Re: Cache aliasing on >32k VIPT caches

[Imre Deak <imre.deak%teleca.com@localhost>]

On Mon, Aug 25, 2008 at 08:27:26AM -0700, Matt Thomas wrote:
>
> On Aug 25, 2008, at 5:54 AM, Imre Deak wrote:
>
>> Hi all,
>>
>> according to the ARMv6 TRM:
>> [...]
>> 2. Alternatively, if all mappings to a physical address are of a page 
>> size equal to
>>    4KB, then the restriction that bits[13:12] of the Virtual Address 
>> must equal
>>    bits[13:12] of the physical address is not necessary. Bits[13:12] of 
>> all Virtual
>>    Address aliases must still be equal.
>>
>>
>>
>> So based on the above at the least we should adhere to 2., I'm  
>> guessing that
>> right now there isn't any case where we need 1. The current pmap code 
>> only considers
>> bit 12 to distinguish between colors, does this need to be corrected? 
>> As far as I
>> understand only bit 12 is significant for picking the cache index and 
>> thus color,
>> which would make the current code correct, but then again the TRM  
>> might just know
>> better..
>>
>>                                  __BIT(9 + CPU_CT_xSIZE_SIZE(isize)
>>                                        - CPU_CT_xSIZE_ASSOC(isize))
>>                                  - PAGE_SIZE;
>
> The code as it exists is correct.
>
> For 16KB/32KB/64KB, CPU_CT_xSIZE_SIZE(isize) is 0b101 (5) / 0b110 (6) / 
> 0b111 (6).
> CPU_CT_xSIZE_ASSOC(size) is always 0b010 (2).
>
> So the __BIT() expression is __BIT(12), __BIT(13), __BIT(14),  
> respectively.
>
> Which gives a mask of 0, PAGE_SIZE, 3*PAGE_SIZE respectively.
>
> For both 16KB and 64KB we use the right value, so why doesn't 32KB use
> 3*PAGE_SIZE as well?  It has to do with cache organization...
>
> Each cache line is 32 bytes and we have 4 ways, so that gives us 128  
> sets for
> 16KB.  Note that 16KB doesn't need page coloring so it must be able map 
> each
> address to its unique (set, way).
>
> Now 64KB needs 512 sets or 4x128 sets.  The page color is used to  
> determine
> which of the four 128-entry sets to place the cache entry.  That's why it
> needs to be matched.
>
> But 32KB only has 256 or 2x128 sets.  So there are only two  
> possibilities for
> the page color.  So while we could use 4 page colors, there is no reason 
> since
> the upper bit will be ignored.  That will just result in additional  
> cache
> flushing to no real effect.
>

Thanks, this is what seems to be logical. The TRM is then too
conservative at this point.

--Imre