Subject: a new pmap_copy_page() and pmap_zero_page()
To: None <port-mips@netbsd.org>
From: Toru Nishimura <locore32@gaea.ocn.ne.jp>
List: port-mips
Date: 10/07/2003 17:04:46
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.

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).

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

Toru Nishimura/ALKYL Technology