Scott Wood <scottw...@freescale.com> wrote on 10/11/2009 23:02:10: > > Joakim Tjernlund wrote: > > Scott Wood <scottw...@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 > > _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
