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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 38CD7C61DA4 for ; Mon, 6 Feb 2023 09:31:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229797AbjBFJb1 (ORCPT ); Mon, 6 Feb 2023 04:31:27 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38230 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229448AbjBFJbY (ORCPT ); Mon, 6 Feb 2023 04:31:24 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CD12A13DDB; Mon, 6 Feb 2023 01:31:23 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6679D60DBB; Mon, 6 Feb 2023 09:31:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C0912C433EF; Mon, 6 Feb 2023 09:31:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1675675882; bh=IbbdJxwExq/xgTnQ3QxlRR4vh7AQ7SmhFQ+DR+Lfkr4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=l4sAkd10OviU9F3grPZsiDbuKk78ANHZn8ZmpfVBK0ikMJji9AdN69CPqafp3VN2T hN1OYKVDAIjkNKghPf3+slZTAvMUo5M0W3u/9h+ylr6KtuYY/G7WnUryDYXOPBCwI+ nNwWolcuaUhNe2Y/BKd2vOUCZUJnEDe+F6qk0rvCwAvVLSaopoOWiUyORbbEzt3Ziw f/sFw55ITnc3rEymlnJdvFDLYIqNGynH+X/W2POarSvTxZ30hP9ZyXlHnX7uIA68EE yuou4ZqcJ6ATDPgOSbWTEBItYQM1FRF6URqDBpjvqhcqH/Por5YgMgrlAfEJDTGMxX 2JwIh31X8N8NA== Received: from sofa.misterjones.org ([185.219.108.64] helo=goblin-girl.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1pOxqK-007wxh-Do; Mon, 06 Feb 2023 09:31:20 +0000 Date: Mon, 06 Feb 2023 09:31:20 +0000 Message-ID: <86y1pbywbb.wl-maz@kernel.org> From: Marc Zyngier To: Mark Brown , Catalin Marinas Cc: Will Deacon , Oleg Nesterov , James Morse , Alexandru Elisei , Suzuki K Poulose , Oliver Upton , Shuah Khan , Alan Hayward , Luis Machado , Szabolcs Nagy , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org Subject: Re: [PATCH v4 07/21] arm64/sme: Enable host kernel to access ZT0 In-Reply-To: <20221208-arm64-sme2-v4-7-f2fa0aef982f@kernel.org> References: <20221208-arm64-sme2-v4-0-f2fa0aef982f@kernel.org> <20221208-arm64-sme2-v4-7-f2fa0aef982f@kernel.org> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (aarch64-unknown-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: broonie@kernel.org, catalin.marinas@arm.com, will@kernel.org, oleg@redhat.com, james.morse@arm.com, alexandru.elisei@arm.com, suzuki.poulose@arm.com, oliver.upton@linux.dev, shuah@kernel.org, alan.hayward@arm.com, luis.machado@arm.com, szabolcs.nagy@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev, linux-kselftest@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 16 Jan 2023 16:04:42 +0000, Mark Brown wrote: >=20 > The new register ZT0 introduced by SME2 comes with a new trap, disable it > for the host kernel so that we can implement support for it. >=20 > Signed-off-by: Mark Brown > --- > arch/arm64/kernel/hyp-stub.S | 6 ++++++ > arch/arm64/kernel/idreg-override.c | 1 + > 2 files changed, 7 insertions(+) >=20 > diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S > index 2ee18c860f2a..d31d1acb170d 100644 > --- a/arch/arm64/kernel/hyp-stub.S > +++ b/arch/arm64/kernel/hyp-stub.S > @@ -132,6 +132,12 @@ SYM_CODE_START_LOCAL(__finalise_el2) > orr x0, x0, SMCR_ELx_FA64_MASK > .Lskip_sme_fa64: > =20 > + // ZT0 available? > + __check_override id_aa64smfr0 ID_AA64SMFR0_EL1_SMEver_SHIFT 4 .Linit_sm= e_zt0 .Lskip_sme_zt0 > +.Linit_sme_zt0: > + orr x0, x0, SMCR_ELx_EZT0_MASK > +.Lskip_sme_zt0: > + I've been looking at this in order to solve a merge conflict in next, and couldn't convince myself that the above actually works. __check_override assumes that the ID_AA64SMFR0_EL1 value is in x1, and I guess that the intent of the code is to reuse value read a few lines above. But as the comment says at the beginning of the macro, x1 will be clobbered, and the checks always fails. I presume we're just lucky that sme2_kernel_enable() does the same thing unconditionally, which probably means this was only ever tested with a VHE kernel (it'd otherwise catch fire). The easiest fix is just to reload the id register before checking it, something like the patch below, compile-tested only. M. =46rom a6c4aaccd33e453ffc8d8ea23a4dd4d9a263cc89 Mon Sep 17 00:00:00 2001 From: Marc Zyngier Date: Mon, 6 Feb 2023 09:24:40 +0000 Subject: [PATCH] arm64/sme: Fix __finalise_el2 SMEver check When checking for ID_AA64SMFR0_EL1.SMEver, __check_override assumes that the ID_AA64SMFR0_EL1 value is in x1, and the intent of the code is to reuse value read a few lines above. However, as the comment says at the beginning of the macro, x1 will be clobbered, and the checks always fails. The easiest fix is just to reload the id register before checking it. Fixes: f122576f3533 ("arm64/sme: Enable host kernel to access ZT0") Signed-off-by: Marc Zyngier --- arch/arm64/kernel/hyp-stub.S | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S index d31d1acb170d..111ff33d93ee 100644 --- a/arch/arm64/kernel/hyp-stub.S +++ b/arch/arm64/kernel/hyp-stub.S @@ -133,6 +133,7 @@ SYM_CODE_START_LOCAL(__finalise_el2) .Lskip_sme_fa64: =20 // ZT0 available? + mrs_s x1, SYS_ID_AA64SMFR0_EL1 __check_override id_aa64smfr0 ID_AA64SMFR0_EL1_SMEver_SHIFT 4 .Linit_sme_= zt0 .Lskip_sme_zt0 .Linit_sme_zt0: orr x0, x0, SMCR_ELx_EZT0_MASK --=20 2.34.1 --=20 Without deviation from the norm, progress is not possible.