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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E2E8CDB465 for ; Thu, 19 Oct 2023 14:08:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345991AbjJSOIA (ORCPT ); Thu, 19 Oct 2023 10:08:00 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235408AbjJSOH4 (ORCPT ); Thu, 19 Oct 2023 10:07:56 -0400 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3613D13E for ; Thu, 19 Oct 2023 07:07:53 -0700 (PDT) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CA561C433C7; Thu, 19 Oct 2023 14:07:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1697724472; bh=cwYxbU4uV9qhjaZqQV147ceVMlmQJtz8w9Ywna095cw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=q+IPTom2FPEiR0CZOXFr3hpsQMqHhZzSOfLuZ4fMGMzkkSPKthZCqwsjdryEL38wI EYAFnimwk7YdRuLJgSdmc5r9H9T8bRXGen40+CloRUQh22n2QkZ5NXTTw/96DvgsN5 kra9MsUIjAP/3HEJmQPF3BdgTGFN13EIXt8s5k2eaFZ1XxllTK9SJzcPY/FDr8N09M hxAKwYCqOo1FfX3gjdBRRQJWK2Z+4nwOZZoFTTuav/9ou2GZrJZ0Flea0bVczYbNIf RjJWhKGQbsbxTPl6zAK3dlnwaohLFrBuHiRVf/kjqOiblmbv3FF+J/eXQ7ydnTpkFD EWUbgOYWu8Daw== 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 1qtTgk-005nGE-3v; Thu, 19 Oct 2023 15:07:50 +0100 Date: Thu, 19 Oct 2023 15:07:48 +0100 Message-ID: <86h6mmn1sb.wl-maz@kernel.org> From: Marc Zyngier To: Miguel Luis Cc: Catalin Marinas , Will Deacon , Oliver Upton , James Morse , Suzuki K Poulose , Zenghui Yu , Jing Zhang , Eric Auger , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "kvmarm@lists.linux.dev" Subject: Re: [PATCH v4 2/3] arm64: Add missing _EL2 encodings In-Reply-To: <21F82E44-6D93-4F4C-8991-F14948673F54@oracle.com> References: <20231016111743.30331-1-miguel.luis@oracle.com> <20231016111743.30331-3-miguel.luis@oracle.com> <86jzrin8nq.wl-maz@kernel.org> <21F82E44-6D93-4F4C-8991-F14948673F54@oracle.com> 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/29.1 (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=UTF-8 Content-Transfer-Encoding: quoted-printable X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: miguel.luis@oracle.com, catalin.marinas@arm.com, will@kernel.org, oliver.upton@linux.dev, james.morse@arm.com, suzuki.poulose@arm.com, yuzenghui@huawei.com, jingzhangos@google.com, eric.auger@redhat.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, kvmarm@lists.linux.dev 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 Thu, 19 Oct 2023 14:23:09 +0100, Miguel Luis wrote: >=20 > Hi Marc, >=20 > > On 19 Oct 2023, at 11:39, Marc Zyngier wrote: > >=20 > > On Mon, 16 Oct 2023 12:17:41 +0100, > > Miguel Luis wrote: > >>=20 > >> Some _EL2 encodings are missing. Add them. > >>=20 > >> Signed-off-by: Miguel Luis > >> --- > >> arch/arm64/include/asm/sysreg.h | 39 +++++++++++++++++++++++++++++++++ > >> 1 file changed, 39 insertions(+) > >>=20 > >> diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/= sysreg.h > >> index ba5db50effec..8653fb67a339 100644 > >> --- a/arch/arm64/include/asm/sysreg.h > >> +++ b/arch/arm64/include/asm/sysreg.h > >=20 > > [...] > >=20 > >> +#define SYS_SDER32_EL2 sys_reg(3, 4, 1, 3, 1) > >=20 > > [...] > >=20 > >> +#define SYS_VSTTBR_EL2 sys_reg(3, 4, 2, 6, 0) > >> +#define SYS_VSTCR_EL2 sys_reg(3, 4, 2, 6, 2) > >=20 > > [...] > >=20 > >> +#define SYS_CNTHVS_TVAL_EL2 sys_reg(3, 4, 14, 4, 0) > >> +#define SYS_CNTHVS_CTL_EL2 sys_reg(3, 4, 14, 4, 1) > >> +#define SYS_CNTHVS_CVAL_EL2 sys_reg(3, 4, 14, 4, 2) > >> +#define SYS_CNTHPS_TVAL_EL2 sys_reg(3, 4, 14, 5, 0) > >> +#define SYS_CNTHPS_CTL_EL2 sys_reg(3, 4, 14, 5, 1) > >> +#define SYS_CNTHPS_CVAL_EL2 sys_reg(3, 4, 14, 5, 2) > >=20 > > While the secure definitions seem correct, what is the rationale > > behind their presence here? They cannot be trapped from non-secure, > > and the pseudocode is pretty explicit: > >=20 > > if !IsCurrentSecurityState(SS_Secure) then > > UNDEFINED; > >=20 > > Given that, they cannot be trapped, handled or accessed from a KVM > > guest, as Linux on arm64 *always* runs non-secure. > >=20 >=20 > Thank you for clarifying. >=20 > Those definitions were needed for the refinement on patch 3 which clearly > didn=E2=80=99t considered that statement beforehand. >=20 > Yet, should we keep them here so they could be used? But that's the whole point: they *cannot* be used. You can't use a secure system register in non-secure, and we *always* run in non-secure, no ifs no buts. If a guest ever uses one of those, it will get an UNDEF exception directly, without any SW intervention, because that's just illegal. KVM will never see it. As far as Linux is concerned, this is purely dead code. M. --=20 Without deviation from the norm, progress is not possible.