Re: [PATCH 20/28] KVM: nVMX: allow MBEC with EVMCS

[Vitaly Kuznetsov <vkuznets@redhat.com>]

mlevitsk@redhat.com writes:

> On Tue, 2026-05-05 at 21:52 +0200, Paolo Bonzini wrote:
>> From: Jon Kohler <jon@nutanix.com>
>> 
>> Extend EVMCS1_SUPPORTED_2NDEXEC to allow MBEC and EVMCS to coexist.
>> Presenting both EVMCS and MBEC simultaneously causes KVM to filter out
>> MBEC and not present it as a supported control to the guest, preventing
>> performance gains from MBEC when Windows HVCI is enabled.
>> 
>> The guest may choose not to use MBEC (e.g., if the admin does not enable
>> Windows HVCI / Memory Integrity), but if they use traditional nested
>> virt (Hyper-V, WSL2, etc.), having EVMCS exposed is important for
>> improving nested guest performance. IOW allowing MBEC and EVMCS to
>> coexist provides maximum optionality to Windows users without
>> overcomplicating VM administration.
>> 
>> Signed-off-by: Jon Kohler <jon@nutanix.com>
>> Message-ID: <20251223054806.1611168-8-jon@nutanix.com>
>> Tested-by: David Riley <d.riley@proxmox.com>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>  arch/x86/kvm/vmx/hyperv_evmcs.h | 1 +
>>  1 file changed, 1 insertion(+)
>> 
>> diff --git a/arch/x86/kvm/vmx/hyperv_evmcs.h b/arch/x86/kvm/vmx/hyperv_evmcs.h
>> index fc7c4e7bd1bf..bc08fe40590e 100644
>> --- a/arch/x86/kvm/vmx/hyperv_evmcs.h
>> +++ b/arch/x86/kvm/vmx/hyperv_evmcs.h
>> @@ -87,6 +87,7 @@
>>   SECONDARY_EXEC_PT_CONCEAL_VMX | \
>>   SECONDARY_EXEC_BUS_LOCK_DETECTION | \
>>   SECONDARY_EXEC_NOTIFY_VM_EXITING | \
>> + SECONDARY_EXEC_MODE_BASED_EPT_EXEC | \
>>   SECONDARY_EXEC_ENCLS_EXITING)
>>  
>>  #define EVMCS1_SUPPORTED_3RDEXEC (0ULL)
>
> Unrelated to this patch:
>
> I haven't paid much attention to this particular area of KVM, but 'EVMCSv1_LEGACY' caught my attention now.
>
> According to the Hypervisor Top Level Function Specificaiton v5.0C and v6.0b that I have, there is only one version defined,
> version 1. 
> Is there a reason on why we choose to call it "Legacy"?
>

This is the patch:
https://lore.kernel.org/kvm/20220830133737.1539624-8-vkuznets@redhat.com/

which was eventually supposed to be supplimented by something like
https://lore.kernel.org/kvm/20220824030138.3524159-10-seanjc@google.com/

> Also I see:
>
> Enlightened VMCSv1 doesn't support these:
> ....
>  * TSC_MULTIPLIER = 0x00002032,
>
> And yet I see it defined:
>
>  EVMCS1_FIELD(TSC_MULTIPLIER, tsc_multiplier,
>  HV_VMX_ENLIGHTENED_CLEAN_FIELD_CONTROL_GRP2),
>

The problem is that EVMCSv1 spec came with a certain feature set and we
were expecting that it is a closed list and the revision id will go up
if needed. That turned out to not be the case, e.g. see

"21	Indicates support for non-zero value of the 0x00002802 (GuestIa32DebugCtl) field in the VMCS."
bit definition for 0x4000000A.EAX

As for TSC_MULTIPLIER, I believe that the field was missing in the spec
initially but then it got added. After some git-blaming I found the
following commit:

commit 96d6955d215e6234bb820fd23756b2a9b77aef0f
Author: Vitaly Kuznetsov <vkuznets@redhat.com>
Date:   Fri Nov 4 15:47:06 2022 +0100

    KVM: nVMX: Invert 'unsupported by eVMCSv1' check

which says:

"""
    From all the controls, SECONDARY_EXEC_TSC_SCALING requires special
    handling as it's actually present in eVMCSv1 definition but is not
    currently supported for Hyper-V-on-KVM, just for KVM-on-Hyper-V. As
    evmcs_supported_ctrls will be used for both scenarios, just add it
    there instead of EVMCS1_SUPPORTED_2NDEXEC.

"""

I have to admit I forgot the gory details on why we don't enable it for
Hyper-V-on-KVM. My guess is that KVM part is simple but we will need a
new enablement method from VMM (KVM_CAP_HYPERV_ENLIGHTENED_VMCS2 or
something) to not break migration.

>
> Anyway I haven't found any restrictions on the execution controls in the EVMCS in the Microsoft's spec, 
> so it is unlikely that it is not supported.
>
> So:
> Reviewed-by: Maxim Levitsky <mlevitsk@redhat.com>
>
> Best regards,
> 	Maxim Levitsky
>

-- 
Vitaly