Subject: Re: Ultra 10, anyone?
To: Jake Burkholder <jake@locore.ca>
From: Andrey Petrov <petrov@netbsd.org>
List: port-sparc64
Date: 08/22/2002 12:34:32
On Thu, Aug 22, 2002 at 02:06:18PM -0400, Jake Burkholder wrote:
> 
> I think you may need this in pmap_enter as well; I notice that the cache
> flushes that used to be there have been removed.  The dcache is write
> 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.

Actually, it corresponds with my observations and thoughts on this.
And yes, frequent flushes will help and mask underlying problem, though
pmap_enter might be not enought to garantie coherence.
And I'd like to catch these appearences first.

> The way I fixed this in FreeBSD/sparc64 is to merge the pv entries and the
> page table entries and to put all mappings on the pv entry chains, which
> allows the aliases to be detected (actually tsb entries, we don't use page
> tables).

TRT. Also kernel might try to avoid miscolored mappings.

	Andrey