RE: [PATCH 04/14] KVM: VMX: Extend VMX controls macro shenanigans

[Vitaly Kuznetsov]

"Dong, Eddie" <eddie.dong@xxxxxxxxx> writes:

>> -----Original Message-----
>> From: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx>
>> Sent: Monday, June 27, 2022 9:05 AM
>> To: kvm@xxxxxxxxxxxxxxx; Paolo Bonzini <pbonzini@xxxxxxxxxx>;
>> Christopherson,, Sean <seanjc@xxxxxxxxxx>
>> Cc: Anirudh Rayabharam <anrayabh@xxxxxxxxxxxxxxxxxxx>; Wanpeng Li
>> <wanpengli@xxxxxxxxxxx>; Jim Mattson <jmattson@xxxxxxxxxx>; Maxim
>> Levitsky <mlevitsk@xxxxxxxxxx>; linux-hyperv@xxxxxxxxxxxxxxx; linux-
>> kernel@xxxxxxxxxxxxxxx
>> Subject: [PATCH 04/14] KVM: VMX: Extend VMX controls macro shenanigans
>> 
>> When VMX controls macros are used to set or clear a control bit, make sure
>> that this bit was checked in setup_vmcs_config() and thus is properly
>> reflected in vmcs_config.
>> 

...

>
> With this, will it be safer if we present L1 CTRL MSRs with the bits
> KVM really uses? Do I miss something?

Sean has already answered but let me present my version. Currently,
vmcs_config has sanitized VMX control MSRs values filtering out three
groups of features:
- Features, which KVM doesn't know about.
- Features, which KVM can't enable (because of eVMCS, bugs,...)
- Features, which KVM doesn't want to enable for some reason.
L1 VMX control MSRs should have the first two groups filtered out but
not the third. E.g. when EPT is in use, KVM doesn't use
CPU_BASED_CR3_LOAD_EXITING/CPU_BASED_CR3_STORE_EXITING but this doesn't
mean that all possible L1 hypervisors are going to be happy if we filter
these out. Same goes to e.g. CPU_BASED_RDTSC_EXITING: KVM never sets
this for itself but nested hypervisor can.

-- 
Vitaly