On Thu, Aug 22, 2002 at 02:06:18PM -0400, Jake Burkholder wrote:

 > through on ultra sparc, it doesn't contain modified data.  The problem is
 > that the pmap doesn't handle illegal dcache aliases properly.  The data
 > cache is virtually indexed, so mappings of the same page with different
 > virtual color create illegal aliases and need to be marked uncacheable.
 > Using the pv entry alias chains to detect illegal aliases is not sufficient
 > because IIRC the mappings created by pmap_kenter_pa are not on the pv entry
 > chains.  The double mappings used by pipes, for example, may create illegal
 > aliases if the kernel address doesn't have the same color as the user address.

This is interesting.  I discussed this with Chuck Silvers with regards
to the ARM (which also has a virtual alias problem -- in fact, it is nigh
impossible to have a *compatible* virtual alias for a page on ARM).

I'll use the term "managed mapping" to refer to mappings entered with
pmap_enter(), and "unmanaged mapping" to refer to mappings entered with
pmap_kenter_pa().

His response to me was:

to map a page with pmap_kenter_pa(), you're supposed to ensure that
one of the following is true:

	* If you enter an unmanaged mapping, you're supposed to ensure that
	  one of the following is true.

		a. The new mapping will be the only mapping of the page.

		b. All the other mappings are read-only (and thus everything
		   in the cache is clean).  In this case, you're not allowed
		   to create any writable mappings again until all of the
		   unmanaged mappings are removed.

	* It's okay to read via unmanaged mappings even if writable
	  managed mappings exist if you're willing to tolerate stale
	  data.  This is used by the pageout code to avoid revoking
	  write permission on a page.  Instead, you just detect the
	  modification again later, and don't mark the page as clean
	  when the pageout is done[1].  This is why pmap_clear_modify()
	  needs to flush the cache.

	  The reason that a read-only unmanaged mapping is okay is that
	  no dirty cache lines will be created, and thus an aliased
	  mapping doesn't actually matter.

	  [1] I think the actual algorithm is something like:

		a. Clear modify bit.

		b. Mark page PG_CLEAN|PG_BUSY.

		c. Do pageout.

		d. If page is modified, clear PG_CLEAN.

		e. Clear PG_BUSY.

Now, Chuq *claims* that it's also okay to have an aliasing writable
unmanaged mapping if you don't actually write to it.  However, I am
skeptical of this.  The NFS read-ahead code seems to do this (I've
been trying to track down a data corruption bug on XScale that happens
only when using the read/write-allocate cache line policy in conjuction
with NFS).

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