On Wed, Nov 07, 2001 at 10:21:20AM -0800, Matt Thomas wrote:
> At 09:10 AM 11/7/2001 -0800, Chuck Silvers wrote:
> >ah, I was wrong, it is a pmap bug.  pmap_pte_clear() is calling
> >TLBIE() on the address that contains the PTE rather than the address
> >that the PTE is mapping.  the attached diff fixes the problem.
> 
> That's intentional.  When only updating the R/C bits of the PTE,
> the PPC 32-bit Programming Environment Manual.
> 
> >I don't know what document that reference about "As shown in Section 
> >7.6.3.2.2"
> >comes from, is that document wrong or did you just mis-read it, matt?
> 
> I doubt it's wrong.  Hmmm.  that sequence is only value for the REF
> bit, not the CHG bit.  I think I need to think about this more.

executing tblie on the address of the PTE doesn't make any sense...
we don't even use the TLB to access the PTEs, we use the BATs, right?
in all the other examples in those pages of the manual they use
"tlbie(old_EA)", why would this one be different?


> Reading a bit closer, I think I need some lwarx/stwcx. instructions
> when directly manipulating the PPC PTEs in order to garuantee
> consistency of the REF|CHG bits as I read them:
> 
> To modify the WIMG or PP bits without overwriting an R or C bit update 
> being performed
> by the processor, a sequence similar to the one shown above can be used, 
> except that the
> second line is replaced by a loop containing an lwarx/stwcx. instruction 
> pair that emulates
> an atomic compare and swap of the low-order word of the PTE.

that's in the "Modifying the Virtual Address" section, which uses
"tlbie(old_EA)" instead of "tlbie(PTE)".  also, it doesn't say that
you can use sequence to clear the R or C bits.

overall I think we're a lot safer if we use the algorithm from the old pmap
for updating the C bit.  if you want to play around with the R bit that's
fine, but we really need the C bit to be handled correctly.

-Chuck