public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Suzuki K Poulose <suzuki.poulose@arm.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
	kvm@vger.kernel.org, Joey Gouly <joey.gouly@arm.com>,
	Oliver Upton <oupton@kernel.org>,
	Zenghui Yu <yuzenghui@huawei.com>,
	Christoffer Dall <christoffer.dall@arm.com>,
	Fuad Tabba <tabba@google.com>, Mark Brown <broonie@kernel.org>
Subject: Re: [PATCH v4 06/49] KVM: arm64: GICv3: Detect and work around the lack of ICV_DIR_EL1 trapping
Date: Tue, 25 Nov 2025 15:01:18 +0000	[thread overview]
Message-ID: <86fra2qhq9.wl-maz@kernel.org> (raw)
In-Reply-To: <e67decb6-20a5-4659-8401-8534049f9229@arm.com>

On Tue, 25 Nov 2025 14:14:25 +0000,
Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> 
> On 25/11/2025 13:48, Marc Zyngier wrote:
> > On Tue, 25 Nov 2025 11:26:10 +0000,
> > Suzuki K Poulose <suzuki.poulose@arm.com> wrote:
> >> 
> >> On 20/11/2025 17:24, Marc Zyngier wrote:
> >>> A long time ago, an unsuspecting architect forgot to add a trap
> >>> bit for ICV_DIR_EL1 in ICH_HCR_EL2. Which was unfortunate, but
> >>> what's a bit of spec between friends? Thankfully, this was fixed
> >>> in a later revision, and ARM "deprecates" the lack of trapping
> >>> ability.
> >>> 
> >>> Unfortuantely, a few (billion) CPUs went out with that defect,
> >>> anything ARMv8.0 from ARM, give or take. And on these CPUs,
> >>> you can't trap DIR on its own, full stop.
> >>> 
> >>> As the next best thing, we can trap everything in the common group,
> >>> which is a tad expensive, but hey ho, that's what you get. You can
> >>> otherwise recycle the HW in the neaby bin.
> >>> 
> >>> Tested-by: Fuad Tabba <tabba@google.com>
> >>> Signed-off-by: Marc Zyngier <maz@kernel.org>
> >>> ---
> >>>    arch/arm64/include/asm/virt.h  |  7 ++++-
> >>>    arch/arm64/kernel/cpufeature.c | 52 ++++++++++++++++++++++++++++++++++
> >>>    arch/arm64/kernel/hyp-stub.S   |  5 ++++
> >>>    arch/arm64/kvm/vgic/vgic-v3.c  |  3 ++
> >>>    arch/arm64/tools/cpucaps       |  1 +
> >>>    5 files changed, 67 insertions(+), 1 deletion(-)
> >>> 
> >>> diff --git a/arch/arm64/include/asm/virt.h b/arch/arm64/include/asm/virt.h
> >>> index aa280f356b96a..8eb63d3294974 100644
> >>> --- a/arch/arm64/include/asm/virt.h
> >>> +++ b/arch/arm64/include/asm/virt.h
> >>> @@ -40,8 +40,13 @@
> >>>     */
> >>>    #define HVC_FINALISE_EL2	3
> >>>    +/*
> >>> + * HVC_GET_ICH_VTR_EL2 - Retrieve the ICH_VTR_EL2 value
> >>> + */
> >>> +#define HVC_GET_ICH_VTR_EL2	4
> >>> +
> >>>    /* Max number of HYP stub hypercalls */
> >>> -#define HVC_STUB_HCALL_NR 4
> >>> +#define HVC_STUB_HCALL_NR 5
> >>>      /* Error returned when an invalid stub number is passed into x0
> >>> */
> >>>    #define HVC_STUB_ERR	0xbadca11
> >>> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> >>> index 5ed401ff79e3e..5de51cb1b8fe2 100644
> >>> --- a/arch/arm64/kernel/cpufeature.c
> >>> +++ b/arch/arm64/kernel/cpufeature.c
> >>> @@ -2303,6 +2303,49 @@ static bool has_gic_prio_relaxed_sync(const struct arm64_cpu_capabilities *entry
> >>>    }
> >>>    #endif
> >>>    +static bool can_trap_icv_dir_el1(const struct
> >>> arm64_cpu_capabilities *entry,
> >>> +				 int scope)
> >>> +{
> >>> +	static const struct midr_range has_vgic_v3[] = {
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M1_ICESTORM),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M1_FIRESTORM),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M1_ICESTORM_PRO),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M1_FIRESTORM_PRO),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M1_ICESTORM_MAX),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M1_FIRESTORM_MAX),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M2_BLIZZARD),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M2_AVALANCHE),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M2_BLIZZARD_PRO),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M2_AVALANCHE_PRO),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M2_BLIZZARD_MAX),
> >>> +		MIDR_ALL_VERSIONS(MIDR_APPLE_M2_AVALANCHE_MAX),
> >>> +		{},
> >>> +	};
> >>> +	struct arm_smccc_res res = {};
> >>> +
> >>> +	BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDIR <= ARM64_HAS_GICV3_CPUIF);
> >>> +	BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDIR <= ARM64_HAS_GICV5_LEGACY);
> >>> +	if (!cpus_have_cap(ARM64_HAS_GICV3_CPUIF) &&
> >>> +	    !is_midr_in_range_list(has_vgic_v3))
> >>> +		return false;
> >>> +
> >>> +	if (!is_hyp_mode_available())
> >>> +		return false;
> >>> +
> >>> +	if (cpus_have_cap(ARM64_HAS_GICV5_LEGACY))
> >>> +		return true;
> >>> +
> >>> +	if (is_kernel_in_hyp_mode())
> >>> +		res.a1 = read_sysreg_s(SYS_ICH_VTR_EL2);
> >>> +	else
> >>> +		arm_smccc_1_1_hvc(HVC_GET_ICH_VTR_EL2, &res);
> >> 
> >> We are reading the register on the current CPU and this capability,
> >> being a SYSTEM_FEATURE, relies on the "probing CPU". If there CPUs
> >> with differing values (which I don't think is practical, but hey,
> >> never say..). This is would better be a
> >> ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE, which would run through all
> >> boot CPUs and would set the capability when it matches.
> > 
> > While I agree that SYSTEM_FEATURE is most probably the wrong thing, I
> > can't help but notice that
> > 
> > - ARM64_HAS_GICV3_CPUIF,
> > - ARM64_HAS_GIC_PRIO_MASKING
> > - ARM64_HAS_GIC_PRIO_RELAXED_SYNC
> > 
> > are all ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE.
> 
> Which means, if GICV3_CPUIF is set any booting CPU must have them.
> 
> > 
> > On the other ARM64_HAS_GICV5_LEGACY is ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE.
> > 
> > Given that ARM64_HAS_ICH_HCR_EL2_TDIR is dependent on both
> > ARM64_HAS_GICV3_CPUIF and ARM64_HAS_GICV5_LEGACY, shouldn't these two
> > (and their dependencies) be aligned to have the same behaviour?
> 
> Yes, but it also depends on how you are detecting the feature.
> 
> BOOT_CPU_FEATURES are finalized with BOOT CPU and thusanything that
> boots up later must have it. So it is fine, as long
> as a SYSTEM cap depends on it and can do its own additional checks
> in a system wide safe manner.

