Re: [PATCH 3/6] 8xx: invalidate non present TLBs

Hi Ben.

On Oct 8, 2009, at 1:28 PM, Benjamin Herrenschmidt wrote:

While you are around ... I have a question :-)

I'll try.  Many brain cells have been replaced or lost
over the years :-)

Do you happen to remember what the story is with the invalidation of
"unpopulated" (aka invalid) entries ?

IE. We create those in the 8xx TLB miss when the PTE is !present  
(or the
PMD is absent). Those then cause a TLB error on the next access which
allows us to process the page fault. But when/how are those invalid
entries supposed to be invalidated ?

I thought we did a tlbie() (or whatever the equivalent is today)
when the PTE was updated in the table.  An optimization was to
load the TLB with the entry at that time to avoid a subsequent miss.
In any case, the TLB entry has to be modified by the software.

The doco seems to hint that at least in the case of an entry with the
wrong C bit (store to an entry with C=0), the HW automatically
invalidates it before taking the TLB Error but that's all I found.

I don't remember how C was used in the past, but I suspect
it just mirrored the Linux VM state.  I'm quite certain the MMU
HW would never change a TLB entry.  Where did you read this?
For most of the 8xx "early days," I used to just mark all write
pages as dirty.   For some reason I just overloaded the write/changed
into one bit, it avoided TLB Error overhead and I think even some
silicon bugs.  Since they were tiny and fairly static embedded
systems, it didn't have any effect on the way VM was managed.

Is there a general HW policy on 8xx to invalidate TLB entries that  
cause
TLB errors ? Or is the kernel expected to do it most of the time ?

The MMU HW on the 8xx is just a translator.  I'm now really
certain it won't ever change a TLB entry.  It's completely up to
software to make all TLB changes.

Just make it simple :-)

Thanks.

	-- Dan