From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Io4is-0001rN-SK for qemu-devel@nongnu.org; Fri, 02 Nov 2007 18:10:38 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Io4ir-0001oQ-Db for qemu-devel@nongnu.org; Fri, 02 Nov 2007 18:10:38 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Io4ir-0001o3-3a for qemu-devel@nongnu.org; Fri, 02 Nov 2007 18:10:37 -0400 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Io4iq-0007Fe-FZ for qemu-devel@nongnu.org; Fri, 02 Nov 2007 18:10:36 -0400 Received: from [192.168.0.2] (ppp-36.net-123.static.magiconline.fr [80.118.184.36]) by bangui.magic.fr (8.13.1/8.13.1) with ESMTP id lA2MASj1027206 for ; Fri, 2 Nov 2007 23:10:28 +0100 Subject: Re: [Qemu-devel] qemu-system-ppc problem with PVR access from user space From: "J. Mayer" In-Reply-To: <20071102204610.GA14306@caradoc.them.org> References: <472B2044.9080601@windriver.com> <1194010730.16781.510.camel@rapid> <472B2CD5.9060209@windriver.com> <1194020639.8327.47.camel@jma4.dev.netgem.com> <20071102204610.GA14306@caradoc.them.org> Content-Type: text/plain Date: Fri, 02 Nov 2007 23:10:32 +0100 Message-Id: <1194041433.16781.519.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Fri, 2007-11-02 at 16:46 -0400, Daniel Jacobowitz wrote: > On Fri, Nov 02, 2007 at 05:23:59PM +0100, Jocelyn Mayer wrote: > > No, it's not accidental. An application accessing priviledged SPR, > > including the PVR, is likely to be buggy. I checked in the kernel > > (2.6.23), trapping the mfpvr instruction is a huge bug because it breaks > > the virtualisation features of the PowerPC architecture. Application > > like mol will suffer of this, not being able to pretend the virtualized > > CPU is not the same as the host CPU. The PowerPC architecture has been > > designed to be fully virtualisable but the vanilla Linux kernel breaks > > this useful feature. The bug is then to be fixed in the kernel (and the > > glibc if it really uses mfpvr). > > I suggest you take this up with the PowerPC kernel maintainers, which > might work, instead of making QEMU noisy about it; the people using > QEMU don't care, and they'll just disable the warning. It wasn't > an accidental decision on the kernel maintainers' part either. You're absolutely right, it's a kernel problem: it would prevent any attempt to enable a kqemu-like feature for the PowerPC, for example. And it seems this behavior has been in the Linux kernel for a very long time... I will disable the warning in the PVR specific case, but this is ugly as it will prevent detection of bugged PVR accesses when using OSes that respect the PowerPC specifications. > I don't see the PVR read in current glibc, but I thought it was there; > I don't remember exactly what happened. One thing is sure: any application which uses mfpvr is bugged. I guess there might be some libraries that would like to do it to enable some optimisations at run-time. Or applications like mplayer... But I don't see why init should ever have any usage of knowing the CPU features... -- J. Mayer Never organized