Date: Sun, 14 May 2006 17:20:35 +0200 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-emulation@FreeBSD.org, Fabrice Bellard <fabrice@bellard.org> Subject: Re: QEMU 0.8.1 and -kernel-kqemu: stalls with "npxdna: fpcurthread == curthread" Message-ID: <20060514152034.GA25076@saturn.kn-bremen.de> In-Reply-To: <20060514132829.H72413@delplex.bde.org> References: <1147403789.1034.9.camel@localhost.eu.mscsoftware.com> <200605122110.k4CLALRc074542@saturn.kn-bremen.de> <20060513102437.O68801@delplex.bde.org> <20060513163240.GA97099@saturn.kn-bremen.de> <20060514132829.H72413@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
[Fabrice: this is from a thread thats been going on freebsd-emulation: http://lists.freebsd.org/pipermail/freebsd-emulation/2006-May/002081.html It is about the FreeBSD kernel complaining about kqemu using the fpu.] On Sun, May 14, 2006 at 03:08:45PM +1000, Bruce Evans wrote: > On Sat, 13 May 2006, Juergen Lock wrote: > > >On Sat, May 13, 2006 at 11:34:31AM +1000, Bruce Evans wrote: > >>On Fri, 12 May 2006, Juergen Lock wrote: > >... > >>>So you think kqemu is doing something wrong? The problem is _k_qemu is > >> > >>Most likely. It could be triggering triggering a bug in the kernel > >>proper, > >>but I can't see how it could do this without doing something wrong. > >> > >>>closed source and afaik the author doesnt use freebsd, the inner > >>>workings of it are in a binary blob that gets linked into a kld and it > >>>runs guest code (including kernel code with -kernel-kqemu) in kernel > >>>space on the host cpu. You can see the freebsd-specific parts in > >>>/usr/ports/emulators/kqemu-kmod/work/kqemu-1.3.0pre7/kqemu-freebsd.c > >>>(after doing make in the port's dir) - could this be patched there? > >> > >>Probably not. I couldn't see any floating point there or in a disassembly > >>of the module. A stack trace would show what used floating point, but > >>might not locate the problem exactly, depending on what used it. > > Now I've found SSE2 code in the amd64 version. It seems to be harmless > but points to possible causes of the problem. We compile modules with > -mno-sse2, etc., to prevent use of SSE2, etc., but on amd64 SSE2 code > still gets generated to copy xmm[0-7] in va_start(). This shouldn't > be a problem since args should never be passed in xmm[0-7]. (On amd64, > the first few args are passed in xmm[0-7]; %al gives the count of such > args and va_start(ap, fmt) copies that many args to ap.) The problem > is more likely that something else is not compiled with -mno-sse2, etc. > > >Its probably guest code (code running on the emulated cpu) that kqemu > >runs (kqemu_exec()) that is using the fpu. > > How does code in qemu get into the kernel? Well, Fabrice knows more about this than I. :) > Or are we mainly talking about > FreeBSD being run under emulation and not FreeBSD running the emulation? no > I can see CR0 in kqemu.h but not anything that sets it. I can see CR0 and > CR_TS being managed a lot (all under emulation?) in qemu but not in kqemu. > > >Could we simply assume that kqemu_exec() will always use the fpu > >and do the necessary things before calling it in kqemu-freebsd.c? > >(and what would those be exactly?) > > If that is the only problem area then it may be enough to just ensure a > consistent state. But I don't understand the context switches here. > > >Btw it seems the ndisulator has a similar problem sometimes: > > http://docs.freebsd.org/cgi/mid.cgi?20051110023940.1785116A420 > > This is for amd64 too. > > Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060514152034.GA25076>