Date: Sun, 11 May 2008 23:05:18 +0200 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-emulation@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) Message-ID: <20080511210518.GA46475@saturn.kn-bremen.de> In-Reply-To: <20080511192745.6F3625B4D@mail.bitblocks.com> References: <20080511160748.GA38480@saturn.kn-bremen.de> <20080511192745.6F3625B4D@mail.bitblocks.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 11, 2008 at 12:27:45PM -0700, Bakul Shah wrote: > 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. > Yeah I posted one of those on the qemu list, http://lists.gnu.org/archive/html/qemu-devel/2008-05/msg00233.html 32 bit linux guests seem to work fine tho at least. > 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. > Hmm. > 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. > Hmm. > 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... > Also, ntpd seems to get very > confused and after syncing with another clock shifts > mostly correct time by a few hours. > Ouch. > 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. > Hmm what exactly do you want to script there? > - We need to add a section on qemu in the handbook. Hmmm... :) Juergen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080511210518.GA46475>