Dan, I haven't heard your opinion on Joakim's proposed change yet.
It looks plausible, and its more complete than dcbst's reimplementation with 8xx specific cache functions (because it also covers userspace dcbst callers). I would love to see this getting fixed in v2.6 mainline. Thanks On Sat, Apr 09, 2005 at 07:37:21PM -0300, Marcelo Tosatti wrote: > On Sat, Apr 09, 2005 at 09:03:54PM +0200, Joakim Tjernlund wrote: > > > > > > On Apr 8, 2005, at 7:07 AM, Marcelo Tosatti wrote: > > > > > > > 1) _tlbie() on update_mmu_cache() surrounded by CONFIG_8xx #ifdef > > > > Did you give up about it? > > > > > > I think a tlbia() of the vaddr should work here. No sense blowing > > > away the whole TLB cache for this. > > > > Umm, isn't it the other way around? tlbie flushes one TLB whereas tlbia > > flushes > > all TLBs. > > Yep > > > > > What else you think can be done? > > > > > > It would be interesting to change __flush_dcache_icache() > > > to use the 8xx SPR cache operations instead of the dcbst instruction. > > > > yes, but I think these operates on physical addresses which makes it a bit > > harder. > > Other than the fact of userspace dcbst users. > > > I still think this can be resolved in fault.c. Replace > > andis. r11, r10, 0x0200 /* If set, indicates store op */ > > beq 2f > > in the DTLB Error handler with > > andis. r11, r10, 0x4800 /* If set, indicates invalid pte or > > protection violation */ > > bne 2f > > Why does the current code jump to page fault handler in case of store > operation? > > Out of curiosity, aren't there any other valid bit combinations for DSISR > other > than 0x4800 which should allow a fastpath DataTLBError ? > > I can't find DSISR settings in MPC860UM.pdf neither paper manual. AFAICS it > always refer to the PEM when talking about DSISR bit assignments. > > I can't find section "7-15" as you mentioned in the other email. > > > In fault.c you can check if both store and invalid is set simultaneously. > > If it is, clear > > the store flag and continue as usual. > > One point is that by changing the in-kernel dcbst implementation userspace is > still vulnerable to the problem. > > Now fixing the exception handler to deal with such boggosity as Joakim > proposes is > complete - it handles userspace dcbst callers. > > > > I wouldn't be surprised if it worked differently, but I'd not be > > > able to explain it :-) > > > > > > Thanks. > > > > > > -- Dan > > > > _______________________________________________ > Linuxppc-embedded mailing list > Linuxppc-embedded at ozlabs.org > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
