Sean Christopherson <seanjc@xxxxxxxxxx> writes: > On Thu, Aug 18, 2022, Vitaly Kuznetsov wrote: >> Sean Christopherson <seanjc@xxxxxxxxxx> writes: >> >> > On Tue, Aug 02, 2022, Vitaly Kuznetsov wrote: >> >> + * Note: HV_X64_NESTED_EVMCS1_2022_UPDATE is not currently documented in any >> >> + * published TLFS version. When the bit is set, nested hypervisor can use >> >> + * 'updated' eVMCSv1 specification (perf_global_ctrl, s_cet, ssp, lbr_ctl, >> >> + * encls_exiting_bitmap, tsc_multiplier fields which were missing in 2016 >> >> + * specification). >> >> + */ >> >> +#define HV_X64_NESTED_EVMCS1_2022_UPDATE BIT(0) >> > >> > This bit is now defined[*], but the docs says it's only for perf_global_ctrl. Are >> > we expecting an update to the TLFS? >> > >> > Indicates support for the GuestPerfGlobalCtrl and HostPerfGlobalCtrl fields >> > in the enlightened VMCS. >> > >> > [*] https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/tlfs/feature-discovery#hypervisor-nested-virtualization-features---0x4000000a >> > >> >> Oh well, better this than nothing. I'll ping the people who told me >> about this bit that their description is incomplete. > > Not that it changes anything, but I'd rather have no documentation. I'd much rather > KVM say "this is the undocumented behavior" than "the document behavior is wrong". > So I reached out to Microsoft and their answer was that for all these new eVMCS fields (including *PerfGlobalCtrl) observing architectural VMX MSRs should be enough. *PerfGlobalCtrl case is special because of Win11 bug (if we expose the feature in VMX feature MSRs but don't set CPUID.0x4000000A.EBX BIT(0) it just doesn't boot). What I'm still concerned about is future proofing KVM for new features. When something is getting added to KVM for which no eVMCS field is currently defined, both Hyper-V-on-KVM and KVM-on-Hyper-V cases should be taken care of. It would probably be better to reverse our filtering, explicitly listing features supported in eVMCS. The lists are going to be fairly long but at least we won't have to take care of any new architectural feature added to KVM. -- Vitaly
