lkml.org 
[lkml]   [2022]   [Aug]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCH v5 03/26] x86/hyperv: Update 'struct hv_enlightened_vmcs' definition
    Date
    Sean Christopherson <seanjc@google.com> writes:

    > On Thu, Aug 18, 2022, Vitaly Kuznetsov wrote:
    >> Sean Christopherson <seanjc@google.com> 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

    \
     
     \ /
      Last update: 2022-08-22 11:22    [W:3.465 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site