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

[Joakim Tjernlund]

Scott Wood <scottwood at freescale.com> wrote on 10/11/2009 22:36:32:
>
> Joakim Tjernlund wrote:
> > 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?
>
> Not sure about others, but 8xx manual explicitly says that it
> invalidates reserved entries.
>
> >> 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?
>
> Not sure what you mean...  loaded modules won't be pinned, and since
> they shouldn't contain rfi, don't need to be.

But CPU15 may invalidate a pinned TLB if you take a TLB Miss?
If not there should not be a problem, because the rest
of the kernel will never take a ITLB Miss.

>
> I don't see how to pin any part of the kernel without introducing some
> possibility of CPU15, unless we go scanning the last word of every
> instruction page, creating trampolines, and hoping there's no data
> embedded in the text segment. :-P

Yes, it is not going to be easy.
So aligning the srr0/srr1/rfi properly is needed.

BTW, you could probably cram the DARFix into the DTLBerror with some luck.
Especially if you allow it to spill over to the next trap. Then create a
branch insn at 0x1500 to 0x1600. Would that make everything aligned again?

  Jocke