How to fix 8xx dcbst bug?

[Marcelo Tosatti]

On Sat, May 07, 2005 at 08:24:01PM +0200, Joakim Tjernlund wrote:
> > 
> > 
> > Hi Dan,
> > 
> > So, restarting this conversation...
> > 
> > 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.
> > >
> > > 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.	
> > 
> > >  We may want to make the dcbxxx instructions 
> > > some
> > > kind of macro, so on 8xx we can include such operations in otherwise
> > > "standard" software.
> > 
> > Now that I think of it, userspace dcbst users should not be an issue
> > because the intermediate invalid TLB entry is not visible to applications.
> > 
> > Userspace sees only: not present pte, or valid present pte.
> > 
> > Well, at least the entry which has been causing problems,
> > created by DataStoreTLBMiss.
> > 
> > Is it safe to assume that dcbst usage on userspace is restricted
> > to valid TLBs? Since MMU SPRs are restricted to supervisor 
> > protection, I think so.
> 
> Not sure what you mean here. Currently all dcbX instr. in user space 
> have to be on valid\populated pte's since otherwise it will SEGV. 

OK. The BUG in update_mmu_cache() is triggered because dcbX happens 
on populated but invalid page mapping.

> If you write your app so that any dcbX will only cause a plain DTLB you are
> safe, just look at ld.so. This should not be a requirement but for 8xx it is currently and I think 8xx gets
> away with it because nobody is using swap on 8xx.