All of lore.kernel.org
 help / color / mirror / Atom feed
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.

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.