From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,INCLUDES_CR_TRAILER,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 32459C433DB for ; Thu, 21 Jan 2021 12:49:18 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id DA19223A00 for ; Thu, 21 Jan 2021 12:49:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DA19223A00 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=817IWJOzKq8Htd2yp5y+3IVYkbIxjl3k98YIQfh596I=; b=DLCUZrcGB0oAYq6nYt5Xle+oI VEa6UJMD3/8nmP9LmXom95CTTkLaa+iztozQYKsqMmZoliHvSBscPnZQQbOnOPeigWshOeAiz3/8z b0zP54nCh9ITy7YYkeEbpW6iThdaCW4xClH0Wn1w5Mhqok6IzMRqSspznW1TaC6ONbzVWdjKblFbH QpGvP0C4ZBSnzxd5PmZ17H2jjzBdAXYNQFGd9uj3OY5QlxyphsNJ1w1dRMxgJCVm0YndLrZePtDGI yeDYrYItUpFkX3nlE3fOMlUiO/CWCmNgzFP41LxFCvSELYBdkzB0xTMDsmZWSVTscAPLrAf2Zy6yO eyivdHCDg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2ZNR-0001py-1v; Thu, 21 Jan 2021 12:47:53 +0000 Received: from mail.kernel.org ([198.145.29.99]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2ZNN-0001p7-1E for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 12:47:50 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id 8E7A1239FD; Thu, 21 Jan 2021 12:47:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611233268; bh=dd4yVlG9KCtejepvHpsxeT3++mxKoHWtZTeivvj2m1Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=juVxlmLRk3sPnqi2cpCwV8Yh5CyUDKDtHm9bgxeBYtb7PgJ/QYTC2/S7FMVsbGieX +p+G+tAXsn3Wpqle6HWrVvXAf81J/hLdQLdkBLHa7g8+MelcuuiHROOMSL10KaUuCZ XI11xwu0vo4X9jpN7GY5jfHt2Aw85hD0nFeioehNGfULUNy6qmaVJ+5gV/iBqXABCm +RGFeDKDWWXQFGlqqKpCIzpWzNRbLl4otLMlpx5lzLJ34oSuMBP/FtFf9m9TZbuclf Cvg+JJmm1O+NVO88bZeg9Fn713WyC6GoeO6bYQWf7CvatkVdCP1510apDJ8fT+KazG Kq2DckCKrXzLA== Date: Thu, 21 Jan 2021 12:47:43 +0000 From: Will Deacon To: Marc Zyngier Subject: Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors Message-ID: <20210121124742.GA22123@willie-the-truck> References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-4-mohamed.mediouni@caramail.com> <20210121112725.GA21750@willie-the-truck> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210121_074749_276933_8BF6401D X-CRM114-Status: GOOD ( 28.08 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Mark Rutland , Catalin Marinas , Hector Martin , linux-kernel@vger.kernel.org, Mohamed Mediouni , linux-arm-kernel@lists.infradead.org, Stan Skowronek Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Thu, Jan 21, 2021 at 11:44:23AM +0000, Marc Zyngier wrote: > On 2021-01-21 11:27, Will Deacon wrote: > > On Wed, Jan 20, 2021 at 02:27:13PM +0100, Mohamed Mediouni wrote: > > > Use nGnRnE instead of nGnRE on Apple SoCs to workaround a serious > > > hardware quirk. > > > > > > On Apple processors, writes using the nGnRE device memory type get > > > dropped in flight, > > > getting to nowhere. > > > > > > Signed-off-by: Stan Skowronek > > > Signed-off-by: Mohamed Mediouni > > > --- > > > arch/arm64/mm/proc.S | 26 ++++++++++++++++++++++++++ > > > 1 file changed, 26 insertions(+) > > > > > > diff --git a/arch/arm64/mm/proc.S b/arch/arm64/mm/proc.S > > > index 1f7ee8c8b7b8..06436916f137 100644 > > > --- a/arch/arm64/mm/proc.S > > > +++ b/arch/arm64/mm/proc.S > > > @@ -51,6 +51,25 @@ > > > #define TCR_KASAN_HW_FLAGS 0 > > > #endif > > > > > > +#ifdef CONFIG_ARCH_APPLE > > > + > > > +/* > > > + * Apple cores appear to black-hole writes done with nGnRE. > > > + * We settled on a work-around that uses MAIR vs changing every > > > single user of > > > + * nGnRE across the arm64 code. > > > + */ > > > + > > > +#define MAIR_EL1_SET_APPLE \ > > > + (MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRnE) | \ > > > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_nGnRnE, MT_DEVICE_nGnRE) | \ > > > + MAIR_ATTRIDX(MAIR_ATTR_DEVICE_GRE, MT_DEVICE_GRE) | \ > > > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_NC, MT_NORMAL_NC) | \ > > > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL) | \ > > > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL_WT, MT_NORMAL_WT) | \ > > > + MAIR_ATTRIDX(MAIR_ATTR_NORMAL, MT_NORMAL_TAGGED)) > > > + > > > +#endif > > > + > > > /* > > > * Default MAIR_EL1. MT_NORMAL_TAGGED is initially mapped as Normal > > > memory and > > > * changed during __cpu_setup to Normal Tagged if the system > > > supports MTE. > > > @@ -432,6 +451,13 @@ SYM_FUNC_START(__cpu_setup) > > > * Memory region attributes > > > */ > > > mov_q x5, MAIR_EL1_SET > > > +#ifdef CONFIG_ARCH_APPLE > > > + mrs x0, MIDR_EL1 > > > + lsr w0, w0, #24 > > > + mov_q x1, MAIR_EL1_SET_APPLE > > > + cmp x0, #0x61 // 0x61 = Implementer: Apple > > > + csel x5, x1, x5, eq > > > > Why does this need to be done so early? It would be a lot cleaner if we > > could detect this in a similar fashion to other errata and update the > > MAIR > > appropriately. If that's not possible because of early IO mappings > > (which > > ones?), then we could instead initialise to nGnRnE unconditionally, but > > relax it to nGnRE if we detect that we _don't_ have the erratum. > > Would that imply another round-trip into the idmap, much like we do > when we switch to non-global mappings? Or do you expect that we can change > the MAIR with live mappings? I think we should be able to change it live and then invalidate the TLB. At least, my reading of the BBM requirements suggests that it isn't required for changing between different types of device memory. I can seek clarification from Arm if necessary. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel