On Mon, 2026-10-19 at 17:24 +0100, David Woodhouse wrote: > From: David Woodhouse <[email protected]> > > 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...
smime.p7s
Description: S/MIME cryptographic signature
