Date: Sat, 13 May 2006 18:32:40 +0200 From: Juergen Lock <nox@jelal.kn-bremen.de> To: Bruce Evans <bde@zeta.org.au> Cc: freebsd-emulation@freebsd.org Subject: Re: QEMU 0.8.1 and -kernel-kqemu: stalls with "npxdna: fpcurthread == curthread" Message-ID: <20060513163240.GA97099@saturn.kn-bremen.de> In-Reply-To: <20060513102437.O68801@delplex.bde.org> References: <1147403789.1034.9.camel@localhost.eu.mscsoftware.com> <200605122110.k4CLALRc074542@saturn.kn-bremen.de> <20060513102437.O68801@delplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, May 13, 2006 at 11:34:31AM +1000, Bruce Evans wrote: > On Fri, 12 May 2006, Juergen Lock wrote: > > >In article <20060512101754.K65309@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. > Its probably guest code (code running on the emulated cpu) that kqemu runs (kqemu_exec()) that is using the fpu. > >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. 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?) Btw it seems the ndisulator has a similar problem sometimes: http://docs.freebsd.org/cgi/mid.cgi?20051110023940.1785116A420
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060513163240.GA97099>