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 76C26D12D5B for ; Wed, 3 Dec 2025 13:01:13 +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=GYeE0a6gX48v5auImLZZV4Hz/PKmAe32sGIthOVY+5o=; b=Kx6RfUVmL8DfbaEnQwi+5uwyP+ eNZbHbdXkoB6M2vCZXGvbfhWUhhoSZ3vrUOmLIRAwPDSReX71mn5ZYlT1qv9VsQ84/oWIogzNa+0w q35A7C8zdd9ABAzco2S8EiVETXi4v7WYX4rJri2MM23Ypi186n9SchDHDS/s1KlbSrSRY1ZTdW0Vg jtHk/Rp3nMLPvNIaLeeTNRAYNCiBuPa8KL6nxv9a6y8hmXQjJBM78btuPuLgHLOHfAcUdXZnbP8Xz JrkEM5aJhi1RllL7yt0J11rDT5XTbzhPZPplOSfIm9FEwq/Rjzio5MudXcXyLz7ivYWpKeBnyOJvC LKKFj68w==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98.2 #2 (Red Hat Linux)) id 1vQmTh-00000006aCe-1G16; Wed, 03 Dec 2025 13:01:05 +0000 Received: from tor.source.kernel.org ([2600:3c04:e001:324:0:1991:8:25]) by bombadil.infradead.org with esmtps (Exim 4.98.2 #2 (Red Hat Linux)) id 1vQmTe-00000006aCY-0dpT for linux-arm-kernel@lists.infradead.org; Wed, 03 Dec 2025 13:01:03 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id EDC676019A; Wed, 3 Dec 2025 13:01:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9B75FC4CEFB; Wed, 3 Dec 2025 13:01:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764766860; bh=94NMNh/bjL/9IvXfEznPqaXJhPlPZ/AXgR/yH/tDbeg=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=qoECoH7adV+Eew2kED6UQJrbbAyDfCHVND9/PRkXMYUbwlAkGq1XMtxj8jND6ehtj GjhBG5Ubi7lmlUzHkOs/YzOzvxMKnerM65N+Vrgr1nT69oCHTehX9956dH8shLmV/4 vdjBGU5mejHUoR/goRSZ9Sxi3QzSic2kigDhhnAPv/xTP6YavyxYC+f458Rd5xghm6 YgmSMgpM6H+vNU8p5/n1Wr9VjbmYgQFKWcTUnFUVk8YChzTDPQK3Xn8Mk2dIQcuKYY 5y3o0YBpu94T9pmVusQ/JhBJ1zV20g6EzvX632dVkxvVRMbS909wCNxO0SaZz88xLw +b+0qvES9OnNw== 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 1vQmTZ-0000000ABPW-3tA8; Wed, 03 Dec 2025 13:00:58 +0000 Date: Wed, 03 Dec 2025 13:00:57 +0000 Message-ID: <86ikenpvna.wl-maz@kernel.org> From: Marc Zyngier To: Alexandru Elisei Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, Joey Gouly , Suzuki K Poulose , Oliver Upton , Zenghui Yu Subject: Re: [PATCH 4/4] KVM: arm64: Convert VTCR_EL2 to config-driven sanitisation In-Reply-To: References: <20251129144525.2609207-1-maz@kernel.org> <20251129144525.2609207-5-maz@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/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: alexandru.elisei@arm.com, kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org, kvm@vger.kernel.org, joey.gouly@arm.com, suzuki.poulose@arm.com, oupton@kernel.org, yuzenghui@huawei.com X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false 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 11:44:14 +0000, Alexandru Elisei wrote: > > Hi Marc, > > 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)) || \ > > Wouldn't that read better as kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN##s, IMP)? > I think that would also be correct. Sure, I don't mind either way, > > > + kvm_has_feat(kvm, ID_AA64MMFR0_EL1, TGRAN##s##_2, IMP)) > > A bit unexpected to treat the same field first as an enum, then as an integer, > but it saves one line. It potentially saves more if the encoding grows over time. I don't think it matters. > > > + > > +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))); > > +} > > That was a doozy, but looks correct to me if the intention was to have the check > as relaxed as possible - i.e, a VM can advertise 52 bit support for one granule, > but not the other (same for stage 1 and stage 2). Not quite. The intent is that, for all the possible granules, at all the possible stages, either the granule size isn't implemented at all, or it supports 52 bits. I think this covers it, but as you said, this is a bit of a bran fsck. This is essentially a transliteration of the MRS: (FEAT_LPA2 && FEAT_S2TGran4K) <=> (UInt(ID_AA64MMFR0_EL1.TGran4_2) >= 3)) (FEAT_LPA2 && FEAT_S2TGran16K) <=> (UInt(ID_AA64MMFR0_EL1.TGran16_2) >= 3)) (FEAT_LPA2 && FEAT_TGran4K) <=> (SInt(ID_AA64MMFR0_EL1.TGran4) >= 1)) (FEAT_LPA2 && FEAT_TGran16K) <=> (UInt(ID_AA64MMFR0_EL1.TGran16) >= 2)) FEAT_S2TGran4K <=> (((UInt(ID_AA64MMFR0_EL1.TGran4_2) == 0) && FEAT_TGran4K) || (UInt(ID_AA64MMFR0_EL1.TGran4_2) >= 2)) FEAT_S2TGran16K <=> (((UInt(ID_AA64MMFR0_EL1.TGran16_2) == 0) && FEAT_TGran16K) || (UInt(ID_AA64MMFR0_EL1.TGran16_2) >= 2)) FEAT_TGran4K <=> (SInt(ID_AA64MMFR0_EL1.TGran4) >= 0) FEAT_TGran16K <=> (UInt(ID_AA64MMFR0_EL1.TGran16) >= 1) > As far as I can tell, everything looks good to me: > > Reviewed-by: Alexandru Elisei Thanks, M. -- Without deviation from the norm, progress is not possible.