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

[David Woodhouse]

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... but
then again, the task has already been ignoring SIGKILL for two seconds
or the oom_reaper wouldn't even have been invoked AIUI, so maybe we
should err on the side of caution by still doing this:

> +		if (!may_block)
> +			req &= ~KVM_REQUEST_WAIT;
> +
> +		called = kvm_make_vcpus_request_mask(kvm, req, vcpu_bitmap);
> +
> +		WARN_ON_ONCE(called && !may_block);

... but instead of warning, it should return -EINVAL in this case? The
OOM reaper should call it to try again in 100ms. I guess we shouldn't
clear the valid flag in that case? Because it does need to check the
vCPUs again on the retry, not just skip on the basis that the
invalidation already happened.

(Yes, this is a void function. It would need not to be, and the return
would need to be propagated back through 
kvm_mmu_notifier_invalidate_range_start())


cf. https://lore.kernel.org/all/20260601144724.ARQR8tYh@xxxxxxxxxxxxx/

Attachment: smime.p7s
Description: S/MIME cryptographic signature