Re: [PATCH v6 09/20] KVM: nVMX: Propagate extended instruction information

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] The patch series reads EXTENDED_INSTRUCTION_INFO using vmcs_read64() if APX is supported, but fails to map this field for enlightened VMCS (eVMCS), triggering a host kernel WARNING and corrupting instruction emulation when KVM runs on Hyper-V.
- [Medium] The logic to propagate EXTENDED_INSTRUCTION_INFO is dead code because KVM's CPUID capability tracking never initializes or exposes X86_FEATURE_APX.
--

--- Patch [9]: [PATCH v6 09/20] KVM: nVMX: Propagate extended instruction information ---
commit 649ca5041fdd2df30db144e44ba02783451c334f
Author: Chang S. Bae <chang.seok.bae@intel.com>

KVM: nVMX: Propagate extended instruction information

Define the new extended_instruction_info field in struct vmcs12 and
propagate it to nested VMX. Gate the propagation on the guest APX
enumeration, which aligns with bare metal behavior.

Link: https://lore.kernel.org/aRvOSnaUt1E+%2FpkC@intel.com

> diff --git a/arch/x86/kvm/reverse_cpuid.h b/arch/x86/kvm/reverse_cpuid.h
> index 657f5f743ed97..de90697c4e5a0 100644
> --- a/arch/x86/kvm/reverse_cpuid.h
> +++ b/arch/x86/kvm/reverse_cpuid.h

[ ... ]

> @@ -35,6 +35,7 @@
>  #define X86_FEATURE_AVX_VNNI_INT16      KVM_X86_FEATURE(CPUID_7_1_EDX, 10)
>  #define X86_FEATURE_PREFETCHITI         KVM_X86_FEATURE(CPUID_7_1_EDX, 14)
>  #define X86_FEATURE_AVX10               KVM_X86_FEATURE(CPUID_7_1_EDX, 19)
> +#define KVM_X86_FEATURE_APX             KVM_X86_FEATURE(CPUID_7_1_EDX, 21)
>  
>  /* Intel-defined sub-features, CPUID level 0x00000007:2 (EDX) */
>  #define X86_FEATURE_INTEL_PSFD		KVM_X86_FEATURE(CPUID_7_2_EDX, 0)

[ ... ]

> diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
> index 8e0523e40477d..1684f5d1dbf4d 100644
> --- a/arch/x86/kvm/vmx/nested.c
> +++ b/arch/x86/kvm/vmx/nested.c

[ ... ]

> @@ -4766,6 +4766,12 @@ static void prepare_vmcs12(struct kvm_vcpu *vcpu, struct vmcs12 *vmcs12,
>  		vmcs12->vm_exit_intr_info = exit_intr_info;
>  		vmcs12->vm_exit_instruction_len = exit_insn_len;
>  		vmcs12->vmx_instruction_info = vmcs_read32(VMX_INSTRUCTION_INFO);
> +		/*
> +		 * The APX enumeration guarantees the presence of the extended
> +		 * fields. This CPUID bit alone is sufficient to rely on it.
> +		 */
> +		if (guest_cpu_cap_has(vcpu, X86_FEATURE_APX))

[Severity: Medium]
Will this condition ever evaluate to true?

It appears X86_FEATURE_APX is defined in arch/x86/kvm/reverse_cpuid.h but is
never enabled in the capabilities mask in cpuid.c (e.g., kvm_cpu_caps).

Without initializing it there, it seems this feature will be stripped from
vcpu->arch.cpu_caps, making this block dead code.

> +			vmcs12->extended_instruction_info = vmcs_read64(EXTENDED_INSTRUCTION_INFO);

[Severity: High]
Does vmcs_read64() handle EXTENDED_INSTRUCTION_INFO correctly when KVM is
running on Hyper-V with enlightened VMCS (eVMCS) enabled?

Since EXTENDED_INSTRUCTION_INFO isn't mapped for eVMCS, attempting to read
it here (once the dead code issue is fixed) will trigger a host kernel
WARNING and return 0.

This could corrupt the instruction emulation state and cause a
guest-triggerable host log denial of service when an L2 guest executes an
instruction that induces a VM-exit reading instruction info.

>  
>  		/*
>  		 * According to spec, there's no need to store the guest's

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260729191656.598771-1-chang.seok.bae@intel.com?part=9