qemu-devel
[Top][All Lists]
Advanced

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

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


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

On 01/23/2012 02:03 PM, Alexander Graf wrote:
> 
> 
> On 23.01.2012, at 19:49, Scott Wood <address@hidden> wrote:
> 
>> On 01/23/2012 12:41 PM, Alexander Graf wrote:
>>>>> For tlb0 on e500 and derivatives, tsize is explicitly documented as
>>>>> ignored.  Software may rely on this.
>>>> Yup, that's why there's the check for TLBnCG_AVAIL, which indicates that
>>>> a TLB has dynamic page size capabilities, which TLB0 does not have.
>>> Silly me, thinking "avail" meant "this TLB is available" instead of
>>> looking up the actual meaning. :-P
>>
>> But where do we fill in the size if TLBnCFG_AVAIL is not set?  If this
>> is TLB0 on e500, we can't trust that the target code provided a valid
>> size -- we need to force to 4K.
> 
> TLB0 has min=max=4k :)

If TLB0 has TLBnCFG[AVAIL] set, then with this patch you'll be raising
an exception rather than setting the size to the minimum.

If TLB0 does not have TLBnCFG[AVAIL] set, you'll be letting the user set
whatever size they want.

In either case, you seem to be letting the user write whatever the want
to the TLB array, and only afterward check whether to send an exception.

> True. Maybe we should just always reserve a surplus TLB entry and have the 
> current code work, basically making it be a nop?
> 
> Or we could add checks everywhere...

I'd have booke206_get_tlbm() check and return NULL, with callers
checking for that.  Optimization can come later, if/when it's shown to
be a bottleneck.

-Scott




reply via email to

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