From: Nathan Chancellor <nathan@kernel.org>
To: Marc Zyngier <maz@kernel.org>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
kvm@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oupton@kernel.org>,
Zenghui Yu <yuzenghui@huawei.com>,
Alexandru Elisei <alexandru.elisei@arm.com>,
Sascha Bischoff <Sascha.Bischoff@arm.com>,
Quentin Perret <qperret@google.com>,
Fuad Tabba <tabba@google.com>,
Sebastian Ene <sebastianene@google.com>
Subject: Re: [PATCH v2 4/6] KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co
Date: Wed, 21 Jan 2026 16:32:04 -0700 [thread overview]
Message-ID: <20260121233204.GA1507843@ax162> (raw)
In-Reply-To: <86zf67b5oa.wl-maz@kernel.org>
On Wed, Jan 21, 2026 at 10:50:45AM +0000, Marc Zyngier wrote:
> Let me guess: Cortex-A72 or similarly ancient ARM-designed CPUs, as
> hinted by the lack of GICv3 TDIR control? Then these do not have
> FEAT_FGT.
Yeah, Cortex-A72 for the one box and an Ampere Altra Q80-26 (which I
believe is Neoverse-N1 cores?), so indeed, no FGT it seems.
> The issue stems from the fact that as an optimisation, we skip the
> parsing of the FGT trap table on such hardware, which also results in
> the FGT masks of known bits not being updated. We then compute the
> effective feature map, and discover that the two don't match.
>
> It was harmless so far, as we were only dealing with RES0 bits, and
> assuming that anything that wasn't a RES0 bit was a stateful bit. With
> the introduction of RES1 handling, we've run out of luck. To be clear,
> that's just a warning, not a functional issue.
>
> At this point, I don't think the above "optimisation" is worth having.
> This is only done *once*, at boot time, so the gain is extremely
> small. I'd like the checks to be effective irrespective of the HW the
> kernel runs on, which is consistent with what we do for other tables
> describing the architectural state.
>
> Anyway, I came up with the following hack, which performs the checks,
> but avoid inserting the FGT information in the sysreg xarray if the HW
> doesn't support it, as a memory saving measure. Please let me know if
> that helps (it does on my old boxes).
Works for me as well, no warnings on either box with this patch applied.
If it is useful for a follow up submission:
Tested-by: Nathan Chancellor <nathan@kernel.org>
> diff --git a/arch/arm64/kvm/emulate-nested.c b/arch/arm64/kvm/emulate-nested.c
> index 88336336efc9f..fa8fa09de67dc 100644
> --- a/arch/arm64/kvm/emulate-nested.c
> +++ b/arch/arm64/kvm/emulate-nested.c
> @@ -2284,9 +2284,6 @@ int __init populate_nv_trap_config(void)
> kvm_info("nv: %ld coarse grained trap handlers\n",
> ARRAY_SIZE(encoding_to_cgt));
>
> - if (!cpus_have_final_cap(ARM64_HAS_FGT))
> - goto check_mcb;
> -
> for (int i = 0; i < ARRAY_SIZE(encoding_to_fgt); i++) {
> const struct encoding_to_trap_config *fgt = &encoding_to_fgt[i];
> union trap_config tc;
> @@ -2306,6 +2303,15 @@ int __init populate_nv_trap_config(void)
> }
>
> tc.val |= fgt->tc.val;
> +
> + if (!aggregate_fgt(tc)) {
> + ret = -EINVAL;
> + print_nv_trap_error(fgt, "FGT bit is reserved", ret);
> + }
> +
> + if (!cpus_have_final_cap(ARM64_HAS_FGT))
> + continue;
> +
> prev = xa_store(&sr_forward_xa, enc,
> xa_mk_value(tc.val), GFP_KERNEL);
>
> @@ -2313,11 +2319,6 @@ int __init populate_nv_trap_config(void)
> ret = xa_err(prev);
> print_nv_trap_error(fgt, "Failed FGT insertion", ret);
> }
> -
> - if (!aggregate_fgt(tc)) {
> - ret = -EINVAL;
> - print_nv_trap_error(fgt, "FGT bit is reserved", ret);
> - }
> }
> }
>
> @@ -2333,7 +2334,6 @@ int __init populate_nv_trap_config(void)
> kvm_info("nv: %ld fine grained trap handlers\n",
> ARRAY_SIZE(encoding_to_fgt));
>
> -check_mcb:
> for (int id = __MULTIPLE_CONTROL_BITS__; id < __COMPLEX_CONDITIONS__; id++) {
> const enum cgt_group_id *cgids;
>
>
> --
> Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2026-01-21 23:32 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-10 17:30 [PATCH v2 0/6] KVM: arm64: VTCR_EL2 conversion to feature dependency framework Marc Zyngier
2025-12-10 17:30 ` [PATCH v2 1/6] KVM: arm64: Fix EL2 S1 XN handling for hVHE setups Marc Zyngier
2025-12-11 13:37 ` Fuad Tabba
2025-12-11 14:30 ` Marc Zyngier
2025-12-19 13:38 ` Leonardo Bras
2025-12-19 14:13 ` Marc Zyngier
2026-01-10 10:22 ` (subset) " Oliver Upton
2025-12-10 17:30 ` [PATCH v2 2/6] arm64: Convert ID_AA64MMFR0_EL1.TGRAN{4,16,64}_2 to UnsignedEnum Marc Zyngier
2025-12-11 13:38 ` Fuad Tabba
2025-12-10 17:30 ` [PATCH v2 3/6] arm64: Convert VTCR_EL2 to sysreg infratructure Marc Zyngier
2025-12-11 14:13 ` Fuad Tabba
2025-12-10 17:30 ` [PATCH v2 4/6] KVM: arm64: Account for RES1 bits in DECLARE_FEAT_MAP() and co Marc Zyngier
2025-12-11 14:30 ` Fuad Tabba
2025-12-11 17:23 ` Sascha Bischoff
2026-01-20 21:15 ` Nathan Chancellor
2026-01-21 10:50 ` Marc Zyngier
2026-01-21 23:32 ` Nathan Chancellor [this message]
2025-12-10 17:30 ` [PATCH v2 5/6] KVM: arm64: Convert VTCR_EL2 to config-driven sanitisation Marc Zyngier
2025-12-11 14:44 ` Fuad Tabba
2025-12-10 17:30 ` [PATCH v2 6/6] KVM: arm64: Honor UX/PX attributes for EL2 S1 mappings Marc Zyngier
2025-12-11 14:51 ` Fuad Tabba
2025-12-11 15:18 ` Joey Gouly
2025-12-11 16:21 ` Marc Zyngier
2025-12-12 16:00 ` Joey Gouly
2025-12-11 14:55 ` [PATCH v2 0/6] KVM: arm64: VTCR_EL2 conversion to feature dependency framework Fuad Tabba
2026-01-15 11:49 ` Marc Zyngier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260121233204.GA1507843@ax162 \
--to=nathan@kernel.org \
--cc=Sascha.Bischoff@arm.com \
--cc=alexandru.elisei@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=maz@kernel.org \
--cc=oupton@kernel.org \
--cc=qperret@google.com \
--cc=sebastianene@google.com \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox