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 A6308D15DB3 for ; Wed, 3 Dec 2025 16:43:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Type:MIME-Version: References:In-Reply-To:Subject:Cc:To:From:Message-ID:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=5c+nc7S6m4RRgh7CUsFpa4LcPLmdMoyUNCHEdFI1R7Y=; b=TJTBzrvvOw5/RYBwtEPxyO+rqb 9yr6WcvB44glPjrmNK4wN2XwTW6mnK6c4IEbIz7IBBoyijoTFESlPv2eFuRewdIgK77Hlpy2aO9VG no29f6PUb41Z0Cvzb7w6DHvWEbCBEw8CCQjzA0WTAVBhoYTC/s8sbYwysJeswuXlaJ1sVG4ZmgCWV 4SqgE8+xzhXiss0my8/hmhl6DWwEtaQp3r4RSDbrnB83xCW7Dm8GlD+Yunz4gAsJD0XLTmrDh1yb9 Yl2DcH8+HR1kHt7wwhqo2XRdROY/IirB/tjneNjkgxMsog+lWxaOeaBIccuAjwG0xB28kNz0mgpT4 Doo3fHYg==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vQpx3-00000006oxU-33ID; Wed, 03 Dec 2025 16:43:37 +0000 Received: from sea.source.kernel.org ([2600:3c0a:e001:78e:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vQpx1-00000006ox5-2SWE for linux-arm-kernel@lists.infradead.org; Wed, 03 Dec 2025 16:43:36 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sea.source.kernel.org (Postfix) with ESMTP id 42A8D438B1; Wed, 3 Dec 2025 16:43:34 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 230B0C4CEF5; Wed, 3 Dec 2025 16:43:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764780214; bh=iyflUZchaw873FTzogwUNqRT8cclH8+Swqz8EPmoL5w=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CA29AkXSlTUEp4TCKC8TjYGZYOKPd7DJierroBKco/xQli3ma3HoMF9l3c6PHRdya jn0FuRwOgU8vlGAA18fWSxmbb2JYp0V60Fo9NO6UZRgRDpPNnObaaSjXFUenWstB4d RX9+AEOh0SUG7hMiiXnCgLzluYqH8tFVr06KHaiSlQyA4UTxM6Ft85SKI7nY+rPW63 wxzUaIGBLxg62Z3EMxd/SKSHs5niGm/vb/7o/fSh1hGblzPKepAHg1nijjeYC6oWbR vyi7w+lsxnnkZuvJ6eWUpI8PNTOuU+Y7kdL3QaREIITPtwOpY29PZE59u62LJOVeAv ooqXhHdtZoEXA== 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.98.2) (envelope-from ) id 1vQpwx-0000000AEDg-38lh; Wed, 03 Dec 2025 16:43:31 +0000 Date: Wed, 03 Dec 2025 16:43:31 +0000 Message-ID: <86fr9rplcc.wl-maz@kernel.org> From: Marc Zyngier To: Joey Gouly Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Suzuki K Poulose , Oliver Upton , Zenghui Yu , Alexandru Elisei Subject: Re: [PATCH 4/4] KVM: arm64: Convert VTCR_EL2 to config-driven sanitisation In-Reply-To: <20251203161715.GA4187196@e124191.cambridge.arm.com> References: <20251129144525.2609207-1-maz@kernel.org> <20251129144525.2609207-5-maz@kernel.org> <20251203161715.GA4187196@e124191.cambridge.arm.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/30.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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: joey.gouly@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com, alexandru.elisei@arm.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20251203_084335_663995_0F8062CB X-CRM114-Status: GOOD ( 26.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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, 03 Dec 2025 16:17:15 +0000, Joey Gouly wrote: > > Hi! > > On Sat, Nov 29, 2025 at 02:45:25PM +0000, Marc Zyngier wrote: > > Describe all the VTCR_EL2 fields and their respective configurations, > > making sure that we correctly ignore the bits that are not defined > > for a given guest configuration. > > > > Signed-off-by: Marc Zyngier > > --- > > arch/arm64/kvm/config.c | 69 +++++++++++++++++++++++++++++++++++++++++ > > arch/arm64/kvm/nested.c | 3 +- > > 2 files changed, 70 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arm64/kvm/config.c b/arch/arm64/kvm/config.c > > index a02c28d6a61c9..c36e133c51912 100644 > > --- a/arch/arm64/kvm/config.c > > +++ b/arch/arm64/kvm/config.c > > @@ -141,6 +141,7 @@ struct reg_feat_map_desc { > > #define FEAT_AA64EL1 ID_AA64PFR0_EL1, EL1, IMP > > #define FEAT_AA64EL2 ID_AA64PFR0_EL1, EL2, IMP > > #define FEAT_AA64EL3 ID_AA64PFR0_EL1, EL3, IMP > > +#define FEAT_SEL2 ID_AA64PFR0_EL1, SEL2, IMP > > #define FEAT_AIE ID_AA64MMFR3_EL1, AIE, IMP > > #define FEAT_S2POE ID_AA64MMFR3_EL1, S2POE, IMP > > #define FEAT_S1POE ID_AA64MMFR3_EL1, S1POE, IMP > > @@ -202,6 +203,8 @@ struct reg_feat_map_desc { > > #define FEAT_ASID2 ID_AA64MMFR4_EL1, ASID2, IMP > > #define FEAT_MEC ID_AA64MMFR3_EL1, MEC, IMP > > #define FEAT_HAFT ID_AA64MMFR1_EL1, HAFDBS, HAFT > > +#define FEAT_HDBSS ID_AA64MMFR1_EL1, HAFDBS, HDBSS > > +#define FEAT_HPDS2 ID_AA64MMFR1_EL1, HPDS, HPDS2 > > #define FEAT_BTI ID_AA64PFR1_EL1, BT, IMP > > #define FEAT_ExS ID_AA64MMFR0_EL1, EXS, IMP > > #define FEAT_IESB ID_AA64MMFR2_EL1, IESB, IMP > > @@ -219,6 +222,7 @@ struct reg_feat_map_desc { > > #define FEAT_FGT2 ID_AA64MMFR0_EL1, FGT, FGT2 > > #define FEAT_MTPMU ID_AA64DFR0_EL1, MTPMU, IMP > > #define FEAT_HCX ID_AA64MMFR1_EL1, HCX, IMP > > +#define FEAT_S2PIE ID_AA64MMFR3_EL1, S2PIE, IMP > > > > static bool not_feat_aa64el3(struct kvm *kvm) > > { > > @@ -362,6 +366,28 @@ static bool feat_pmuv3p9(struct kvm *kvm) > > return check_pmu_revision(kvm, V3P9); > > } > > > > +#define has_feat_s2tgran(k, s) \ > > + ((kvm_has_feat_enum(kvm, ID_AA64MMFR0_EL1, TGRAN##s##_2, TGRAN##s) && \ > > + !kvm_has_feat_enum(kvm, ID_AA64MMFR0_EL1, TGRAN##s, NI)) || \ > > + kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN##s##_2, IMP)) > > + > > +static bool feat_lpa2(struct kvm *kvm) > > +{ > > + return ((kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN4, 52_BIT) || > > + !kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN4, IMP)) && > > + (kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN16, 52_BIT) || > > + !kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN16, IMP)) && > > + (kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN4_2, 52_BIT) || > > + !has_feat_s2tgran(kvm, 4)) && > > + (kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN16_2, 52_BIT) || > > + !has_feat_s2tgran(kvm, 16))); > > +} > > + > > +static bool feat_vmid16(struct kvm *kvm) > > +{ > > + return kvm_has_feat_enum(kvm, ID_AA64MMFR1_EL1, VMIDBits, 16); > > +} > > + > > static bool compute_hcr_rw(struct kvm *kvm, u64 *bits) > > { > > /* This is purely academic: AArch32 and NV are mutually exclusive */ > > @@ -1168,6 +1194,44 @@ static const struct reg_bits_to_feat_map mdcr_el2_feat_map[] = { > > static const DECLARE_FEAT_MAP(mdcr_el2_desc, MDCR_EL2, > > mdcr_el2_feat_map, FEAT_AA64EL2); > > > > +static const struct reg_bits_to_feat_map vtcr_el2_feat_map[] = { > > + NEEDS_FEAT(VTCR_EL2_HDBSS, FEAT_HDBSS), > > + NEEDS_FEAT(VTCR_EL2_HAFT, FEAT_HAFT), > > + NEEDS_FEAT(VTCR_EL2_TL0 | > > + VTCR_EL2_TL1 | > > + VTCR_EL2_AssuredOnly | > > + VTCR_EL2_GCSH, > > + FEAT_THE), > > The text for VTCR_EL2.AssuredOnly says: > > This field is RES0 when VTCR_EL2.D128 is 1. > > > + NEEDS_FEAT(VTCR_EL2_D128, FEAT_D128), > > + NEEDS_FEAT(VTCR_EL2_S2POE, FEAT_S2POE), > > + NEEDS_FEAT(VTCR_EL2_S2PIE, FEAT_S2PIE), > > The text for VTCR_EL2.S2PIE says: > > This field is RES1 when VTCR_EL2.D128 is set. > > > Are these cases that need to be handled here somehow? These are not static configurations. They are dynamic behaviours depending on other control bits. D128 code, if it ever exists, will have to *interpret* these bits as RES0 (resp. RES1) when evaluating the page tables. If you want a similar example in existing code, look at the way we handle TCR_EL1.HPDn in the S1 PTW. They are treated as RES1 if TCR2_EL1.PIE is set, as per R_JHSVW. Thanks, M. -- Without deviation from the norm, progress is not possible.