From owner-freebsd-emulation@FreeBSD.ORG Sat May 13 16:34:45 2006 Return-Path: X-Original-To: freebsd-emulation@freebsd.org Delivered-To: freebsd-emulation@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0859116A790 for ; Sat, 13 May 2006 16:34:45 +0000 (UTC) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn.kn-bremen.de [212.63.36.242]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0ACA043D73 for ; Sat, 13 May 2006 16:34:37 +0000 (GMT) (envelope-from nox@saturn.kn-bremen.de) Received: from gwyn.kn-bremen.de (gwyn [127.0.0.1]) by gwyn.kn-bremen.de (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4DGYZFn023503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 13 May 2006 18:34:35 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id k4DGYZ3D023501; Sat, 13 May 2006 18:34:35 +0200 Received: from saturn.kn-bremen.de (nox@localhost [127.0.0.1]) by saturn.kn-bremen.de (8.13.3/8.13.1) with ESMTP id k4DGWhj8097439; Sat, 13 May 2006 18:32:43 +0200 (CEST) (envelope-from nox@saturn.kn-bremen.de) Received: (from nox@localhost) by saturn.kn-bremen.de (8.13.3/8.13.1/Submit) id k4DGWeq4097438; Sat, 13 May 2006 18:32:41 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sat, 13 May 2006 18:32:40 +0200 To: Bruce Evans Message-ID: <20060513163240.GA97099@saturn.kn-bremen.de> Mail-Followup-To: Bruce Evans , freebsd-emulation@freebsd.org References: <1147403789.1034.9.camel@localhost.eu.mscsoftware.com> <200605122110.k4CLALRc074542@saturn.kn-bremen.de> <20060513102437.O68801@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060513102437.O68801@delplex.bde.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-emulation@freebsd.org Subject: Re: QEMU 0.8.1 and -kernel-kqemu: stalls with "npxdna: fpcurthread == curthread" X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 May 2006 16:34:47 -0000 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