Re: [Qemu-devel] [Qemu-ppc] [PATCH] booke_206_tlbwe: Discard invalid bits in MAS2

[Alexander Graf <agraf@suse.de>]

On 05/21/2012 12:59 PM, Fabien Chouteau wrote:
> On 05/21/2012 11:08 AM, Alexander Graf wrote:
>> On 21.05.2012, at 10:56, Fabien Chouteau wrote:
>>
>>> On 05/20/2012 12:18 PM, Alexander Graf wrote:
>>>>
>>>> On 20.05.2012, at 12:15, Alexander Graf<agraf@suse.de>  wrote:
>>>>
>>>>>
>>>>> On 09.05.2012, at 15:28, Fabien Chouteau<chouteau@adacore.com>  wrote:
>>>>>
>>>>>> The size of EPN field in MAS2 depends on page size. This patch adds a
>>>>>> mask to discard invalid bits in EPN field.
>>>>>>
>>>>>> Definition of EPN field from e500v2 RM:
>>>>>> EPN Effective page number: Depending on page size, only the bits
>>>>>> associated with a page boundary are valid. Bits that represent offsets
>>>>>> within a page are ignored and should be cleared.
>>>>>>
>>>>>> There is a similar (but more complicated) definition in PowerISA V2.06.
>>>>>>
>>>>>> Signed-off-by: Fabien Chouteau<chouteau@adacore.com>
>>>>>> ---
>>>>>> target-ppc/op_helper.c |   10 ++++++++--
>>>>>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>>>>>
>>>>>> diff --git a/target-ppc/op_helper.c b/target-ppc/op_helper.c
>>>>>> index 4ef2332..6bc64ad 100644
>>>>>> --- a/target-ppc/op_helper.c
>>>>>> +++ b/target-ppc/op_helper.c
>>>>>> @@ -4227,6 +4227,8 @@ void helper_booke206_tlbwe(void)
>>>>>>    uint32_t tlbncfg, tlbn;
>>>>>>    ppcmas_tlb_t *tlb;
>>>>>>    uint32_t size_tlb, size_ps;
>>>>>> +    target_ulong mask;
>>>>>> +
>>>>>>
>>>>>>    switch (env->spr[SPR_BOOKE_MAS0]&  MAS0_WQ_MASK) {
>>>>>>    case MAS0_WQ_ALWAYS:
>>>>>> @@ -4289,8 +4291,12 @@ void helper_booke206_tlbwe(void)
>>>>>>        tlb->mas1 |= (tlbncfg&  TLBnCFG_MINSIZE)>>  12;
>>>>>>    }
>>>>>>
>>>>>> -    /* XXX needs to change when supporting 64-bit e500 */
>>>>>> -    tlb->mas2 = env->spr[SPR_BOOKE_MAS2]&  0xffffffff;
>>>>>> +    /* Make a mask from TLB size to discard invalid bits in EPN field */
>>>>>> +    mask = ~(booke206_tlb_to_page_size(env, tlb)
>>>>> This breaks execution of -cpu with qemu-system-ppc64, no?
>>>> -cpu e500 I mean of course :).
>>>>
>>> Maybe but I don't see why...
>> Because the effective address might be padded to be negative, rendering lots of f's in the upper 32 bits.
> Sorry I don't understand, can you provide an example?

Sure, just try to run your guest kernel with qemu-system-ppc64 and it 
will break :).

lis r1, 0x8000
lwz r2, 0(r1)

With qemu-system-ppc, this will translate to a read at 0x80000000. For 
qemu-system-ppc64 however, r1 contains 0xffffffff80000000, no?

>
>> Do you maybe have an idea how this works for 64-bit BookE hardware? How does it make sure that a TLB entry only covers the lower 32 bits of the EA when running 32-bit user space?
>>
> No I don't know 64-bit BookE hardware. But I don't see why this would be
> a special case. A 32-bit address would be padded with zeros to get a
> 64-bit address to compare with EPN.
>
> 0x00100000 ->  0x0000000000100000
>
> It's up to the OS to provide a good mapping in a 32-bit process (i.e.
> use 32-bit EPN).

Hrm. This is not about the OS, it's about the TLB. Does TLB matching 
restrict itself to the low 32 bits when not in a 64-bit context? If so, 
we could add that check and make it work again :).


Alex