Scott Wood <scottw...@freescale.com> wrote on 10/11/2009 21:27:05: > > Joakim Tjernlund wrote: > > Scott Wood <scottw...@freescale.com> wrote on 10/11/2009 17:55:28: > >> Except that the invalidation only happens when you take an ITLB miss on > >> an adjacent page, which means we'd likely never get CPU15 protection for > >> kernel code if pinning is enabled. :-( > > > > So tlbie invalidates pinned TLBs too? > > Yes.
OK, and this is in no way unique for 8xx? > > > It is likely that you won't get ITLB Misses for normal kernel > > space but for modules you will. Also, since the pinned D&I TLBs overlap, > > how do you make sure that invalidating a kernel DTLB won't > > spill over to the pinned ITLB? > > I don't see when you'd ever invalidate the pinned entry, whether for > instruction or data purposes, unless you take an ITLB miss for the page > immediately following the pinned mapping. tlbie is used by the kernel in other places too, so I assumed it could be on kernel space too. However, it was just a guess, and by the looks of things, a bad one. > > > Does pinned TLBs work for you? > > Yes -- I turned on CONFIG_PIN_TLB, padded things so that the rfi is > still on the beginning of a new page, and it boots fine. If I keep > everything the same but replace MD_RSV4I with zero, it fails again. Ah, good. > > But who knows when CPU15 will strike... yes, maybe there is a way around that. Perhaps by using one of the pinned entries for loaded modules, i.e avoid ITLB misses for kernel space? In any case one should consider fixing entry_32.S and friends to be properly aligned. Then we are no worse off than when we started, right? Jocke _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev