Re: [Qemu-devel] [Qemu-ppc] Help needed testing on ppc

[Alexander Graf <agraf@suse.de>]

On 19.06.14 15:21, BALATON Zoltan wrote:
> On Wed, 18 Jun 2014, Tom Musta wrote:
>> On 6/17/2014 10:17 AM, BALATON Zoltan wrote:
>>> On Tue, 17 Jun 2014, Tom Musta wrote:
>>>> I am looking at the test case source code and do not see how you 
>>>> are setting the reserved bit. Maybe I am missing some cleverness in 
>>>> how the test is built?
>>>
>>> Probably I should have written it more straight-forward but I wanted 
>>> it to be possible to change it for other tests easily so it's a bit 
>>> tricky. Basically I get the code location by a bl then fetching the 
>>> link register:
>>>
>>>>  asm volatile("mfcr %0 \n\t"
>>>>               "bl 1f                 \n\t"
>>>>               "mfcr %1               \n\t"
>>>>               "mflr 10               \n\t"
>>>
>>> and then set the bit with the next three lines after testing the 
>>> normal case:
>>>
>>>>               "lwz %0, 36(10) \n\t"
>>>>               "ori %0, %0, 1         \n\t"
>>>>               "stw %0, 36(10)        \n\t"
>>>
>>> Then test again with the bit set:
>>>
>>>>               "mfcr %0 \n\t"
>>>>               "bl 1f                 \n\t"
>>>>               "mfcr %2               \n\t"
>>>
>>> and exit:
>>>
>>>>               "b 2f \n\t"
>>>>               "1: stwx %0, %4, %6    \n\t" <<<<<<<<<<<<< just a 
>>>> normal stwx, right?
>>>>               "blr                   \n\t"
>>>>               "2:                    \n\t"
>>>>                : "=&r"(cr), "=&r"(cr1), "=&r"(cr2), "=m"(val)
>>>>                : "r"(&val), "m"(val), "r"(8)
>>>>                : "r8", "r9", "r10", "cc", "memory");
>>>>
>>>>  prom_printf("old cr  (mem):\t%#x\n", val);
>>>>  prom_printf("old cr  (reg):\t%#x\n", cr);
>>>>  prom_printf("new cr1 (reg):\t%#x\n", cr1);
>>>>  prom_printf("new cr2 (reg):\t%#x\n", cr2);
>>>> }
>>>>
>>>>
>>>> But the objdump of your test binary does not show that it is set 
>>>> either:
>>>
>>> It should show in a debugger the second time the stwx is called (it 
>>> did for me).
>>>
>>
>> There should be an icbi after the ori/stw sequence to ensure that the 
>> modified code gets into the instruction cache.
>
> I've corrected the test accordingly and rerun on iMac,1. It did not 
> change the stwx test results, the cr values are still the same.

Great :). Now please check through all opcodes that get generated by the 
GEN_STUX, GEN_STX_E, GEN_LDUX and GEN_LDX_E helpers in translate.c and 
verify that the bit gets ignored on all of them. We can then easily  
just remove the reserved Rc bit on those instruction definitions 
generically and call it a day.


Alex