cr@sap.com said:
> On Sun, 02 Dec 2001, David Woodhouse wrote:
> > You said 'assume i386', but just to make it clear - this is likely
> > to break horribly on some non-i386 platforms, due to dcache
> > aliasing.
> Which platforms are affected by this?
Anything with a virtually-indexed cache and a data capacity per way that's
more than your page size - basically anything where it's possible for two
different _virtual_ addresses for the same physical address to end up on
different cache lines.
On SH3 you'll get away with it because the range of address space covered by
the cache is only 2KiB anyway - it's a 8KiB cache but 4-way associative, so
only the bottom 11 bits of the address affect the cache line used - and in
fact it doesn't matter that it's virtually indexed because unless you start
using 1KiB pages, those bits aren't changed by the MMU - only the offset
within the page defined the cache line you look in, and it doesn't matter
about the translation.
On SH4, the data capacity per way of the cache is 8KiB, and because we use
4KiB pages we have two colours. See arch_get_unmapped_area() in
arch/sh/kernel/sys_sh.c, and its usage in sys_mmap() and sys_mremap().
Basically we refuse to allow a mmap of a page to the 'wrong' colour, to
avoid getting aliases.
ARM used to just break, but I pointed it out to Russell a while ago and I
believe he fixed it. I don't remember what his fix was - it may have been
just to map the offending page uncached, which is also a fairly effective
was of avoiding cache aliasing :)
The MIPS kernel doesn't deal with this at all. Ralf tells me that the RM7000
and R[236]000 processors should be fine for the same reason as the SH3, but
R[45]000 are likely to break.
I don't know about other architectures.
A third possible approach other than just refusing the wrong-colour mapping
or disabling the cache entirely is to use the MMU to make sure only one
colour is accessible at a time - when you get a fault on the virtual address
of another colour, you flush the caches and swap over. You're not going to
do that without a physical->virtual lookup though, so it's basically not an
option for Linux atm.
-- dwmw2
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Dec 07 2001 - 21:00:22 EST