Date: Sun, 11 May 2008 22:33:02 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Bakul Shah <bakul@bitblocks.com> Cc: freebsd-emulation@freebsd.org, Juergen Lock <nox@jelal.kn-bremen.de>, freebsd-amd64@freebsd.org Subject: Re: seems I finally found what upset kqemu on amd64 SMP... shared gdt! (please test new patch :) Message-ID: <20080511193302.GA18958@deviant.kiev.zoral.com.ua> 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
--c21wNPJaWSwegqfI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, May 11, 2008 at 12:27:45PM -0700, Bakul Shah wrote: > Juergen, >=20 > With your latest patch things are looking pretty good! >=20 > - 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). >=20 > - 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). >=20 > - 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. >=20 > Now the bugs (probably most having to do with qemu/kqemu, > not the freebsd port): >=20 > 1. kernel mode kqemu seems to cause crashes. Generally this > happens right after the guest freebsd kernel comes up. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 5. An initial getty gets killed as it "exceeded maximum CPU limit" > This could an emulation bug or related to time issues. The #5 usually means the thread' kernel stack overflow. >=20 > Random thoughts: > - If qemu is made scriptable we can automate a lot of > testing. For qemu/kqemu and freebsd. >=20 > - We need to add a section on qemu in the handbook. --c21wNPJaWSwegqfI Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkgnSe4ACgkQC3+MBN1Mb4gSCACgrPhP/kp90lrUV79SYLn0nCWE ON0AnjX8BgQTEmPNAP5LfEdwmvjvIMae =G4X1 -----END PGP SIGNATURE----- --c21wNPJaWSwegqfI--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080511193302.GA18958>