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=-17.7 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 41F13C433E0 for ; Thu, 21 Jan 2021 11:29:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id EC308238E2 for ; Thu, 21 Jan 2021 11:29:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728358AbhAUL30 (ORCPT ); Thu, 21 Jan 2021 06:29:26 -0500 Received: from mail.kernel.org ([198.145.29.99]:44982 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728322AbhAUL2M (ORCPT ); Thu, 21 Jan 2021 06:28:12 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id C7D0E2222B; Thu, 21 Jan 2021 11:27:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611228451; bh=NNIBRAti613JrHVuyoNx3eoND4o9Cxpt15znQz5QslI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t6I/9FOynulb34GA52aJvTWKNLg4FA+lcJ4ttaGKG9Fj2YTUvTHiBNEWASgveGEj6 6fAxOEJaBygZ3Ut5JggIIgsfZFQE0a8Zb6DxD/iyYqHe14hMUH0xxsxJNK+aWqgzK7 2xJnI24rYKqXCnWiGgGZ0MatLfG0sZVAL5F60RDkISgi3zhgXQuf3LvV4XFMLrhhb8 zUI/hwHcinh5UnWaqkWrfxZxqYoEYIeZegK8BA6OTZ9gtLKnn6ZLAK9Jc+qP5kTD3J rkDBa/xQWf0jtSMc0lso6u3bj+ElkKiwRhdf33Yd2iqxYMVw/VH/J9x1dsObKyYwIa V5LnKG0cOHKIQ== Date: Thu, 21 Jan 2021 11:27:26 +0000 From: Will Deacon To: Mohamed Mediouni Cc: linux-arm-kernel@lists.infradead.org, Catalin Marinas , Mark Rutland , Marc Zyngier , Hector Martin , linux-kernel@vger.kernel.org, Stan Skowronek Subject: Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors Message-ID: <20210121112725.GA21750@willie-the-truck> References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-4-mohamed.mediouni@caramail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210120132717.395873-4-mohamed.mediouni@caramail.com> User-Agent: Mutt/1.10.1 (2018-07-13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Will 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=unavailable 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 2BE3EC433E6 for ; Thu, 21 Jan 2021 11:30:00 +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 D6B89238E2 for ; Thu, 21 Jan 2021 11:29:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D6B89238E2 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=LA8w6LLQjoiB991Gv2Q3LR4nkkfpVbF93z2qHFlnY0o=; b=shlFiUd8618a3ArgWOMrkpBje M+pOpB7NjIg+rwQmupfOVbxGzYrvNQQKEdIsBeHLZtS2Mg5BCK8kqu+g3v+up+HQKWRfnDqaGhuZl atJFSGtBz4dGgcvx/a5MM1du4WnO6sTXePwZcwQLJtsZCy+w7okfNDAwCmhRRtoFBa66sCfOEUQs/ +O+ngQaIPJ3j6ehgRURNm74CubpeFXE7a5Hg3e6Vw89k+LxGH9LL48rm3UlzMkK07P6AzooqLTM+b Plvv7A+D5hp6E0+63E3xLkEZ5iTnpQ6jPklAdDqiV3wFKGxbAHTVQFGTougUiNYwAGpNtzF3kv0/K llrZeFWWg==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1l2Y84-0000qn-6z; Thu, 21 Jan 2021 11:27:56 +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 1l2Y7i-0000iH-77 for linux-arm-kernel@lists.infradead.org; Thu, 21 Jan 2021 11:27:44 +0000 Received: by mail.kernel.org (Postfix) with ESMTPSA id C7D0E2222B; Thu, 21 Jan 2021 11:27:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1611228451; bh=NNIBRAti613JrHVuyoNx3eoND4o9Cxpt15znQz5QslI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=t6I/9FOynulb34GA52aJvTWKNLg4FA+lcJ4ttaGKG9Fj2YTUvTHiBNEWASgveGEj6 6fAxOEJaBygZ3Ut5JggIIgsfZFQE0a8Zb6DxD/iyYqHe14hMUH0xxsxJNK+aWqgzK7 2xJnI24rYKqXCnWiGgGZ0MatLfG0sZVAL5F60RDkISgi3zhgXQuf3LvV4XFMLrhhb8 zUI/hwHcinh5UnWaqkWrfxZxqYoEYIeZegK8BA6OTZ9gtLKnn6ZLAK9Jc+qP5kTD3J rkDBa/xQWf0jtSMc0lso6u3bj+ElkKiwRhdf33Yd2iqxYMVw/VH/J9x1dsObKyYwIa V5LnKG0cOHKIQ== Date: Thu, 21 Jan 2021 11:27:26 +0000 From: Will Deacon To: Mohamed Mediouni Subject: Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors Message-ID: <20210121112725.GA21750@willie-the-truck> References: <20210120132717.395873-1-mohamed.mediouni@caramail.com> <20210120132717.395873-4-mohamed.mediouni@caramail.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20210120132717.395873-4-mohamed.mediouni@caramail.com> 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_062734_421950_36E888FB X-CRM114-Status: GOOD ( 19.50 ) 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, Marc Zyngier , 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 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. Will _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel