From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Inwjg-0003zf-GL for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:38:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Inwje-0003yx-Qj for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:38:56 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Inwje-0003ys-K4 for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:38:54 -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 1Inwje-0007o7-0A for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:38:54 -0400 Subject: Re: [Qemu-devel] qemu-system-ppc problem with PVR access from user space From: "J. Mayer" In-Reply-To: <472B2044.9080601@windriver.com> References: <472B2044.9080601@windriver.com> Content-Type: multipart/mixed; boundary="=-NdAzjJsOXC0qmbSad5w+" Date: Fri, 02 Nov 2007 14:38:50 +0100 Message-Id: <1194010730.16781.510.camel@rapid> Mime-Version: 1.0 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 --=-NdAzjJsOXC0qmbSad5w+ Content-Type: text/plain Content-Transfer-Encoding: 7bit On Fri, 2007-11-02 at 08:04 -0500, Jason Wessel wrote: > The typical kernel + user space I boot on the prep machine no longer > boots due to an issue accessing the PVR special purpose register. When > the PVR is accessed from user space, it should generate an exception > with the PC set to the instruction that it occurred at when it saves to > the stack. In the latest CVS, it is off by 4 bytes. With out the fix > /sbin/init gets killed because the kernel's trap handler which does the > userspace emulation of the instruction does not clean up the trap. > > I am using the attached patch to work around the problem, but I wonder > if there is a more generic problem that was introduced as a regression > with all ppc merges in the last month or so, given this used to work > fine through the generic handler. > > Any insight into this would certainly be useful. Seems like I made a mistake for program exception generation while fixing floating-point ones, I'm sorry. Your patch is incorrect but the one attached should fix the problem. Could you please check it in your case ? -- J. Mayer Never organized --=-NdAzjJsOXC0qmbSad5w+ Content-Disposition: attachment; filename=ppc_excp.diff Content-Type: text/x-patch; name=ppc_excp.diff; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Index: target-ppc/helper.c =================================================================== RCS file: /sources/qemu/qemu/target-ppc/helper.c,v retrieving revision 1.85 diff -u -d -d -p -r1.85 helper.c --- target-ppc/helper.c 28 Oct 2007 00:55:05 -0000 1.85 +++ target-ppc/helper.c 2 Nov 2007 13:35:52 -0000 @@ -2146,10 +2145,9 @@ static always_inline void powerpc_excp ( new_msr |= (target_ulong)1 << MSR_HV; #endif msr |= 0x00100000; - if (msr_fe0 != msr_fe1) { - msr |= 0x00010000; - goto store_current; - } + if (msr_fe0 == msr_fe1) + goto store_next; + msr |= 0x00010000; break; case POWERPC_EXCP_INVAL: #if defined (DEBUG_EXCEPTIONS) @@ -2187,7 +2185,7 @@ static always_inline void powerpc_excp ( env->error_code); break; } - goto store_next; + goto store_current; case POWERPC_EXCP_FPU: /* Floating-point unavailable exception */ new_msr &= ~((target_ulong)1 << MSR_RI); #if defined(TARGET_PPC64H) --=-NdAzjJsOXC0qmbSad5w+--