Port-arm archive

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

Re: Cache aliasing on >32k VIPT caches

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

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

Home | Main Index | Thread Index | Old Index