I had a quick go at it, and things are a bit murky. As it turns out,
the GICv3 stuff is STRICT_BOOT_CPU_FEATURE because we need the GIC
super early, before secondary CPUs can be brought up.

However, virtualisation-specific features only get used way down the
line, so both ICH_HCR_EL2_TDIR and GICV5_LEGACY can be delayed until
all CPUs have booted.

> But in your case, we a have SYSTEM cap, which only performs the check
> on the "running CPU" and not considering a system wide safe value for
> ICH_VTR_EL2_TDS. In order to do this, we need to switch to something
> like the GICV5_LEGACY cap, which chooses to perform the check on all
> booting CPUs (as we don't keep the system wide safe value for the
> bit it is looking for).
>
> e.g., your cap may be incorrectly SET, when the BOOT cpu (which
> mostly runs the SYSTEM scope), but another CPU didn't have the
> ICH_VTR_EL2_TDS.

Yup, that's the conclusion I also came to.

> Does that help ?

It does. I came up with the fix below, which I'll spin as a patch shortly.

Thanks,

	M.

diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
index ff2b05f7226a9..c840a93b9ef95 100644
--- a/arch/arm64/kernel/cpufeature.c
+++ b/arch/arm64/kernel/cpufeature.c
@@ -2326,14 +2326,14 @@ static bool can_trap_icv_dir_el1(const struct arm64_cpu_capabilities *entry,
 
 	BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDIR <= ARM64_HAS_GICV3_CPUIF);
 	BUILD_BUG_ON(ARM64_HAS_ICH_HCR_EL2_TDIR <= ARM64_HAS_GICV5_LEGACY);
