From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1InwDR-0001cy-AJ for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:05:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1InwDM-0001Y8-LS for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:05:36 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1InwDM-0001Xn-Cg for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:05:32 -0400 Received: from mail.windriver.com ([147.11.1.11] helo=mail.wrs.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1InwDL-0005Jt-97 for qemu-devel@nongnu.org; Fri, 02 Nov 2007 09:05:31 -0400 Received: from ALA-MAIL03.corp.ad.wrs.com (ala-mail03 [147.11.57.144]) by mail.wrs.com (8.13.6/8.13.6) with ESMTP id lA2D5RdJ029617 for ; Fri, 2 Nov 2007 06:05:28 -0700 (PDT) Message-ID: <472B2044.9080601@windriver.com> Date: Fri, 02 Nov 2007 08:04:04 -0500 From: Jason Wessel MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------080706090202090904030301" Subject: [Qemu-devel] qemu-system-ppc problem with PVR access from user space 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 This is a multi-part message in MIME format. --------------080706090202090904030301 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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. Thanks, Jason. --------------080706090202090904030301 Content-Type: text/x-patch; name="ppc_pvr_access_from_user_space.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ppc_pvr_access_from_user_space.patch" Work around the problem that the PC register is not saved with the right address when taking a user space PVR access exception. Signed-off-by: Jason Wessel --- target-ppc/translate_init.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) --- a/target-ppc/translate_init.c +++ b/target-ppc/translate_init.c @@ -92,6 +92,13 @@ static void spr_write_clear (void *opaqu } #endif +static void spr_read_generic_fault_user(void *opaque, int sprn) +{ + DisasContext *ctx = opaque; + ctx->nip -= 4; + GEN_EXCP_PRIVREG(ctx); +} + /* SPR common to all PowerPC */ /* XER */ static void spr_read_xer (void *opaque, int sprn) @@ -5942,7 +5949,7 @@ static void init_ppc_proc (CPUPPCState * /* Register SPR common to all PowerPC implementations */ gen_spr_generic(env); spr_register(env, SPR_PVR, "PVR", - SPR_NOACCESS, SPR_NOACCESS, + &spr_read_generic_fault_user, SPR_NOACCESS, &spr_read_generic, SPR_NOACCESS, def->pvr); /* PowerPC implementation specific initialisations (SPRs, timers, ...) */ --------------080706090202090904030301--