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

[Bruce Evans]

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?  Or are we mainly talking about
FreeBSD being run under emulation and not FreeBSD running the emulation?
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