[PATCH v3 0/5] KVM: arm64: Add LR overflow infrastructure (the dregs, the bad and the ugly)

[Fuad Tabba]

On Tue, 18 Nov 2025 at 07:20, Oliver Upton <oupton at kernel.org> wrote:
>
> On Mon, Nov 17, 2025 at 09:15:22AM +0000, Marc Zyngier wrote:
> > This is a follow-up to the original series [1] (and fixes [2][3])
> > with a bunch of bug-fixes and improvements. At least one patch has
> > already been posted, but I thought I might repost it as part of a
> > series, since I accumulated more stuff:
> >
> > - The first patch addresses Mark's observation that the no-vgic-v3
> >   test has been broken once more. At some point, we'll have to retire
> >   that functionality, because even if we keep fixing the SR handling,
> >   nobody tests the actual interrupt state exposure to userspace, which
> >   I'm pretty sure has badly been broken for at least 5 years.
> >
> > - The second one addresses a report from Fuad that on QEMU,
> >   ICH_HCR_EL2.TDIR traps ICC_DIR_EL1 on top of ICV_DIR_EL1, leading to
> >   the host exploding on deactivating an interrupt. This behaviour is
> >   allowed by the spec, so make sure we clear all trap bits
> >
> > - Running vgic_irq in an L1 guest (the test being an L2) results in a
> >   MI storm on the host, as the state synchronisation is done at the
> >   wrong place, much like it was on the non-NV path before it was
> >   reworked. Apply the same methods to the NV code, and enjoy much
> >   better MI emulation, now tested all the way into an L3.
> >
> > - Nuke a small leftover from previous rework.
> >
> > - Force a read-back of ICH_MISR_EL2 when disabling the vgic, so that
> >   the trap prevents too many spurious MIs in an L1 guest, as the write
> >   to ICH_HCR_EL2 does exactly nothing on its own when running under
> >   FEAT_NV2.
> >
> > Oliver: this is starting to be a large series of fixes on top of the
> > existing series, plus the two patches you have already added. I'd be
> > happy to respin a full v4 with the fixes squashed into their original
> > patches. On the other hand, if you want to see the history in its full
> > glory, that also works for me.
>
> I'll pick up these patches in a moment but at this point I'd prefer a
> clean history. Plan is to send out the 6.19 pull sometime next week so
> any time before then would be great for v4.

I'm happy to take that for another spin Marc before you send it, if
it's different from the ToT I tested. In that case, just send me a
pointer to the branch.

Cheers,
/fuad

> Thanks for ironing out all the quirks :)
>
> Best,
> Oliver