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

[Marc Zyngier <maz@kernel.org>]

Hi Fuad,

On Tue, 18 Nov 2025 13:59:14 +0000,
Fuad Tabba <tabba@google.com> wrote:
> 
> On Tue, 18 Nov 2025 at 07:20, Oliver Upton <oupton@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.

I've just pushed out a full branch at [1]. Please make sure to merge
kvmarm-fixes-6.18-3 in, as it fixes a couple of nasties (small
conflict expected, but the resolution should be obvious).

For my own testing, I added -rc6 on top.

Note that I didn't take your Tested-by: tags, as you are about to
retest the whole thing anyway. If all goes well (fingers crossed),
Oliver will be able to apply any further tag once I post these
patches.

Thanks,

	M.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/maz/arm-platforms.git/log/?h=kvm-arm64/vgic-lr-overflow

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