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

[Sean Christopherson]

On Tue, Nov 03, 2026, David Woodhouse wrote:
> On Mon, 2026-10-19 at 17:24 +0100, 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.
> 
> Meh, it isn't even just GPC that's affected by this — anything that
> uses kvm_write_guest() can get a spurious -EFAULT if it happens during
> a memslot update.
> 
> I just think that until I started torture-testing the GPC SRCU
> conversion, nobody ever cared because in practice we *don't* delete or
> split the memslots which KVM is actually trying to write to.
> 
> I'm tempted to drop the whole -EAGAIN part of the series and the retry
> attempts, and continue our historical stance of not caring.
> 
> I'll just keep the other incidental bugfixes I've found along the way
> (especially the SCHEDOP_poll vs. srcu one).
> 
> The Xen use case is actually the easy one, as userspace really ought to
> be using KVM_XEN_ATTR_TYPE_SHARED_INFO_HVA for that anyway and
> shouldn't be affected by memslots at all. I can update the GPC-SRCU
> torture testing to do that, and pretend I never spotted the transient
> invalidity...

Apparently I suck extra hard at reading today.  I responded to the cover letter
with basically the same response, and _then_ I saw this.  /facepalm

At least we're in general agreement.  I've got patch 1 earmarked, so no need to
resend that one.