-	if (!cpus_have_cap(ARM64_HAS_GICV3_CPUIF) &&
+	if (!this_cpu_has_cap(ARM64_HAS_GICV3_CPUIF) &&
 	    !is_midr_in_range_list(has_vgic_v3))
 		return false;
 
 	if (!is_hyp_mode_available())
 		return false;
 
-	if (cpus_have_cap(ARM64_HAS_GICV5_LEGACY))
+	if (this_cpu_has_cap(ARM64_HAS_GICV5_LEGACY))
 		return true;
 
 	if (is_kernel_in_hyp_mode())
@@ -2864,7 +2864,7 @@ static const struct arm64_cpu_capabilities arm64_features[] = {
 		 */
 		.desc = "ICV_DIR_EL1 trapping",
 		.capability = ARM64_HAS_ICH_HCR_EL2_TDIR,
-		.type = ARM64_CPUCAP_SYSTEM_FEATURE,
+		.type = ARM64_CPUCAP_EARLY_LOCAL_CPU_FEATURE,
 		.matches = can_trap_icv_dir_el1,
 	},
 #ifdef CONFIG_ARM64_E0PD

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2025-11-25 15:01 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-20 17:24 [PATCH v4 00/49] KVM: arm64: Add LR overflow infrastructure (the final one, I swear!) Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 01/49] irqchip/gic: Add missing GICH_HCR control bits Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 02/49] irqchip/gic: Expose CPU interface VA to KVM Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 03/49] irqchip/apple-aic: Spit out ICH_MISR_EL2 value on spurious vGIC MI Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 04/49] KVM: arm64: Turn vgic-v3 errata traps into a patched-in constant Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 05/49] KVM: arm64: vgic-v3: Fix GICv3 trapping in protected mode Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 06/49] KVM: arm64: GICv3: Detect and work around the lack of ICV_DIR_EL1 trapping Marc Zyngier
2025-11-25 11:26   ` Suzuki K Poulose
2025-11-25 13:48     ` Marc Zyngier
2025-11-25 14:14       ` Suzuki K Poulose
2025-11-25 15:01         ` Marc Zyngier [this message]
2025-11-25 15:03           ` Suzuki K Poulose
2025-11-20 17:24 ` [PATCH v4 07/49] KVM: arm64: Repack struct vgic_irq fields Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 08/49] KVM: arm64: Add tracking of vgic_irq being present in a LR Marc Zyngier
2025-11-20 17:24 ` [PATCH v4 09/49] KVM: arm64: Add LR overflow handling documentation Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 10/49] KVM: arm64: GICv3: Drop LPI active state when folding LRs Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 11/49] KVM: arm64: GICv3: Preserve EOIcount on exit Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 12/49] KVM: arm64: GICv3: Decouple ICH_HCR_EL2 programming from LRs Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 13/49] KVM: arm64: GICv3: Extract LR folding primitive Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 14/49] KVM: arm64: GICv3: Extract LR computing primitive Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 15/49] KVM: arm64: GICv2: Preserve EOIcount on exit Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 16/49] KVM: arm64: GICv2: Decouple GICH_HCR programming from LRs being loaded Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 17/49] KVM: arm64: GICv2: Extract LR folding primitive Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 18/49] KVM: arm64: GICv2: Extract LR computing primitive Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 19/49] KVM: arm64: Compute vgic state irrespective of the number of interrupts Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 20/49] KVM: arm64: Eagerly save VMCR on exit Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 21/49] KVM: arm64: Revamp vgic maintenance interrupt configuration Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 22/49] KVM: arm64: Turn kvm_vgic_vcpu_enable() into kvm_vgic_vcpu_reset() Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 23/49] KVM: arm64: Make vgic_target_oracle() globally available Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 24/49] KVM: arm64: Invert ap_list sorting to push active interrupts out Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 25/49] KVM: arm64: Move undeliverable interrupts to the end of ap_list Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 26/49] KVM: arm64: Use MI to detect groups being enabled/disabled Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 27/49] KVM: arm64: GICv3: Handle LR overflow when EOImode==0 Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 28/49] KVM: arm64: GICv3: Handle deactivation via ICV_DIR_EL1 traps Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 29/49] KVM: arm64: GICv3: Add GICv2 SGI handling to deactivation primitive Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 30/49] KVM: arm64: GICv3: Set ICH_HCR_EL2.TDIR when interrupts overflow LR capacity Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 31/49] KVM: arm64: GICv3: Add SPI tracking to handle asymmetric deactivation Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 32/49] KVM: arm64: GICv3: Handle in-LR deactivation when possible Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 33/49] KVM: arm64: GICv3: Avoid broadcast kick on CPUs lacking TDIR Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 34/49] KVM: arm64: GICv3: nv: Resync LRs/VMCR/HCR early for better MI emulation Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 35/49] KVM: arm64: GICv3: nv: Plug L1 LR sync into deactivation primitive Marc Zyngier
2026-03-30 11:51   ` Vishnu Pajjuri
2026-03-30 12:17     ` Marc Zyngier
2026-03-31  6:31       ` Vishnu Pajjuri
2026-03-31  9:42         ` Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 36/49] KVM: arm64: GICv3: Force exit to sync ICH_HCR_EL2.En Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 37/49] KVM: arm64: GICv2: Handle LR overflow when EOImode==0 Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 38/49] KVM: arm64: GICv2: Handle deactivation via GICV_DIR traps Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 39/49] KVM: arm64: GICv2: Always trap GICV_DIR register Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 40/49] KVM: arm64: selftests: gic_v3: Add irq group setting helper Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 41/49] KVM: arm64: selftests: gic_v3: Disable Group-0 interrupts by default Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 42/49] KVM: arm64: selftests: vgic_irq: Fix GUEST_ASSERT_IAR_EMPTY() helper Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 43/49] KVM: arm64: selftests: vgic_irq: Change configuration before enabling interrupt Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 44/49] KVM: arm64: selftests: vgic_irq: Exclude timer-controlled interrupts Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 45/49] KVM: arm64: selftests: vgic_irq: Remove LR-bound limitation Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 46/49] KVM: arm64: selftests: vgic_irq: Perform EOImode==1 deactivation in ack order Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 47/49] KVM: arm64: selftests: vgic_irq: Add asymmetric SPI deaectivation test Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 48/49] KVM: arm64: selftests: vgic_irq: Add Group-0 enable test Marc Zyngier
2025-11-20 17:25 ` [PATCH v4 49/49] KVM: arm64: selftests: vgic_irq: Add timer deactivation test Marc Zyngier
2025-11-21 14:15 ` [PATCH v4 00/49] KVM: arm64: Add LR overflow infrastructure (the final one, I swear!) Mark Brown
2025-11-24 22:44 ` Oliver Upton

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=86fra2qhq9.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=broonie@kernel.org \
    --cc=christoffer.dall@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=oupton@kernel.org \
    --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