From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from az33egw02.freescale.net (az33egw02.freescale.net [192.88.158.103]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "az33egw02.freescale.net", Issuer "Thawte Premium Server CA" (verified OK)) by ozlabs.org (Postfix) with ESMTPS id 9963EB7C4B for ; Wed, 11 Nov 2009 09:01:44 +1100 (EST) Received: from de01smr01.freescale.net (de01smr01.freescale.net [10.208.0.31]) by az33egw02.freescale.net (8.14.3/az33egw02) with ESMTP id nAAM1eER027639 for ; Tue, 10 Nov 2009 15:01:41 -0700 (MST) Received: from az33exm25.fsl.freescale.net (az33exm25.am.freescale.net [10.64.32.16]) by de01smr01.freescale.net (8.13.1/8.13.0) with ESMTP id nAAM5QPX021764 for ; Tue, 10 Nov 2009 16:05:27 -0600 (CST) Message-ID: <4AF9E2E2.7030100@freescale.com> Date: Tue, 10 Nov 2009 16:02:10 -0600 From: Scott Wood MIME-Version: 1.0 To: Joakim Tjernlund Subject: Re: [PATCH 0/8] 8xx: Misc fixes for buggy insn References: <1257341920-29277-1-git-send-email-Joakim.Tjernlund@transmode.se> <20091106003305.GA15814@loki.buserror.net> <20091109215321.GA4351@loki.buserror.net> <20091109230004.GA24671@loki.buserror.net> <4AF99695.800@freescale.com> <4AF99B00.6080504@freescale.com> <4AF9CC99.1030500@freescale.com> <4AF9DCE0.4030805@freescale.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Cc: "linuxppc-dev@ozlabs.org" , Rex Feany List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Joakim Tjernlund wrote: > Scott Wood 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. 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). 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. > 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