Re: Cache aliasing on >32k VIPT caches

[Matt Thomas <matt%3am-software.com@localhost>]

On Aug 25, 2008, at 5:54 AM, Imre Deak wrote:

> Hi all,
>
> according to the ARMv6 TRM:
>
> 1. If multiple Virtual Addresses are mapped onto the same physical  
> address then for
>    all mappings, bits [13:12] of the Virtual Addresses must be  
> equal and the same as
>    bits [13:12] of the physical address. Imposing this requirement  
> on the virtual
>    addresses is sometimes called page coloring.
>    The same physical address can be mapped by TLB entries of  
> different page sizes,
>    including page sizes over 4KB.

This is used when mapping large pages and sections by mem(4).  I  
recently added
support to do that.

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