• Sean Christopherson's avatar
    x86/vmx: Introduce VMX_FEATURES_* · 15934878
    Sean Christopherson authored
    Add a VMX-specific variant of X86_FEATURE_* flags, which will eventually
    supplant the synthetic VMX flags defined in cpufeatures word 8.  Use the
    Intel-defined layouts for the major VMX execution controls so that their
    word entries can be directly populated from their respective MSRs, and
    so that the VMX_FEATURE_* flags can be used to define the existing bit
    definitions in asm/vmx.h, i.e. force developers to define a VMX_FEATURE
    flag when adding support for a new hardware feature.
    
    The majority of Intel's (and compatible CPU's) VMX capabilities are
    enumerated via MSRs and not CPUID, i.e. querying /proc/cpuinfo doesn't
    naturally provide any insight into the virtualization capabilities of
    VMX enabled CPUs.  Commit
    
      e38e05a8 ("x86: extended "flags" to show virtualization HW feature
    		 in /proc/cpuinfo")
    
    attempted to address the issue by synthesizing select VMX features into
    a Linux-defined word in cpufeatures.
    
    Lack of reporting of VMX capabilities via /proc/cpuinfo is problematic
    because there is no sane way for a user to query the capabilities of
    their platform, e.g. when trying to find a platform to test a feature or
    debug an issue that has a hardware dependency.  Lack of reporting is
    especially problematic when the user isn't familiar with VMX, e.g. the
    format of the MSRs is non-standard, existence of some MSRs is reported
    by bits in other MSRs, several "features" from KVM's point of view are
    enumerated as 3+ distinct features by hardware, etc...
    
    The synthetic cpufeatures approach has several flaws:
    
      - The set of synthesized VMX flags has become extremely stale with
        respect to the full set of VMX features, e.g. only one new flag
        (EPT A/D) has been added in the the decade since the introduction of
        the synthetic VMX features.  Failure to keep the VMX flags up to
        date is likely due to the lack of a mechanism that forces developers
        to consider whether or not a new feature is worth reporting.
    
      - The synthetic flags may incorrectly be misinterpreted as affecting
        kernel behavior, i.e. KVM, the kernel's sole consumer of VMX,
        completely ignores the synthetic flags.
    
      - New CPU vendors that support VMX have duplicated the hideous code
        that propagates VMX features from MSRs to cpufeatures.  Bringing the
        synthetic VMX flags up to date would exacerbate the copy+paste
        trainwreck.
    
    Define separate VMX_FEATURE flags to set the stage for enumerating VMX
    capabilities outside of the cpu_has() framework, and for adding
    functional usage of VMX_FEATURE_* to help ensure the features reported
    via /proc/cpuinfo is up to date with respect to kernel recognition of
    VMX capabilities.
    Signed-off-by: default avatarSean Christopherson <sean.j.christopherson@intel.com>
    Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
    Link: https://lkml.kernel.org/r/20191221044513.21680-10-sean.j.christopherson@intel.com
    15934878
vmxfeatures.h 5.63 KB