Re: [PATCH v2 4/4] KVM: selftests: Check VMPTRLD with active eVMCS

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Code relying on CPU flags after `KVM_ASM_SAFE` incorrectly evaluates them because the macro's cleanup instructions unconditionally clobber the flags.
--

--- Patch [4]: [PATCH v2 4/4] KVM: selftests: Check VMPTRLD with active eVMCS ---
commit d5821824a958c354147206d0cf6cf26eaeb71cc6
Author: Vitaly Kuznetsov <vkuznets@redhat.com>

KVM: selftests: Check VMPTRLD with active eVMCS

This commit verifies that VMPTRLD triggers a #UD when eVMCS is active.
It uses the KVM_ASM_SAFE framework to safely handle the expected
exceptions from VMPTRLD testing.

> diff --git a/tools/testing/selftests/kvm/include/x86/vmx.h b/tools/testing/selftests/kvm/include/x86/vmx.h
> index 047d02aa96889..e6adde3970d4d 100644
> --- a/tools/testing/selftests/kvm/include/x86/vmx.h
> +++ b/tools/testing/selftests/kvm/include/x86/vmx.h
[ ... ]
> @@ -336,6 +333,22 @@ static inline int vmptrld(u64 vmcs_pa)
>  	return ret;
>  }
>  
> +static inline int vmptrld_safe(u64 vmcs_pa)
> +{
> +	u64 error_code;
> +	u8 vector;
> +	u8 failed;
> +
> +	asm volatile(KVM_ASM_SAFE("vmptrld %[pa]")
> +		     "\n\tsetna %[failed]"

[Severity: Medium]
Will this setna instruction incorrectly evaluate CPU flags?

The KVM_ASM_SAFE macro executes xor %%r9, %%r9 on its success path, which
unconditionally clears the Carry Flag (CF=0) and sets the Zero Flag (ZF=1).

Because setna evaluates flags immediately after KVM_ASM_SAFE finishes its
cleanup instructions, it captures these clobbered flags and always evaluates
to true.

Does this cause vmptrld_safe() to incorrectly return -EINVAL upon successful
execution?

> +		     : KVM_ASM_SAFE_OUTPUTS(vector, error_code),
> +		       [failed]"=qm"(failed)
> +		     : [pa]"m"(vmcs_pa)
> +		     : "cc", "memory", KVM_ASM_SAFE_CLOBBERS);
> +
> +	return vector ? vector : failed ? -EINVAL : 0;
> +}
> +

[Severity: Medium]
This isn't a bug introduced by this patch, but is a pre-existing issue in
guest_execute_fastop_div() located in
tools/testing/selftests/kvm/x86/fastops_test.c:

Does guest_execute_fastop_div() suffer from a similar flag evaluation issue?

__asm__ __volatile__(fastop(__KVM_ASM_SAFE(insn " %[denom]"))

The fastop macro invokes __KVM_ASM_SAFE, and captures flags via pushfq.
Does capturing flags after the macro result in saving the clobbered flags
from the internal xor instruction rather than the actual result of the
instruction under test?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260818165258.2613603-1-vkuznets@redhat.com?part=4