Date: Sun, 11 May 2008 16:51:39 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Juergen Lock <nox@jelal.kn-bremen.de> Cc: freebsd-emulation@freebsd.org Subject: Re: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) Message-ID: <20080511235139.C9ECD5B58@mail.bitblocks.com> In-Reply-To: Your message of "Sun, 11 May 2008 23:05:18 %2B0200." <20080511210518.GA46475@saturn.kn-bremen.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 11 May 2008 23:05:18 +0200 Juergen Lock <nox@jelal.kn-bremen.de> wrote: > > 4. "calcru: runtime went backwards from <t1> usec to <t2> for > > pid <pid> (<cmd>)" is back! > > Well, the clock never was very accurate thats true... Simulated time will be slower than the real time by some indeterminate amount but still all times ought to be monotonically increasing. > > Random thoughts: > > - If qemu is made scriptable we can automate a lot of > > testing. For qemu/kqemu and freebsd. > > > Hmm what exactly do you want to script there? I don't have an "exact" idea but lots of vague ideas that need fleshing out! Ideally, after every significant update, all the useful qemu options get automatically tested. For that you need to be able to control qemu's operation (and the guest OS!) and capture useful information in case of bugs or crashes. Right now you can emulate keyboard input via qemu's monitor interface but you don't know how the guest OS reacts to it. May be even snapshotting the console display to a .png file on certain conditions can be very useful. You want to be able run a test manually and create an automated script from it (e.g. when I run these set of things, this is what the screen looks like except for that rectangle in the bottom right corner!). And this has to happen relative to the qemu's virtual time. For testing a guest OS such as FreeBSD, one would like to bootstrap a freshly built kernel and run a variety automated tests against it. In case of the OS crashing you capture backtrace, save the memory image in a dump file and contiue testing. Doing this after a real machine crash is much more painful. With qemu (or vmware) you just start up a whole bunch of virtual machines (depending on available resources) and do testing in parallel. All testing is repetitious so it needs to be automated. > > - We need to add a section on qemu in the handbook. > > Hmmm... :) You just need to extend chapter 21 on Virtualization that already talks about vmware, parallels, xen and virual PC. :-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080511235139.C9ECD5B58>