Re: [PATCH v4 10/18] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] The guest_memfd invalidation flow fails to synchronously wait for vCPUs to exit guest mode before allowing the host to free the VMSA page, resulting in RMPUPDATE FAIL_INUSE hardware errors and a host kernel panic.
--

--- Patch [10]: [PATCH v4 10/18] KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped ---
commit ceb579c141d8889038624fb707ecde51b8427194
Author: Sean Christopherson <seanjc@google.com>

KVM: SEV: Forcefully invalidate SNP VMSA if its backing gmem page is zapped

This commit wires up a gmem_invalidate_range() call for SNP VMs, forcing
vCPUs to reload their VMSA if the backing guest_memfd page is invalidated
(e.g., via PUNCH_HOLE).

Link: https://lore.kernel.org/all/aimMWzAf5b3luM0b@v4bel

> diff --git a/virt/kvm/guest_memfd.c b/virt/kvm/guest_memfd.c
> --- a/virt/kvm/guest_memfd.c
> +++ b/virt/kvm/guest_memfd.c
[ ... ]
> @@ -185,6 +185,10 @@ static void __kvm_gmem_invalidate_start(struct gmem_file *f, pgoff_t start,
>  		}
>  
>  		flush |= kvm_mmu_unmap_gfn_range(kvm, &gfn_range);
> +
> +#ifdef CONFIG_HAVE_KVM_ARCH_GMEM_INVALIDATE
> +		kvm_arch_gmem_invalidate_range(kvm, &gfn_range);
> +#endif
>  	}
>  
>  	if (flush)

[Severity: Critical]
Does this invalidation path need a way to guarantee a synchronous wait before
returning?

Since VMSA pages typically do not have TDP MMU SPTEs,
kvm_mmu_unmap_gfn_range() will return false, leaving flush as false.

Because flush remains false, the subsequent kvm_flush_remote_tlbs(kvm) call
is skipped.

Meanwhile, sev_gmem_invalidate_range() relies on KVM_REQ_VMSA_PAGE_RELOAD
and kvm_make_request_and_kick() to send an asynchronous IPI to the vCPU:

arch/x86/kvm/svm/sev.c:sev_gmem_invalidate_range() {
    ...
    kvm_make_request_and_kick(KVM_REQ_VMSA_PAGE_RELOAD, vcpu);
    ...
}

Because the IPI is asynchronous and the TLB flush (which would otherwise
provide a synchronous wait) is skipped, the host could proceed to free the
VMSA page before the vCPU actually drops it and exits guest mode.

Could this lead to the very RMPUPDATE FAIL_INUSE hardware error and host
kernel panic that the commit is trying to resolve, if a host userspace
process issues fallocate(PUNCH_HOLE) on the guest_memfd region?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260709204948.1988414-1-seanjc@google.com?part=10