QEMU 0.8.1 and -kernel-kqemu: stalls with "npxdna: fpcurthread == curthread"

[Juergen Lock]

[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