In message <000701c38ca9$ad008540$0a00a8c0@PAQ2>, you write: 

-> Rafal Boni  said;
-> 
-> > What I ended up doing (per Nisimura-san's suggestion,
-> > is to simply supply a new pmap_copy_page() and pmap_zero_page() for
-> > the R5k), which do things slightly differently by writing through a
-> > VA set aside for copy/zero and using write-through cache mode on that
-> > mapping.
-> 
-> The point is, just make sure _not_ to have any aliasing, pay full attension
-> every cache line is occupied with consistent VA.  It's wrong to fix/cheat
-> the fundamental issue by VCE.   This could be done thru keep "VA cache
-> slide (cache colour?)"  sync w/ cache indexing.  Say, 32KB direct map
-> cache brings 32KB slide in VA, 16KB 2 way cache does 8KB.  Also note that
-> 16KB 4 way cache implies "don't worry, happy size for 4KB page",
-> that is, this case will never matter in turn since there is 1-to-1 
-> symmetry between VA index and cache line index.

Right, I've not done this (ye) because as you mention below, it requires
info from the VM system about where the page will be mapped.

-> Rafal, there is no need to #ifdef R5000 for the new pmaps.  It should be
-> generic across any MIPS processors.   (Actually, I have been accumulating
-> boring sense to see patchy #ifdefs before full considerations).

The only reason I even care about this is that on the R5k I can map the
pages write-through no-allocate (via a reserved VA) and hence don't have
to worry about the cache effects (at least for zero; for copy there is
still the need to sync the source page and maybe invalidate the dest --
though I'm not sure if the latter is actually required as I unmap and
mark both VA ranges invalid after the copy is done).  AFAIK, the R4k
did not have the right CCAs to be able to do this and in any case there
the currently algorithm pretty much works (modulo the fact that it's
ugly :-).

I have it #ifdef'ed right now, but was just going to do what the sparc
does, which is to indirect it through a function pointer and have diff-
erent functions for the R5k/R4k/pre-R4k.

-> It's not perfect solution to have the new copy/zero because the whole
-> here comes from the fact those pmap routines have no clue of target VA.
-> Necessity to change some in MI (U)VM arena.

Right; maybe I should bug Chuq some about this.  IIRC, there was a paper
out of DEC's WRL (?) about pmap changes for a virutally-indexed HP box
where they actually pre-mapped it in a way that left in inaccessible to
all but the copy/zero code and passed a VA down to the copy/zero routines.
After the copy/zero, the page was fixed up to them be accesible and passed
on to it's owner...  Unfortunately, I think that would be very intrusive
change given the way UVM works now.

--rafal

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