[PATCH v2 3/3] KVM: arm64: Limit clearing of ID_{AA64PFR0,PFR1}_EL1.GIC to userspace irqchip

[Marc Zyngier]

On Mon, 10 Nov 2025 14:15:27 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> On Mon, Nov 10, 2025 at 01:11:05PM +0000, Marc Zyngier wrote:
> > Mark Brown <broonie at kernel.org> wrote:
> 
> > > Today's next/pending-fixes is showing regressions on a range of physical
> > > arm64 platforms (including at least a bunch of A53 systems, an A55 one
> > > and an A72 one) in the steal_time selftest which bisect to this patch.
> > > We get asserts in the kernel on ID register sets:
> 
> > Please name the platforms this fails on. Here, on a sample of one A72
> > box, I don't see the issue:
> 
> It looks like it's GICv2 that's affected - I'm seeing this on at least
> Raspberry Pi 3B+ and 4, Pine 64 Plus and Libretech Potato, Solitude and
> Tritum.  The platforms with GICv3 that I have results for (eg, the
> Toradex Verdin i.MX8MP and Mallow AM625) all seem fine.

Yeah, I just found out by exhuming the dusty dregs. As it turns out,
this catches a pre-existing bug that wasn't noticed until we moved
over to the standard accessors rather than bypassing them.

The hack below fixes it for me on XGene.

	M.

diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c
index 3bf7005258f07..19afcd833d6fa 100644
--- a/arch/arm64/kvm/sys_regs.c
+++ b/arch/arm64/kvm/sys_regs.c
@@ -5624,7 +5624,11 @@ int kvm_finalize_sys_regs(struct kvm_vcpu *vcpu)
 
 	guard(mutex)(&kvm->arch.config_lock);
 
-	if (!irqchip_in_kernel(kvm)) {
+	/*
+	 * This hacks into the ID registers, so only perform it when the
+	 * first vcpu runs, or the kvm_set_vm_id_reg() helper will scream.
+	 */
+	if (!irqchip_in_kernel(kvm) && !kvm_vm_has_ran_once(kvm)) {
 		u64 val;
 
 		val = kvm_read_vm_id_reg(kvm, SYS_ID_AA64PFR0_EL1) & ~ID_AA64PFR0_EL1_GIC;



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