On Wed, Jan 30, 2002 at 10:55:46AM +0000, Richard Earnshaw wrote:

 > Presumably a future stepping will fix this...

Yes, it will be fixed in D-step, but the first step of the next XScale
processor will also have the bug.

 > > 	* Replace uses of (PT_B | PT_C) when clearing cache bits from a
 > > 	  PTE with a new global pte_cache_bits.  This will be more
 > > 	  important for a future change, which will make the kernel
 > > 	  use the extended cache modes available on the XScale.
 > 
 > Aren't all remaining uses of (PT_B | PT_C) used in the inverse (ie ~(...)).
 > 
 > If so, it would save an invert operation on every use if this were 
 > pte_noncache_bits.

Hm, true, that chould shave some cycles off its use.

 > > 	* When changing permission on a page, clear the existing
 > > 	  cache bits in the PTE and set new cache bits based on the
 > > 	  new page protection.  This requires a Wb cache operation
 > > 	  on the page.  (I certainly hope it doesn't require a
 > > 	  WbInv.)
 > 
 > I can only see one place where you are doing this.  Are you sure the other 
 > places where bits are changing are not also changing a mapping for an 
 > existing page?

Honestly, I could only find that one place where a r/w -> r/o transition
happens.  Are there others?  If so, I'd be grateful if you could point
them out..

 > Have you looked at the modified-emulation code?  That makes pages 
 > read-only, so presumably you will have to mess with the cache bits when 
 > doing that.  Maybe also for the referenced-emulation code.

I'll go through it again.  I needed to give my eyes a break for a bit
and have someone else look at it :-)  (Staring and interrupt and pmap
code all day can make you go nuts...)

 > NOTE: I don't want to fork the pmap code, I just wonder if there is a way 
 > of expressing some of it, maybe with macros, that would allow some of the 
 > indirections to be bypassed when we know we are building a kernel that 
 > will only run on one type of processor.  For example, we know that even 
 > GENERIC kernels for NetWinder and CATS will only contain a StrongARM.

Yah.  It should be possible to do this.  In fact, I'll take a look at
making this happen "soon" (in reality, after BSDcon and Intel Developer
Forum).

Note that at some point, we're going to have to fork the pmap code, or
at least, split out some functions into separate files and have a common
part; at some point in the future, we're going to have to deal with parts
that have physically-indexed caches.

 > R.
 > 
 > PS.  "diff -p" is your friend (well mine, in this case): it labels each 
 > hunk of the patch with the function it comes from.

Ah, of course ... I'll do that next time make a big diff (hm, maybe
I'll just add it to my .cvsrc :-)

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