8xx v2.6 TLB problems and suggested workaround

[Marcelo Tosatti]

On Tue, Apr 05, 2005 at 11:58:17AM -0400, Dan Malek wrote:
> 
> On Apr 4, 2005, at 3:17 PM, Marcelo Tosatti wrote:
> 
> >Problem is that the "dcbst" instruction will, _sometimes_ (the 
> >failure/success rate is about 1/4
> >with my test application) fault as a _write_ operation on the data.
> 
> Oh, geeze .... It's all coming back to me now ....
> 
> The 8xx cache operations don't always operate as defined in the PEM.
> There are likely to be some archive discussions within the Freescale
> knowledge data base that describe the different behaviors I've seen
> with the chip variants and revisions.  I can't find any of those e-mail
> discussions, so I'll try to recall from memory.
> 
> The PEM cache instructions are all implemented in a microcode that
> uses the 8xx unique cache control SPRs.  Depending upon the state
> of the cache and MMU, it seems in some cases the EA translation is
> subject to a "normal" protection match instead of a load operation 
> match.
> 
> The behavior of these operations isn't consistent across all of the 8xx
> processor revisions, especially with early silicon if people are still
> using those.  During conversations with Freescale engineers, it seems
> the only guaranteed operation was to use the 8xx unique SPRs, but
> I think I only did that in 8xx specific functions.

How sweet.  :)

> We have way too much code in the TLB exception handlers already,
> so let's just try a tlbia of the EA in the update_mmu_cache, with an 
> #ifdef
> for the 8xx.  

Are you sure this is the best solution ? 

Problem is that update_mmu_cache() is called from other context's where
the tlb invalidate is not necessary (because it has already been invalidated).

For example all ptep_set_access_flags() (which does the tlb invalidate) -> 
update_mmu_cache() sequences.

Moreover jumping directly from DataTLBMiss to the page fault handler
shortcuts the process: there is no need to jump back to execution if we
know in advance that DataTLBError exception is going to happen. 

But hey, you are the boss. Even with the above facts you prefer 
to leave the DataTLBMiss untouched? 

About size: I think it is the smaller expection handler present.

> It seems if the dcbst causes a TLB miss during execution,
> it does the right thing. 

It should always cause a miss because the TLB entry is marked as invalid
(DataTLBMiss just created the invalid TLB entry). 

So even when a miss happens, it can do the wrong thing.

Right? 

>  We may want to make the dcbxxx instructions 
> some
> kind of macro, so on 8xx we can include such operations in otherwise
> "standard" software.

I'm a bit lost here: you're talking about the kernel side of things only 
or userspace also? 

The latter would require "GNU as" dcbxxx macro? Hum...

> Thanks for the great work!

Your help has been invaluable!

I feel very good after many days of debugging pain. :)