Re: [PATCH v4 00/12] KVM: x86/xen: Don't drop event deliveries which race memslot updates

[Sean Christopherson]

On Mon, Oct 19, 2026, David Woodhouse wrote:
> From: David Woodhouse <dwmw@xxxxxxxxxxxx>
> 
> Sashiko analysis and torture testing of the upcoming conversion of the
> gfn_to_pfn_cache from rwlock to atomic SRCU¹ highlighted a pre-existing
> problem: refreshing a cache can fail while a memslot is briefly marked
> KVM_MEMSLOT_INVALID during a memslot update, causing kvm_gpc_refresh() to
> return -EFAULT. The Xen event channel and timer delivery paths silently
> dropped events when this happened.

Gah, sorry for not reacting to versions 1-3, I completely misread the cover letter's
subject or something.

KVM's de facto ABI is that userspace must "pause" vCPUs when modifying memslots.
KVM obviously needs to ensure racing updates don't harm the host, but beyond that,
it's userspace's responsibility to ensure vCPUs can't see mixed state.

> The first patch is a standalone fix which the same testing found: a guest
> parked in SCHEDOP_poll with a zero timeout halts holding vcpu_run's
> kvm->srcu read section — unlike every other halt, which drops it — so the
> VMM's next memslot update hangs, unkillably, in synchronize_srcu() until the
> guest deigns to be woken. A memslot add which normally completes in
> microseconds blocks forever.
> 
> For the KVM_MEMSLOT_INVALID case, in some cases we don't really care very
> much: the VMM should really be using the KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA
> mode which doesn't depend on memslots at all, and more faithfully represents
> the Xen semantics where the shared info page exists whether it's mapped into
> the guest at any given moment or not. But we can be more consistent, and
> more intentional about it. So...

I don't want to be more consistent or intentional though, because that risks
signing KVM up for something it fundamentally can't support.

See also: https://lore.kernel.org/all/20220909104506.738478-1-eesposit@xxxxxxxxxx