Well, the rule is: any time the same page is mapped more than once,
and at least one of the mappings is writable.

I think there are some ports (Sun 3?) which disable caching if there
is a writable mapping in *any* pmap.  However, since our cache isn't
tagged, we have to purge it on a context switch anyway.  In this case
there's no reason to care about other pmaps.

Give this, the aliasing we care about doesn't happen in any `usual'
cases -- i.e., program text, program data, heaps, or stacks.  However,
it can happen with mmap(2).  If you map the same file twice with
PROT_WRITE and MAP_SHARED, and then cause the pages to be faulted in,
then you'll have two writable mappings of the same pages.  With a
virtually indexed cache, these need to be made uncachable.

Even mmap(2) can be helped, BTW.  If you're letting the kernel place
the pages, then pmap_prefer() can attempt to align the pages so that
they always end up on the same cache lines, and thus the pages can be
left cachable.  This requires knowing some properties of the cache,
and as it's a pretty rare case anyway, I haven't bothered to look at
it yet.