[PATCH v3 0/5] KVM: arm64: Add LR overflow infrastructure (the dregs, the bad and the ugly)
Oliver Upton
oupton at kernel.org
Mon Nov 17 23:20:48 PST 2025
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.
Thanks for ironing out all the quirks :)
Best,
Oliver
More information about the linux-arm-kernel
mailing list