Re: [Qemu-devel] [PATCH] spapr-rtas: reset top 4 bits in parameters address

[Alexey Kardashevskiy <aik@ozlabs.ru>]

On 09/05/2013 05:08 PM, Alexander Graf wrote:
> 
> 
> Am 05.09.2013 um 07:58 schrieb Alexey Kardashevskiy <aik@ozlabs.ru>:
> 
>> 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 <aik@ozlabs.ru>
>> ---
>> 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