Re: [PATCH v4 02/10] KVM: pfncache: Restore guest-uses-pfn support

[Sean Christopherson <seanjc@google.com>]

On Mon, Jun 01, 2026, David Woodhouse wrote:
> On Fri, 2026-01-02 at 14:24 +0000, Fred Griffoul wrote:
> > 
> > @@ -55,6 +70,27 @@ void gfn_to_pfn_cache_invalidate_start(struct kvm *kvm, unsigned long start,
> >  		read_unlock_irq(&gpc->lock);
> >  	}
> >  	spin_unlock(&kvm->gpc_lock);
> > +
> > +	if (evict_vcpus) {
> > +		/*
> > +		 * KVM needs to ensure the vCPU is fully out of guest context
> > +		 * before allowing the invalidation to continue.
> > +		 */
> > +		unsigned int req = KVM_REQ_OUTSIDE_GUEST_MODE;
> > +		bool called;
> > +
> > +		/*
> > +		 * If the OOM reaper is active, then all vCPUs should have
> > +		 * been stopped already, so perform the request without
> > +		 * KVM_REQUEST_WAIT and be sad if any needed to be IPI'd.
> > +		 */
> 
> I am unconvinced of the veracity of that claim. We get here via
> __oom_reap_task_mm() which has explicit comments about 'might start
> racing with the dying task'.
> 
> I think it's actually fine to use KVM_REQUEST_WAIT in theory...

Actually, it has to be "fine", because KVM already does KVM_REQUEST_WAIT for
literally every releavnt OOM kill thanks to the kvm_flush_remote_tlbs() in
kvm_mmu_notifier_invalidate_range_start() -> kvm_handle_hva_range().  So I would
say don't worry about KVM_REQUEST_WAIT here; if we need to fix anything for the
OOM case, then we need a more generic fix.