Re: [PATCH 60/60] kvm: svm: Advertise full multi-VMPL support to the SNP guest

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] The patch unconditionally advertises the new GHCB_HV_FT_SNP_MULTI_VMPL feature to guests without userspace enumeration or control, violating KVM invariants.
--

commit 885b4d7d907e2c3c684356fd3142ddc49a702d2c
Author: Tom Lendacky <thomas.lendacky@amd.com>

kvm: svm: Advertise full multi-VMPL support to the SNP guest

This commit updates the GHCB hypervisor features bitmap to include the
GHCB_HV_FT_SNP_MULTI_VMPL flag. It indicates to the guest that full
multi-VMPL support is available.

> diff --git a/arch/x86/kvm/svm/sev.c b/arch/x86/kvm/svm/sev.c
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> @@ -43,7 +43,8 @@
>  #define GHCB_HV_FT_SUPPORTED	(GHCB_HV_FT_SNP			| \
>  				 GHCB_HV_FT_SNP_AP_CREATION	| \
>  				 GHCB_HV_FT_SNP_RINJ		| \
> -				 GHCB_HV_FT_APIC_ID_LIST)
> +				 GHCB_HV_FT_APIC_ID_LIST	| \
> +				 GHCB_HV_FT_SNP_MULTI_VMPL)

[Severity: High]
Does unconditionally exposing this feature break KVM live migration
and capability negotiation?

It looks like GHCB_HV_FT_SNP_MULTI_VMPL is now enabled by default for
all SEV-SNP guests whenever they request HV features, without giving
userspace the ability to enumerate or control it.

If a guest queries this newly exposed flag and attempts to switch to a
valid VMPL (e.g., vmpl = 1), but userspace has not yet created the
target plane, would sev_handle_vmgexit_msr_protocol() return -EINVAL
when calling __sev_snp_run_vmpl()? This appears to propagate up to the
KVM_RUN loop and abort the VM entirely, meaning the guest could
unexpectedly crash its own VM on a host missing userspace configuration.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260608144252.351443-1-joro@8bytes.org?part=60