qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] PPC: booke206: Check for min/max TLB entry size


From: Scott Wood
Subject: Re: [Qemu-devel] [PATCH] PPC: booke206: Check for min/max TLB entry size
Date: Mon, 23 Jan 2012 11:28:30 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

On 01/20/2012 08:43 PM, Alexander Graf wrote:
> 
> 
> Am 20.01.2012 um 21:01 schrieb Scott Wood <address@hidden>:
>> I'm not sure what happens when you write
>> an entry to TLB1 with an invalid TSIZE.
> 
> What it says, the ISA means it's implementation dependent. What e500mc 
> actually implements is an different question. Which still needs to be 
> answered.

AFAIK it's not documented what e500mc does for invalid sizes in TLB1, so
I think anything that complies with the architecture's statement of any
supported size is OK.

> However for now I think wde 're ok by not modeling every odd corner case.

Sure.  I was just curious about the architectural statement.

>>> +    /* XXX only applies for MAV 1.0 */
>>> +    size_tlb = (tlb->mas1 & MAS1_TSIZE_MASK) >> (MAS1_TSIZE_SHIFT + 1);
>>> +    size_min = (tlbncfg & TLBnCFG_MINSIZE) >> TLBnCFG_MINSIZE_SHIFT;
>>> +    size_max = (tlbncfg & TLBnCFG_MAXSIZE) >> TLBnCFG_MAXSIZE_SHIFT;
>>> +    if ((size_tlb > size_max) || (size_tlb < size_min)) {
>>> +        /* set to min size */
>>> +        tlb->mas1 &= ~MAS1_TSIZE_MASK;
>>> +        tlb->mas1 |= size_min << (MAS1_TSIZE_SHIFT + 1);
>>> +    }
>>
>> You could just implement a bitmap now, which will work for MAV 2.0 as well.
>>
>> Especially since we're using the MAV 2.0 definition of tsize already, so
>> min/max isn't an accurate way to describe what we support.
> 
> Not sure I follow. In MAV 1.0 the size constraints are defined in TLBnCFG, 
> while for MAV 2.0 they are defned in their own bitmap registers (TLBnPS)
> 
> Would you like to have a function called that returns a bitmap of
> supported sizes for the TLB depending on its MAV value based on
> either TLBnCFG or TLBnPS? We could then check if that size value bit
> is set.

Yes, use a bitmap internally regardless of how the programming model
says we convey the information to the target code.

-Scott




reply via email to

[Prev in Thread] Current Thread [Next in Thread]