From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:52536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHUBZ-0004rn-Ps for qemu-devel@nongnu.org; Thu, 05 Sep 2013 03:41:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VHUBT-00056E-Ks for qemu-devel@nongnu.org; Thu, 05 Sep 2013 03:41:01 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:56731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VHUBT-000568-ER for qemu-devel@nongnu.org; Thu, 05 Sep 2013 03:40:55 -0400 Received: by mail-pa0-f42.google.com with SMTP id lj1so1565103pab.1 for ; Thu, 05 Sep 2013 00:40:54 -0700 (PDT) Message-ID: <5228357E.7000106@ozlabs.ru> Date: Thu, 05 Sep 2013 17:40:46 +1000 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <1378360700-4300-1-git-send-email-aik@ozlabs.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] spapr-rtas: reset top 4 bits in parameters address List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: "qemu-ppc@nongnu.org" , Paul Mackerras , "qemu-devel@nongnu.org" On 09/05/2013 05:08 PM, Alexander Graf wrote: > > > Am 05.09.2013 um 07:58 schrieb Alexey Kardashevskiy : > >> On the real hardware, RTAS is called in real mode and therefore >> ignores top 4 bits of the address passed in the call. > > Shouldn't we ignore the upper 4 bits for every memory access in real mode, not just that one parameter? We probably should but I just do not see any easy way of doing this. Yet another "Ignore N bits on the top" memory region type? No idea. This particular patch was born after discovering GCC 4.8.0 bug with not doing -0xc000.0000.0000.0000 correctly and this would not be a problem on the real hardware. So I would think there are kernel somewhere which have this bug. And there are few (honestly I found only one place and the patch fixes it) places which can fail because of this GCC bug. So the patch does make sense for Paul and myself. btw the patch is wrong, I should do this in a different place, sorry about that :) > > Alex > >> >> This fixes QEMU to do the same thing. >> >> Signed-off-by: Alexey Kardashevskiy >> --- >> hw/ppc/spapr_rtas.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/hw/ppc/spapr_rtas.c b/hw/ppc/spapr_rtas.c >> index eb542f2..ab03d67 100644 >> --- a/hw/ppc/spapr_rtas.c >> +++ b/hw/ppc/spapr_rtas.c >> @@ -240,7 +240,8 @@ target_ulong spapr_rtas_call(PowerPCCPU *cpu, sPAPREnvironment *spapr, >> struct rtas_call *call = rtas_table + (token - TOKEN_BASE); >> >> if (call->fn) { >> - call->fn(cpu, spapr, token, nargs, args, nret, rets); >> + call->fn(cpu, spapr, token, nargs, args & 0x0FFFFFFFFFFFFFFFUL, >> + nret, rets); >> return H_SUCCESS; >> } >> } >> -- >> 1.8.4.rc4 >> -- Alexey