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

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

On Mon, 2026-10-19 at 17:24 +0100, David Woodhouse wrote:
> From: David Woodhouse <dwmw@amazon.co.uk>
> 
> 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...

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6179 bytes --]