[PATCH v2 0/2] KVM: arm64: vgic-its: Fix LPI double mapping and DISCARD

Marc Zyngier maz at kernel.org
Tue Oct 13 04:16:09 PDT 2026


On Tue, 13 Oct 2026 11:50:09 +0100,
Fuad Tabba <fuad.tabba at linux.dev> wrote:
> 
> Hi Marc,
> 
> On Tue, 13 Oct 2026 11:01:44 +0100, Marc Zyngier <maz at kernel.org> wrote:
> [...]
> > Yeah, I now have a series that has the counting pause, your single
> > vcpu pause (fixed to DTRT), and the LPI disabling fix. Patch #2 of
> > this series can probably make use of the single-vcpu stunning.
> 
> I'll rebase the series on that once it's out, with patch 2 using the
> single-vcpu stunning.
> 
> > As for the OUTSIDE_GUEST discussion, I've had a long discussion with
> > Will where we reversed engineered the synchronisation requirements,
> > and concluded that there was nothing to fix on that front (the logic
> > is incredibly subtle and counter-intuitive, but overall sound). This
> > patch is therefore dropped.
> 
> The first [High] issue Sashiko found on patch 2 [1] holds for DISCARD,
> because the fold writes back the pending_latch that DISCARD clears.
> With a 2ms delay after the exit to widen the window, and the DISCARD
> sent at a varying time, the guest in my DISCARD reproducer takes the
> discarded LPI in 13 of 20 runs on v2.
> 
> A vCPU on its way into the guest does the same: it loads its LRs in
> kvm_vgic_flush_hwstate() while it's still OUTSIDE_GUEST_MODE, so
> kvm_arm_halt_guest() doesn't wait for it. With the delay after the
> flush instead, on v2 plus your 1/7 and 2/7 [2] and both changes from
> your reply to 1/7 [3], the guest takes it in 9 of 20 runs.

Does this mean we still need OUTSIDE_GUEST_MODE to be a store-release
past the point where we resync the state?

> Once DISCARD waits for irq->on_lr to clear before clearing
> pending_latch, the guest takes it in none of 20 runs in either case.
> I'll add that to v3, unless the single-vcpu stunning already waits for
> it.

Polling for on_lr feels very dodgy, and I'd like to avoid this. If the
OUTSIDE_GUEST release addresses it, I'd rather do that.

Thanks,

	M.

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



More information about the linux-arm-kernel mailing list