Re: [PATCH RFC v1 07/20] KVM: nVMX: Support the extended instruction info field

From: Chao Gao

Date: Tue Nov 11 2025 - 20:54:47 EST


>> --- a/arch/x86/kvm/vmx/nested.c
>> +++ b/arch/x86/kvm/vmx/nested.c
>> @@ -4798,6 +4798,8 @@ 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);
>> + if (vmx_egpr_enabled(vcpu))
>> + vmcs12->extended_instruction_info = vmcs_read64(EXTENDED_INSTRUCTION_INFO);
>
>>From patch 17:
>
>+static inline bool vmx_egpr_enabled(struct kvm_vcpu *vcpu)
>+{
>+ return vcpu->arch.xcr0 & XFEATURE_MASK_APX && is_64_bit_mode(vcpu);
>+}
>
>but here you must not check XCR0, the extended instruction information field
>is always available. The spec says "A non-Intel® APX enabled VMM is free to
>continue using the legacy definition of the field, since lack of Intel® APX
>enabling will guarantee that regIDs are only 4-bits, maximum" but you can
>also use the extended instruction information field if you want. So, I'd
>make this also static_cpu_has(X86_FEATURE_APX).

Shouldn't we check guest's capabilities rather than host's,

i.e., guest_cpu_cap_has(X86_FEATURE_APX)?