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 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 8BF90C433EF for ; Thu, 27 Jan 2022 15:53:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc: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=N6T16KqzVdfJ9Bnlx7eNDqjt4FO28FWko0N0uWylXXY=; b=lXzZ62xzCNEeaz Hwky3mpTFXTaGz023XDW0VP7ZQLz8STtLOs9lxoKpleDrWTp2Fd/HvUgD2AKSH/US/wBojQ3HMbI5 JpjV+qhXlJwTGx3z/BvMsxDS/pf988CRz+i51WES+7gM94w2800BOkMcJ7X9a+B/NbD05j3sFv6Ve aSa5T/l1H80BFFG/fn/RjT7biqC1bMa/G6B6TpHAwUhGfYzsHqFdHnggerJCKPNaNO1QjRW34G5X6 HXa38cLiG7OT7obYXnKt1O8USy1xrrN7ZXNQiVuvCs0Q+OnqOFmK3rFnwZW7WTyQe/6hdDSnmxy0V BxahLOAZZ0dKEkSErIzA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD74c-00GKFK-Af; Thu, 27 Jan 2022 15:52:34 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nD74Z-00GKDU-9Y for linux-arm-kernel@lists.infradead.org; Thu, 27 Jan 2022 15:52:32 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 7FA2D1063; Thu, 27 Jan 2022 07:52:27 -0800 (PST) Received: from FVFF77S0Q05N (unknown [10.57.14.34]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3257D3F766; Thu, 27 Jan 2022 07:52:26 -0800 (PST) Date: Thu, 27 Jan 2022 15:52:13 +0000 From: Mark Rutland To: Andre Przywara Cc: linux-arm-kernel@lists.infradead.org, broonie@kernel.org, jaxson.han@arm.com, robin.murphy@arm.com, vladimir.murzin@arm.com, wei.chen@arm.com Subject: Re: [bootwrapper PATCH v3 02/15] aarch64: correct SCTLR_EL1_KERNEL for AA32 kernels Message-ID: References: <20220125150057.3936090-1-mark.rutland@arm.com> <20220125150057.3936090-3-mark.rutland@arm.com> <20220126150338.5af163e5@donnerap.cambridge.arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220126150338.5af163e5@donnerap.cambridge.arm.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220127_075231_446636_6121CF2A X-CRM114-Status: GOOD ( 26.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , 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 26, 2022 at 03:03:38PM +0000, Andre Przywara wrote: > On Tue, 25 Jan 2022 15:00:44 +0000 > Mark Rutland wrote: > > Hi, > > > Bits [31:0] of the AArch64 SCTLR_EL1 register are architecturally mapped > > to bits [31:0] of the AArch32 SCTLR register. This means that any > > individual bit always has the same value across the two registers. > > > > Across the two registers, the same bit may have distinct meanings, > > distinct RESx behaviour, and distinct reset behaviour. For example, > > SCTLR_EL1[28] is nTLSMD, which we wich to initialize to 0b1, whereas > > SCTLR[28] is TRE, which we wish to initialize to 0b0. > > > > To avoid setting bits which we did not intend to, and in preparation for > > configuring more AArch64 RES1 bits, this patch decouples the > > SCTLR_EL1_KERNEL value used for AArch32 kernels from the SCTLR_EL1_RES1 > > definitions such that is does not inherit AArch64 SCTLR_EL1 bits which > > would be problematic in the AArch32 SCTLR. For now we open-code a copy > > of the bits defined in arch/aarch64/include/asm/cpu.h. > > > > Signed-off-by: Mark Rutland > > Cc: Andre Przywara > > --- > > arch/aarch64/include/asm/cpu.h | 11 +++++++++-- > > 1 file changed, 9 insertions(+), 2 deletions(-) > > > > diff --git a/arch/aarch64/include/asm/cpu.h b/arch/aarch64/include/asm/cpu.h > > index e3269b8..49d3f86 100644 > > --- a/arch/aarch64/include/asm/cpu.h > > +++ b/arch/aarch64/include/asm/cpu.h > > @@ -36,8 +36,15 @@ > > #define SCTLR_EL1_RES1 (3 << 28 | 3 << 22 | 1 << 11) > > > > #ifdef KERNEL_32 > > -/* 32-bit kernel decompressor uses CP15 barriers */ > > -#define SCTLR_EL1_KERNEL (SCTLR_EL1_RES1 | SCTLR_EL1_CP15BEN) > > +/* > > + * When booting a 32-bit kernel, EL1 uses AArch32 and registers which are > > + * architecturally mapped must be configured with the AArch32 layout. > > + * > > + * We copy the AArch32 definition of SCTLR_KERNEL here. > > + * > > + * TODO: restructure the headers to share a single definition. > > + */ > > +#define SCTLR_EL1_KERNEL (3 << 22 | 1 << 11 | 1 << 5 | 3 << 4) > > Is the verbatim copying of the value, including the redundancy, intended? Yup, the intent is to have the exact same definition, overlapping bits and all. I would like to clean that up in future, but for now I want this to clearly be the same. > Maybe that meant 3 << 3, as bits[4:3] are documented as "Reserved, > RAO/SBOP" in the ARMv7 ARM? > It's fine with me either way, since it copies the aarch32 value, just > wanted to check: > > Reviewed-by: Andre Przywara Thanks! Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel