[PATCH 0/8] 8xx: Misc fixes for buggy insn
Joakim Tjernlund
joakim.tjernlund at transmode.se
Wed Nov 11 10:15:48 EST 2009
Scott Wood <scottwood at freescale.com> wrote on 10/11/2009 23:02:10:
>
> Joakim Tjernlund wrote:
> > Scott Wood <scottwood at freescale.com> wrote on 10/11/2009 22:36:32:
> >> Joakim Tjernlund wrote:
> >>> 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.
>
> It wasn't the CPU15 workaround that I was worried about taking down the
> pinning -- but rather the CPU15 bug itself causing bad code to be
> executed inside the pinned kernel mapping.
Oh, but then one is screwed anyway.
>
> However, the erratum says "MMU page", not "4K region", so I suppose if
> we have a pinned 8M page the problem could only occur at the end of the
> 8M (by which point the text segment should have ended).
The wording makes me wonder why not a dcbi would fix the problem too.
Invalidate the problem cache lines and let the branch resolve.
>
> Unless we have any evidence that this is not what the erratum means, I'd
> say make pinning mandatory, and avoid placing modules immediately after
> a pinned entry.
It is worth a try.
>
> > 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?
>
> Yes, until some other code change breaks it again.
>
> -Scott
>
>
More information about the Linuxppc-dev
mailing list