[PATCH v1] KVM: arm64: vgic-v4: Don't forward an LPI with no target vCPU

[Fuad Tabba]

On Mon, 12 Oct 2026 at 19:12, Marc Zyngier <maz at kernel.org> wrote:
>
> On Mon, 12 Oct 2026 15:13:51 +0100,
> Fuad Tabba <fuad.tabba at linux.dev> wrote:
> >
> > Hi Marc,
> >
> > On Mon, 12 Oct 2026 12:18:51 +0100, Marc Zyngier <maz at kernel.org> wrote:
> > [...]
> > > Isn't the core problem that we don't correctly handle the UNPRED
> > > double mapping of the same LPI? I'd rather we attack the issue at the
> > > source instead of papering over the consequences.
> > >
> > > I hacked the following, which is obviously untested. Can you give it a
> > > go?
> >
> > With your diff on rc3, the second MAPTI is dropped, and forwarding the
> > vfio-pci MSI to its event leaves the host up.
> >
> > However, a vgic_irq outlives its ITE while the LPI is pending on a
> > vCPU, so the check also drops a legitimate remap: a guest that
> > DISCARDs a pending LPI and then maps it again loses the new mapping.
>
> But this is yet another bug: 5.3.4 is pretty clear that DISCARD should
> get rid of everything (pending bit and mapping). I reckon this is yet
> another case of the initial implementation being overly worried about
> kicking vcpus out of the guest when destructive action is required.
>
> We should fix this.

I'll add a patch to v2 that makes DISCARD clear the pending state,
kicking the vCPUs out of the guest first when the LPI is queued on
one.

Cheers,
/fuad


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