Re: [PATCH v2 4/8] KVM: SEV: Add direct VMSA capability

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Using `guard(mutex)` inside a `switch` case without enclosing braces causes a compile-time error and bypasses variable initialization.
--

commit 14ba20ca988537a92ef023f074770d517f738803
Author: Joerg Roedel <joerg.roedel@amd.com>

KVM: SEV: Add direct VMSA capability

This commit introduces the KVM_CAP_SNP_DIRECT_VMSA capability, allowing
userspace to manage VMSA pages directly for SNP VMs. When enabled, it skips
KVM-owned VMSA allocation during vCPU creation and measurement at launch.

> diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
> index 7d59d301e1e54..98c5cffe2c227 100644
> --- a/arch/x86/kvm/svm/svm.c
> +++ b/arch/x86/kvm/svm/svm.c
[ ... ]
> +static int svm_enable_vm_cap(struct kvm *kvm, struct kvm_enable_cap *cap)
> +{
> +	switch (cap->cap) {
> +#ifdef CONFIG_KVM_AMD_SEV
> +	case KVM_CAP_SNP_DIRECT_VMSA:
> +		if (memchr_inv(cap->args, 0, sizeof(cap->args)) ||
> +		    kvm->arch.vm_type != KVM_X86_SNP_VM)
> +			return -EINVAL;
> +
> +		guard(mutex)(&kvm->lock);

[Severity: Low]
Does this code cause a build failure? Using guard(mutex) inside a switch case
without enclosing braces declares a variable in the wider scope of the switch
block.

> +		if (kvm->created_vcpus)
> +			return -EINVAL;
> +
> +		to_kvm_sev_info(kvm)->snp_direct_vmsa = true;
> +		return 0;
> +#endif
> +	default:
> +		return -EINVAL;

If execution jumps to this default label, it bypasses the initialization of
the cleanup variable declared by the guard in the case above. The cleanup
function will then attempt to run on an uninitialized pointer upon return.

Could the KVM_CAP_SNP_DIRECT_VMSA case be enclosed in curly braces to limit
the scope of the guard?

> +	}
> +}

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