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.
