Re: [PATCH] KVM: arm64: gic-v3: Only set ICH_HCR traps for v2-on-v3 or v3 guests

[Sean Christopherson <seanjc@google.com>]

On Tue, Oct 21, 2025, Mark Brown wrote:
> On Tue, Oct 07, 2025 at 04:07:13PM +0000, Sascha Bischoff wrote:
> > The ICH_HCR_EL2 traps are used when running on GICv3 hardware, or when
> > running a GICv3-based guest using FEAT_GCIE_LEGACY on GICv5
> > hardware. When running a GICv2 guest on GICv3 hardware the traps are
> > used to ensure that the guest never sees any part of GICv3 (only GICv2
> > is visible to the guest), and when running a GICv3 guest they are used
> > to trap in specific scenarios. They are not applicable for a
> > GICv2-native guest, and won't be applicable for a(n upcoming) GICv5
> > guest.
> 
> v6.18-rc2 introduces a failure in the KVM no-vgic-v3 selftest on what
> appears to be all arm64 platforms with a GICv3 in all of VHE, nVHE and
> pKVM modes:
> 
> # selftests: kvm: no-vgic-v3
> # Random seed: 0x6b8b4567
> # ==== Test Assertion Failure ====
> #   arm64/no-vgic-v3.c:66: handled
> #   pid=3469 tid=3469 errno=4 - Interrupted system call
> #      1	0x0000000000402ff7: test_run_vcpu at no-vgic-v3.c:128
> #      2	0x0000000000402213: test_guest_no_gicv3 at no-vgic-v3.c:155
> #      3	 (inlined by) main at no-vgic-v3.c:174
> #      4	0x0000ffff7fca7543: ?? ??:0
> #      5	0x0000ffff7fca7617: ?? ??:0
> #      6	0x00000000004023af: _start at ??:?
> #   ICC_PMR_EL1 no read trap
> not ok 25 selftests: kvm: no-vgic-v3 # exit=254
> 
> introduced by this patch, which is commit 3193287ddffb and which never
> appeared in -next prior to being merged into mainline.
> 
> It didn't appear in -next since the arm64 KVM fixes tree is not directly
> in -next and it was only pulled into Paolo's tree on Saturday, a few
> hours before Paolo sent his pull request to Linus, so there was no
> opportunity for it to be picked up.  As I've previously suggested it
> does seem like it would be a good idea to include the fixes branches for
> the KVM arch trees in -next (s390 is there, but I don't see the others),

FWIW, "kvm-x86 fixes" is in -next (unless I've screwed up recently), it just gets
routed in via "kvm-x86 next" via an octopus merge.

> and/or to have more cooking time between things being pulled into the
> main KVM fixes branch and being sent to Linus.