[PATCH v2 29/45] KVM: arm64: GICv3: Set ICH_HCR_EL2.TDIR when interrupts overflow LR capacity

[Marc Zyngier]

On Mon, 24 Nov 2025 11:52:07 +0000,
Mark Brown <broonie at kernel.org> wrote:
> 
> [1  <text/plain; us-ascii (quoted-printable)>]
> On Fri, Nov 14, 2025 at 03:02:32PM +0000, Marc Zyngier wrote:
> > Fuad Tabba <tabba at google.com> wrote:
> > > On Sun, 9 Nov 2025 at 17:17, Marc Zyngier <maz at kernel.org> wrote:
> 
> > > > +       /*
> > > > +        * Note that we set the trap irrespective of EOIMode, as that
> > > > +        * can change behind our back without any warning...
> > > > +        */
> > > > +       if (irqs_active_outside_lrs(als))
> > > > +               cpuif->vgic_hcr |= ICH_HCR_EL2_TDIR;
> > > >  }
> 
> > > I just tested these patches as they are on kvmarm/next
> > > 2ea7215187c5759fc5d277280e3095b350ca6a50 ("Merge branch
> > > 'kvm-arm64/vgic-lr-overflow' into kvmarm/next"), without any
> > > additional pKVM patches. I tried running it with pKVM (non-protected)
> > > and with just plain nVHE. In both cases, I get a trap to EL2 (0x18)
> > > when booting a non-protected guest, which triggers a bug in
> > > handle_trap() arch/arm64/kvm/hyp/nvhe/hyp-main.c:706
> 
> > > This trap is happening because of setting this particular trap (TDIR).
> > > Just removing this trap from vgic_v3_configure_hcr() from the ToT on
> > > kvmarm/next boots fine.
> 
> > This is surprising, as I'm not hitting this on actual HW. Are you
> > getting a 0x18 trap? If so, is it coming from the host? Can you
> > correlate the PC with what the host is doing?
> 
> FWIW I am seeing this on i.MX8MP (4xA53+GICv3):
> 
>   https://lava.sirena.org.uk/scheduler/job/2118713#L1044

There are worrying errors way before that, in the VMID allocator init,
and I can't see what the GIC has to do with it. The issue Fuad
reported was at run time, not boot time. so this really doesn't align
with what you are seeing.

	M.

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