Subject: Re: Ultra 10, anyone?
To: Jake Burkholder <jake@locore.ca>
From: Chuck Silvers <chuq@chuq.com>
List: port-sparc64
Date: 08/22/2002 21:58:31
hi,

yea, the virtually-addressed caches are tricky.
the business of allowing bad aliases in pmap_kenter_pa()
requires a bit more effort in some of the other interfaces.
the general idea is that removing a writable mapping should
remove the cache effects of that mapping as well (ie. flushing
a VAC when removing write access and invalidating it when removing
all access), and when clearing the modified state you should also
clean any dirty VAC cache lines that are associated with the dirty page.
when these rules are followed, allowing bad aliases seems to work ok
on all the different platforms I've tried.

the weird thing that jason mentioned on the Xscale is exceptional,
I haven't figured out what's going on there yet.  it only happens
if with a certain cache configuration or with changes to copyin()
to use cache prefetching instructions.

-Chuck


On Thu, Aug 22, 2002 at 02:06:18PM -0400, Jake Burkholder wrote:
> Apparently, On Thu, Aug 22, 2002 at 10:27:38AM -0700,
> 	Jason R Thorpe said words to the effect of;
> 
> > On Thu, Aug 22, 2002 at 10:23:16AM -0700, Andrey Petrov wrote:
> > 
> >  > I'm not sure if that hme or not but the following patch fixed
> >  > 'signal 11' during NFS build for me. I have some theory about
> >  > aliased shared pages, but it's just guess with no prove at this 
> >  > point.
> > 
> > Please check this patch in.  For a write-back cache, when MOD is cleared,
> > the cache *must* be written-back, otherwise it is possible for data to
> > be lost.
> 
> 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.
> 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).
> 
> Please correct me if I'm wrong; OpenBSD may have picked up these changes
> and have the same problem.
> 
> Jake