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 55D59C28CF5 for ; Wed, 26 Jan 2022 15:20:38 +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:MIME-Version:References:In-Reply-To: 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=ZVabmIkHnobPMwtkAdC6uz2LDn1bKRBzbG3/Rs+DY8c=; b=P2BPswI0IuYCXC QWj3gnxI8yALTcs+Gdmj54rQbh7hxZqbcoVbIWHR8oIIABdipkLx+t6cfcimbwfhW6J0ahJXeS4qH zAscRhAC8Rn3VFGaus3JiDC3sV64qnSmTNaGEzTcor+drDJHeLbsLWCw+KNgH1ggQ51KPO5Xd2io4 sdh1hemT8u2C5C1ICZdF8yI0lih6uGlmemPbJ47EFjzTI1+9JXj0mVhOfnH7ZYLG6zwlsiaXBFvSs H/SkxzGQP1NEGpSlPE7nU1f2D86DjyjyyrObKzAOB60ha7f/P/l0LCadb+A4kZmYLOme05ICFzc34 nNyiuHPXZQ82jp3iV3Eg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nCk4j-00CE2G-1K; Wed, 26 Jan 2022 15:19:09 +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 1nCjpm-00C6qO-BN for linux-arm-kernel@lists.infradead.org; Wed, 26 Jan 2022 15:03:43 +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 823A71FB; Wed, 26 Jan 2022 07:03:41 -0800 (PST) Received: from donnerap.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.121.207.14]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9C0C73F793; Wed, 26 Jan 2022 07:03:40 -0800 (PST) Date: Wed, 26 Jan 2022 15:03:38 +0000 From: Andre Przywara To: Mark Rutland 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: <20220126150338.5af163e5@donnerap.cambridge.arm.com> In-Reply-To: <20220125150057.3936090-3-mark.rutland@arm.com> References: <20220125150057.3936090-1-mark.rutland@arm.com> <20220125150057.3936090-3-mark.rutland@arm.com> Organization: ARM X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; aarch64-unknown-linux-gnu) MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220126_070342_514193_F529F9D9 X-CRM114-Status: GOOD ( 21.40 ) 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 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? 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 Cheers, Andre > #define SPSR_KERNEL (SPSR_A | SPSR_I | SPSR_F | SPSR_HYP) > #else > #define SCTLR_EL1_KERNEL SCTLR_EL1_RES1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel