[PATCH 0/8] 8xx: Misc fixes for buggy insn

Joakim Tjernlund joakim.tjernlund at transmode.se
Wed Nov 11 08:25:17 EST 2009


Scott Wood <scottwood at freescale.com> wrote on 10/11/2009 21:27:05:
>
> Joakim Tjernlund wrote:
> > Scott Wood <scottwood at 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



More information about the Linuxppc-dev mailing list