Re: [PATCH 1/4] KVM: SEV: Treat unassigned RMP entry as benign race on PSMASH failure

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Medium] Unaligned GFN range in RMP fault handler causes erroneous invalidation of adjacent memory
--

--- Patch [1]: [PATCH 1/4] KVM: SEV: Treat unassigned RMP entry as benign race on PSMASH failure ---
commit de1b2dc6f988d4cc54c9ff854b0263fe60c82d44
Author: Ackerley Tng <ackerleytng@google.com>
KVM: SEV: Treat unassigned RMP entry as benign race on PSMASH failure

This commit modifies KVM's handling of RMP faults during a PSMASH operation.
It updates the RMP entry lookup condition to treat an unassigned entry as an
expected race when re-checking after a failed PSMASH, preventing unnecessary
warning logs if another process transitions the page to shared.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> index fcb41dfde4c02..b2738362a928b 100644
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -5074,10 +5074,11 @@ void sev_handle_rmp_fault(struct kvm_vcpu *vcpu, gpa_t gpa, u64 error_code)

[ ... ]

>  		/*
>  		 * Look it up again. If it's 4K now then the PSMASH may have
>  		 * raced with another process and the issue has already resolved
> -		 * itself.
> +		 * itself. If it's not assigned, then this must have raced with
> +		 * another process that made this page shared.
>  		 */
>  		if (!snp_lookup_rmpentry(pfn, &assigned, &rmp_level) &&
> -		    assigned && rmp_level == PG_LEVEL_4K)
> +		    ((assigned && rmp_level == PG_LEVEL_4K) || !assigned))
>  			goto out;
>  
>  		pr_warn_ratelimited("SEV: Unable to split RMP entry for GPA 0x%llx PFN 0x%llx ret %d\n",
> 				    gpa, pfn, ret);
>  	}
>  
>  	kvm_zap_gfn_range(kvm, gfn, gfn + PTRS_PER_PMD);

[Severity: Medium]
This is a pre-existing issue, but does this correctly align the guest frame
number before zapping the range?

Looking at sev_handle_rmp_fault(), the gfn is calculated from the unaligned
faulting guest physical address. Since gfn isn't masked to a 2MB boundary,
does adding PTRS_PER_PMD cause the zap range to cross into and erroneously
invalidate up to 511 pages of the adjacent 2MB region?

Additionally, if the NPT mappings were already 4K, would this unaligned gfn
cause the function to miss zapping the start of the intended 2MB region?

> out:
>  	trace_kvm_rmp_fault(vcpu, gpa, pfn, error_code, rmp_level, ret);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818-gmem-no-return-page-v1-0-4f8d939efdbc@google.com?part=1