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

[Bakul Shah]

Juergen,

With your latest patch things are looking pretty good!

- Multiple qemus on a MP FreeBSD amd64 works with kqemu
  enabled for user code.  Some running 64 bit kernels
  (freebsd), some running 32 bit kernels (freebsd and plan9).

- Nested qemus work! That is, qemu*x86_64 under qemu*x86_64,
  both with user mode kqemu. A 32 bit 7.0 kernel under it ran
  fine.  Ideally qemus should nest as long as there is enough
  memory (a torture test for emulation fidelity).

- As mentioned in another thread netbooting works well enough
  but you have to use pxeboot from -current and append a byte
  to it to work around an etherboot tftp bug.

Now the bugs (probably most having to do with qemu/kqemu,
not the freebsd port):

1. kernel mode kqemu seems to cause crashes.  Generally this
   happens right after the guest freebsd kernel comes up.

2. After the above crash VM reboots automatically but now it
   can't find the root device so it hangs at the root
   selection prompt.

3. Ocassionally plan9 and (less often FreeBSD) crashes on
   boot.  Looks like a race condition of some sort.  If they
   boot, there are no further problems traceable to
   qemu/kqemu.

4. "calcru: runtime went backwards from <t1> usec to <t2> for
   pid <pid> (<cmd>)" is back! Also, ntpd seems to get very
   confused and after syncing with another clock shifts
   mostly correct time by a few hours.

5. An initial getty gets killed as it "exceeded maximum CPU limit"
   This could an emulation bug or related to time issues.

Random thoughts:
- If qemu is made scriptable we can automate a lot of
  testing.  For qemu/kqemu and freebsd.

- We need to add a section on qemu in the handbook.