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

[Dan Malek]

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