On Mon, Nov 18, 2019 at 07:12:33PM -0800, Sean Christopherson wrote:
> 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 e38e05a85828d ("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.
>
> 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.
That's all fine and good but who's going to use those feature bits?
Or are we reporting them just for the sake of it? Because if only
that, then it is not worth the effort. Sure, I don't mind extending
the framework so that you can use cpu_has() for VMX features but the
/proc/cpuinfo angle is not clear to me.
Especially since you're hiding most of them with the "" prepended in the
define comment.
> Note, the displayed names 'vnmi', 'tpr_shadow' and 'flexpriority' are
> retained for backwards compatibility with the existing ABI.
>
> Signed-off-by: Sean Christopherson <sean.j.christopherson@xxxxxxxxx>
> ---
> MAINTAINERS | 2 +-
> arch/x86/include/asm/processor.h | 1 +
> arch/x86/include/asm/vmxfeatures.h | 81 ++++++++++++++++++++++++++++++
> 3 files changed, 83 insertions(+), 1 deletion(-)
> create mode 100644 arch/x86/include/asm/vmxfeatures.h
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index df711965c377..6b736e78ee9e 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9009,7 +9009,7 @@ F: arch/x86/include/uapi/asm/svm.h
> F: arch/x86/include/asm/kvm*
> F: arch/x86/include/asm/pvclock-abi.h
> F: arch/x86/include/asm/svm.h
> -F: arch/x86/include/asm/vmx.h
> +F: arch/x86/include/asm/vmx*.h
> F: arch/x86/kernel/kvm.c
> F: arch/x86/kernel/kvmclock.c
>
> diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
> index b4e29d8b9e5a..772de8917430 100644
> --- a/arch/x86/include/asm/processor.h
> +++ b/arch/x86/include/asm/processor.h
> @@ -25,6 +25,7 @@ struct vm86;
> #include <asm/special_insns.h>
> #include <asm/fpu/types.h>
> #include <asm/unwind_hints.h>
> +#include <asm/vmxfeatures.h>
>
> #include <linux/personality.h>
> #include <linux/cache.h>
> diff --git a/arch/x86/include/asm/vmxfeatures.h b/arch/x86/include/asm/vmxfeatures.h
> new file mode 100644
> index 000000000000..aea39b9f1587
> --- /dev/null
> +++ b/arch/x86/include/asm/vmxfeatures.h
> @@ -0,0 +1,81 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +#ifndef _ASM_X86_VMXFEATURES_H
> +#define _ASM_X86_VMXFEATURES_H
> +
> +/*
> + * Note: If the comment begins with a quoted string, that string is used
> + * in /proc/cpuinfo instead of the macro name. If the string is "",
> + * this feature bit is not displayed in /proc/cpuinfo at all.
> + */
> +
> +/* Pin-Based VM-Execution Controls, EPT/VPID, APIC and VM-Functions, word 0 */
> +#define VMX_FEATURE_INTR_EXITING ( 0*32+ 0) /* "" VM-Exit on vectored interrupts */
> +#define VMX_FEATURE_NMI_EXITING ( 0*32+ 3) /* "" VM-Exit on NMIs */
> +#define VMX_FEATURE_VIRTUAL_NMIS ( 0*32+ 5) /* "vnmi" NMI virtualization */
> +#define VMX_FEATURE_PREEMPTION_TIMER ( 0*32+ 6) /* VMX Preemption Timer */
You really wanna have "preemption_timer" in /proc/cpuinfo? That should
at least say vmx-something, if it should be visible there at all.
> +#define VMX_FEATURE_POSTED_INTR ( 0*32+ 7) /* Posted Interrupts */
Same here.
In general, the questions stand for all those feature bits which will be
visible in /proc/cpuinfo.
1. Which to show and why?
2. Who's going to use them?
3. If show and dumping them together with the other feature flags, have
their name be proper (vmx-prefixed etc).
> +/* EPT/VPID features, scattered to bits 16-23 */
> +#define VMX_FEATURE_INVVPID ( 0*32+ 16) /* INVVPID is supported */
> +#define VMX_FEATURE_EPT_EXECUTE_ONLY ( 0*32+ 17) /* "ept_x_only" EPT entries can be execute only */
> +#define VMX_FEATURE_EPT_AD ( 0*32+ 18) /* EPT Accessed/Dirty bits */
> +#define VMX_FEATURE_EPT_1GB ( 0*32+ 19) /* 1GB EPT pages */
^^^^^^^^^^^^
There are some spaces that need to be converted to tabs here.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
