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

[Bruce Evans]

On Fri, 12 May 2006, Juergen Lock wrote:

> In article <20060512101754.K65309 at delplex.bde.org> you write:
>> On Fri, 12 May 2006, Georg-W. Koltermann wrote:

>>>        May 11 13:04:44 hunter kernel: npxdna: fpcurthread == curthread
>> 43 times
>>>        ...
>>>
>>> messages.  I then had to kill qemu.
>>>
>>> It does run ok without the "-kernel-kqemu" option.  Any idea?
>>
>> 1. This error should cause a panic instead of a printf.  An invariant has
>>    been violated.  The panic was broken in rev.1.131 of npx.c.
>> 2. This error has been implemented before.  It was in the amd64
>>    linux32_sysvec.c until rev.1.9 of that.  There it was caused by dubious
>>    setting of CR0_TS.  The fix is dubious too:
>> ...
>> Maybe other emulators get this wrong similarly.
>
> 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.

> Btw, kqemu on amd64 also causes lots of
> 	fpudna in kernel mode!
> messages even when not using -kernel-kqemu (so that kqemu only runs
> guest userland code in kernel space.)

This should cause a panic too.  It indicates that the kernel is using
the FPU without even setting up for using it.  It just gets used (*).
This may clobber its current user since there is no setup.  (The kernel
is currently only permitted to use the FPU for saving and restoring
it for userland.  In disabled optimizations for old Pentiums, the FPU
is really used by the kernel, but this requires saving the state if there
is a current user.)  A stack track for this would locate a problem
exactly.

(*) Note fpudna() is called unconditionally, and we only panic if it
returns 0.  The test is especially bogus on amd64 since fpudna() always
returns 1 there.  On i386's, the corresponding npxdna() still returns
0 in the !npx_exists case, but that case should never occur.

Bruce