From owner-freebsd-emulation@FreeBSD.ORG Sun May 14 05:08:50 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 8C83016A401 for ; Sun, 14 May 2006 05:08:50 +0000 (UTC) (envelope-from bde@zeta.org.au) Received: from mailout2.pacific.net.au (mailout2.pacific.net.au [61.8.0.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE79843D46 for ; Sun, 14 May 2006 05:08:49 +0000 (GMT) (envelope-from bde@zeta.org.au) Received: from mailproxy1.pacific.net.au (mailproxy1.pacific.net.au [61.8.0.86]) by mailout2.pacific.net.au (Postfix) with ESMTP id 76ED016DFD4; Sun, 14 May 2006 15:08:48 +1000 (EST) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailproxy1.pacific.net.au (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k4E58jgp005472; Sun, 14 May 2006 15:08:46 +1000 Date: Sun, 14 May 2006 15:08:45 +1000 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Juergen Lock In-Reply-To: <20060513163240.GA97099@saturn.kn-bremen.de> Message-ID: <20060514132829.H72413@delplex.bde.org> References: <1147403789.1034.9.camel@localhost.eu.mscsoftware.com> <200605122110.k4CLALRc074542@saturn.kn-bremen.de> <20060513102437.O68801@delplex.bde.org> <20060513163240.GA97099@saturn.kn-bremen.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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: Sun, 14 May 2006 05:08:50 -0000 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