[PATCH v3 0/5] KVM: arm64: Add LR overflow infrastructure (the dregs, the bad and the ugly)
Fuad Tabba
tabba at google.com
Wed Nov 19 02:37:39 PST 2025
Hi Marc,
On Tue, 18 Nov 2025 at 19:06, Marc Zyngier <maz at kernel.org> wrote:
>
> Hi Fuad,
>
> On Tue, 18 Nov 2025 13:59:14 +0000,
> Fuad Tabba <tabba at google.com> wrote:
> >
> > 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.
>
> 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 this branch [1]:
Tested-by: Fuad Tabba <tabba at google.com>
On QEMU, nVHE, hVHE protected mode (non-protected VMs with and without
the Android pKVM patches), and protected VMs (with the Android pKVM
patches).
Cheers,
/fuad
> 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.
More information about the linux-arm-kernel
mailing list