From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:34977) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTDS7-0008AX-HF for qemu-devel@nongnu.org; Sun, 05 Jun 2011 09:33:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTDS6-000248-Cw for qemu-devel@nongnu.org; Sun, 05 Jun 2011 09:33:15 -0400 Received: from agogare.doit.wisc.edu ([144.92.197.211]:62547) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTDS6-000243-8M for qemu-devel@nongnu.org; Sun, 05 Jun 2011 09:33:14 -0400 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth2.wiscmail.wisc.edu by smtpauth2.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0LMB00N00KBD4E00@smtpauth2.wiscmail.wisc.edu> for qemu-devel@nongnu.org; Sun, 05 Jun 2011 08:33:13 -0500 (CDT) Date: Sun, 05 Jun 2011 08:33:11 -0500 From: Nathan Whitehorn In-reply-to: <1EA846CC-A2F8-4677-9012-ACEEC78F3B12@suse.de> Message-id: <4DEB8597.8050906@freebsd.org> References: <4DE50181.6070902@freebsd.org> <4DE52823.4000805@twiddle.net> <4DEA8749.6090902@freebsd.org> <1EA846CC-A2F8-4677-9012-ACEEC78F3B12@suse.de> Subject: Re: [Qemu-devel] [PATCH] ppc64: fix mtmsr behavior on 64-bit targets List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org, Richard Henderson On 06/05/11 04:00, Alexander Graf wrote: > On 04.06.2011, at 21:28, Nathan Whitehorn wrote: > >> On 05/31/11 12:40, Richard Henderson wrote: >>> On 05/31/2011 07:56 AM, Nathan Whitehorn wrote: >>>> #if defined(TARGET_PPC64) >>>> - if (!ctx->sf_mode) { >>>> TCGv t0 = tcg_temp_new(); >>>> TCGv t1 = tcg_temp_new(); >>> You're removing a scope in which these variables were defined. >>> That seems wrong, at minimum. >>> >> I'll fix that (and resend the patch), thanks. A note on this: it looks like a lot of code here incorrectly changes behavior depending on the setting of MSR[SF]. While most of them aren't checking the condition the wrong way, like here, MSR[SF] actually changes very few aspects of the processor's operation. Turning MSR[SF] on or off on a 64-bit CPU basically only affects whether it pays attention to the high 32-bits of addresses when doing loads, stores, and branches -- 64-bit arithmetic, comparisons, registers, etc. are all available whatever the setting of MSR[SF]. > Not sure I understand what you mean. You can't access the upper 32 bits since the instructions are not available when !SF. Also, some subtile behavior changes. > > If you for example run "lis x,-1" in !SF on a 64-bit machine, the full register value becomes 0xffffffffffffffff while in SF mode it becomes 0xffffffff. Maybe there are some parts in the code that are not correct, but !SF on 64-bit is very subtile :). Is that actually true, though? The architecture manual says nothing about it, and on both Cell and 970 systems (the hardware I had handy), as well as IBM Systemsim, lis x,-1 gives 0xffffffffffffff00 irrespective of the value of MSR[SF]. -Nathan