Re: [PATCH v2 7/9] 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:
- [Low] Data Race on lockless access to `snp_guest_vmsa_gpa` without READ_ONCE/WRITE_ONCE.
--

commit 0384ec40691742221905a1f869e903471b8acac7
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_invalid_range() call for SNP VMs. It forces
vCPUs to reload or recheck their guest-provided VMSA if the backing
guest_memfd page is being invalidated.

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

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index 3d90aa723dc25..04be49b1af57d 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c

[ ... ]

> @@ -5135,6 +5154,31 @@ int sev_gmem_prepare(struct kvm *kvm, kvm_pfn_t pfn, gfn_t gfn, int max_order)
>  
>  	return 0;
>  }
> +void sev_gmem_invalidate_range(struct kvm *kvm, struct kvm_gfn_range *range)
> +{
> +	struct kvm_vcpu *vcpu;
> +	unsigned long i;
> +
> +	lockdep_assert_held_write(&kvm->mmu_lock);
> +
> +	/*
> +	 * An unstable result for "is SNP" is a-ok here, thanks to mmu_lock.
> +	 * The vCPU's VMSA GPA is invalidated before the vCPU is made visible
> +	 * to other tasks, and can only become valid while holding mmu_lock,
> +	 * after the VM is fully committed to being an SNP VM.
> +	 */
> +	if (!____sev_snp_guest(kvm))
> +		return;
> +
> +	kvm_for_each_vcpu(i, vcpu, kvm) {
> +		gpa_t gpa = to_svm(vcpu)->sev_es.snp_guest_vmsa_gpa;
> +
> +		if (VALID_PAGE(gpa) &&

[Severity: Low]
Can this lead to a data race or KCSAN splat?

Here snp_guest_vmsa_gpa is read locklessly relative to snp_vmsa_mutex. It is
read under mmu_lock, but in __sev_snp_reload_vmsa(), snp_guest_vmsa_gpa is
cleared (set to INVALID_PAGE) while holding snp_vmsa_mutex without mmu_lock.

Since they don't share a common lock for this variable's lifecycle, should
this read and the corresponding write in __sev_snp_reload_vmsa() use
READ_ONCE() and WRITE_ONCE() to prevent compiler refetching or optimization
artifacts?

> +		    gpa_to_gfn(gpa) >= range->start &&
> +		    gpa_to_gfn(gpa) < range->end)
> +			kvm_make_request_and_kick(KVM_REQ_VMSA_PAGE_RELOAD, vcpu);
> +	}
> +}

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