From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35269) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTDV9-0008VM-Em for qemu-devel@nongnu.org; Sun, 05 Jun 2011 09:36:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QTDV6-0002R8-5I for qemu-devel@nongnu.org; Sun, 05 Jun 2011 09:36:22 -0400 Received: from agogare.doit.wisc.edu ([144.92.197.211]:62697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QTDV5-0002Qk-QR for qemu-devel@nongnu.org; Sun, 05 Jun 2011 09:36:20 -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 <0LMB00000KGJE400@smtpauth2.wiscmail.wisc.edu> for qemu-devel@nongnu.org; Sun, 05 Jun 2011 08:36:19 -0500 (CDT) Date: Sun, 05 Jun 2011 08:36:17 -0500 From: Nathan Whitehorn In-reply-to: <4DEB8597.8050906@freebsd.org> Message-id: <4DEB8651.9030205@freebsd.org> References: <4DE50181.6070902@freebsd.org> <4DE52823.4000805@twiddle.net> <4DEA8749.6090902@freebsd.org> <1EA846CC-A2F8-4677-9012-ACEEC78F3B12@suse.de> <4DEB8597.8050906@freebsd.org> 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 08:33, Nathan Whitehorn wrote: > 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 Also, those instructions *are* available. That's the only way to turn 64-bit mode on, for instance: you need to grab the MSR, set one of the high bits, then mtmsrd (which is a 64-bit instruction). -Nathan