Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp140594pxb; Thu, 21 Jan 2021 03:33:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJyk5MBMVGSL3kqiopb/J9SX9SWTwMOwAOCZEQXG9bw60EKl1mNQ6Ruo05nXVdNMuIxOyUEG X-Received: by 2002:a17:906:f144:: with SMTP id gw4mr9127048ejb.189.1611228780736; Thu, 21 Jan 2021 03:33:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611228780; cv=none; d=google.com; s=arc-20160816; b=MgQKQXB3UD+kZLELeSJ7VHjnRY055oqmVobZaIQPeKV8jJK5iFRTbVIz46NJ1EKREz FIR/PVKXQEnyuCE2d2k1Sd3TKtIeqwUv4Y9/JnesMl3LqsSa5irrfa/Xj68nW4qZ4JUy c0Y8vGUZiwR8mKqprdWiCOfH/TXLBCpKf7L/G26uRlk5MNGUbZDGb5leVSwO9sQNpz9E L/j1zvQALeSnmlDtAohXjl1kA5IQrK7kc8Hk+/Yzn/XZ04BfYf7l7r1lzcxQR3ECZpMh /h0tTCJuxc0x3TA+gf38per9Dx7tDaQUcDUMFPQ1RWJkssGkxIAK8AopUsOevuuj9cpR XS3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=VIF2+EhEbMyo7Y0q0l8+chVM5DQUAi+NjEs1UqZvve8=; b=ZxsgXNIE+OYWndco3FQPzdINqOunBfpKnIuHkVtpkMFiGbh7M1apU3dC9xHgk5cF5G tw/BLYdMi3YGQppeCS+g+E9Rv1Q7elJAHkZbd2xZq+Ys1HpTycPvw9hyiN/qzViBlXnd RnJXbDln3zzgud5cEjT884tJpyFGvclQjhe5jZe5Nf67Io1gj5zgsEV8i3GBV2BrXFwG /ZgIBV5L/mrrS1g99Q5UGm1X0v9OpE12OQMyxI6T2IXPbUQQgHUO3OPme5yiKMWO+F1B 1w9j+kgD7OVJIkenjv0fQGf2/WJdSfzL7dPF+ey1AYzpto7cxhEo6cvKBoS52NXrTpl1 qD1w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="t6I/9FOy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id go43si1454869ejc.565.2021.01.21.03.32.36; Thu, 21 Jan 2021 03:33:00 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b="t6I/9FOy"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728396AbhAUL3E (ORCPT + 99 others); Thu, 21 Jan 2021 06:29:04 -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