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

[Fabien Chouteau <chouteau@adacore.com>]

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?

> 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).

-- 
Fabien Chouteau