From owner-freebsd-emulation@FreeBSD.ORG Sun May 14 15:22:21 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 80F7A16A416 for ; Sun, 14 May 2006 15:22:21 +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 B481D43D45 for ; Sun, 14 May 2006 15:22:20 +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 k4EFMG2N019078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 May 2006 17:22:16 +0200 Received: from saturn.kn-bremen.de (uucp@localhost) by gwyn.kn-bremen.de (8.13.4/8.13.4/Submit) with UUCP id k4EFMG5T019076; Sun, 14 May 2006 17:22:16 +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 k4EFKanI025248; Sun, 14 May 2006 17:20:36 +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 k4EFKZiv025247; Sun, 14 May 2006 17:20:35 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Sun, 14 May 2006 17:20:35 +0200 To: Bruce Evans Message-ID: <20060514152034.GA25076@saturn.kn-bremen.de> Mail-Followup-To: Bruce Evans , freebsd-emulation@FreeBSD.org, Fabrice Bellard 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> <20060514132829.H72413@delplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060514132829.H72413@delplex.bde.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-emulation@FreeBSD.org, Fabrice Bellard 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 15:22:21 -0000 [Fabrice: this is from a thread thats been going on freebsd-emulation: http://lists.freebsd.org/pipermail/freebsd-emulation/2006-May/002081.html It is about the FreeBSD kernel complaining about kqemu using the fpu.] On Sun, May 14, 2006 at 03:08:45PM +1000, Bruce Evans wrote: > 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? Well, Fabrice knows more about this than I. :) > Or are we mainly talking about > FreeBSD being run under emulation and not FreeBSD running the emulation? no > 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