On Mon, Oct 15, 2001 at 09:14:46PM +0100, Richard Earnshaw wrote:

 > 1) Different ARM processors all have different amounts of cache, that 
 > would make the code highly processor specific.  Well we could cope with 
 > that, but:
 > 2) All ARM cache implementations that I am aware of are set-associative.  
 > As far as I can tell, the trick used on the hp300 (to take an example that 
 > I think you are referring to) will only work with a direct-mapped cache.  
 > For set-associative caches, both entries can be in the cache at the same 
 > time.
 > 
 > 
 > So how would this make the pmap code any easier?

The MIPS pmap "handles" this (though, admittedly, the MIPS cache handling
needs serious cleanup, which I am [slowly] making progress on).

Basically, for an N-way cache, you just be a bit more pessimistic about
the alias distance:

	alias_mask = ((cache_size / cache_ways) - 1) & ~(PAGE_SIZE - 1);

Then, when entering a mapping:

	if ((va1 & alias_mask) != (va2 & alias_mask)) {
		/* need to handle the alias */
	}

Handling the alias generally means flushing the page out of the cache,
and changing all mappings of the page to uncached.  You can restore the
caching of the page when the incompatible mappings go away.

pmap_vac_me_harder() in the current arm32 pmap seems to handle the
"multipe writable mappings" case, but it doesn't appear to actually
check if the pages are at incompatible VAs.  It probably should be
changed to do so.

The pmap can also hint UVM about what VA to use for a mapping, using
pmap_prefer().  I notice the arm32 pmap does not currently supply
pmap_prefer()/PMAP_REFER().  It should do so.  See also the sparc, mips,
and hp300 pmaps (the HP320 has an HP MMU + VAC).  The presence of
PMAP_PREFER() also changes the way UBC caches mappings (it plays nicer
with VACs if PMAP_PREFER is provided by the pmap).

-- 
        -- Jason R. Thorpe <thorpej@wasabisystems.com>