seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :)

[Bakul Shah]

On Sun, 11 May 2008 23:05:18 +0200 Juergen Lock <nox at 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. :-)