In message <3EABD55A.1080700@mips.com>, Nigel writes: 

-> Rafal Boni wrote:
-> 
-> > void
-> >-r5k_sdcache_wbinv_rangeall(vaddr_t va, vsize_t size)
-> >+r5k_sdcache_wbinv_range_index(vaddr_t va, vsize_t size)
-> > {
-> >-	r5k_sdcache_wbinv_all();
-> >+	/*
-> >+	 * Since we're doing Index ops, we expect to not be able
-> >+	 * to access the address we've been given.  So, get the
-> >+	 * bits that determine the cache index, and make a KSEG0
-> >+	 * address out of them.
-> >+	 */
-> >+	va = MIPS_PHYS_TO_KSEG0(va & (mips_sdcache_size - 1));
-> >+	r5k_sdcache_wbinv_range(va, size);
-> > }
-> >
-> >  
-> >
-> 
-> Rafal
-> 
-> Excuse me if I'm getting confused here, as I don't know my way around 
-> the NetBSD cache maintenance code, but unlike the primaries the r5k 
-> secondary cache is physically indexed. Surely you can't simply use the 
-> low-order virtual address bits as an index without first translating 
-> them to a physical address, or else wbinv'ing all possible aliases?

Hmm, you have a good point... I assumed that all the callers of the 
cache maintenance functions (mainly the pmap, I believe) would only
use the indexed operations when they were safe, but now that you ask
this question, I'm not sure if all the cases where they do this make
the same assumptions I made (esp since the L1 cache ops do indeed need
the VA and not the PA).

As you point out, the indexed wbinv for the L2 cache should probably
turn the VA passed in into a PA first, then pull out the index bits.
The aliasing cases, OTOH, I believe should be taken care of by the
caller (as they are by the pmap, for example).

Thanks,
--rafal

----
Rafal Boni                                                     rafal@attbi.com
  We are all worms.  But I do believe I am a glowworm.  -- Winston Churchill