seems I finally found what upset kqemu on amd64 SMP... shared
gdt! (please test new patch :)
bakul at bitblocks.com
Sun May 11 19:43:50 UTC 2008
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
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
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.
- 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.
More information about the freebsd-amd64