From: Sean Christopherson <firstname.lastname@example.org> To: Borislav Petkov <email@example.com> Cc: "Thomas Gleixner" <firstname.lastname@example.org>, "Ingo Molnar" <email@example.com>, firstname.lastname@example.org, "H. Peter Anvin" <email@example.com>, "Peter Zijlstra" <firstname.lastname@example.org>, "Arnaldo Carvalho de Melo" <email@example.com>, "Mark Rutland" <firstname.lastname@example.org>, "Alexander Shishkin" <email@example.com>, "Jiri Olsa" <firstname.lastname@example.org>, "Namhyung Kim" <email@example.com>, "Paolo Bonzini" <firstname.lastname@example.org>, "Radim Krčmář" <email@example.com>, "Vitaly Kuznetsov" <firstname.lastname@example.org>, "Wanpeng Li" <email@example.com>, "Jim Mattson" <firstname.lastname@example.org>, "Joerg Roedel" <email@example.com>, "Tony Luck" <firstname.lastname@example.org>, "Tony W Wang-oc" <TonyWWangemail@example.com>, "Shuah Khan" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, "Jarkko Sakkinen" <email@example.com> Subject: Re: [PATCH v3 12/19] x86/vmx: Introduce VMX_FEATURES_* Date: Thu, 21 Nov 2019 13:50:17 -0800 Message-ID: <20191121215017.GC16617@linux.intel.com> (raw) In-Reply-To: <20191121165250.GK6540@zn.tnic> On Thu, Nov 21, 2019 at 05:52:58PM +0100, Borislav Petkov wrote: > On Mon, Nov 18, 2019 at 07:12:33PM -0800, Sean Christopherson wrote: > > 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. I actually don't want to use cpu_has() for the VMX features, which is why I put these in a separate array (one of the future patches). The motivation is purely for /proc/cpuinfo. Currently there is no sane way for a user to query the capabilities of their platform. The issue comes up on a fairly regular basis, e.g. when trying to find a platform to test a new feature or to debug an issue that has a hardware dependency. Lack of reporting is especially annoying when the end 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 actually enumerated as 3+ separate features by hardware, etc... Punting to a userspace utility isn't a viable option because all of the capabilities are reported via MSRs. As for why I want to keep these out of cpu_has()... VMX has a concept of features being fixed "on", e.g. early CPUs don't allow disabling off CR3 interception. A cpu_has() approach doesn't work well since it loses the information regarding which bits are fixed-1. KVM also has several module params that can be used to disable use of features, i.e. we don't want cpu_has() for VMX features because the KVM-specific variables need to be the canonical reference. > Especially since you're hiding most of them with the "" prepended in the > define comment. > > > +/* 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. Originally I wanted these to go in a completely separate line in /proc/cpuinfo, e.g. "vmx flags". That's what I submitted in v1, but then found out it'd break the ABI due to handful of VMX features being enumerated in "flags" via synthetic cpufeature bits. Paolo suggested dropping the "vmx flags" approach as an easy solution, and I obviously didn't update the names to prepend vmx_. Preprending vmx_ would be somewhat annoying because changing the names of the synthetic flags would also break the ABI... Alternatively, what about adding "vmx flags" but keeping the existing synthetic flags? That'd mean having duplicates for tpr_shadow, vnmi, ept, flexpriority, vpi and ept_ad. On the plus side, we'd cap the pollution of "flags" at those six features. > > +#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. Doh.
next prev parent reply index Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-19 3:12 [PATCH v3 00/19] x86/cpu: Clean up handling of VMX features Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 01/19] x86/msr-index: Clean up bit defines for IA32_FEATURE_CONTROL MSR Sean Christopherson 2019-11-19 11:15 ` Borislav Petkov 2019-11-19 23:18 ` Sean Christopherson 2019-11-20 17:48 ` Borislav Petkov 2019-11-21 9:46 ` Jarkko Sakkinen 2019-11-21 22:14 ` Sean Christopherson 2019-11-29 21:06 ` Jarkko Sakkinen 2019-11-29 21:11 ` Jarkko Sakkinen 2019-11-19 3:12 ` [PATCH v3 02/19] selftests: kvm: Replace manual MSR defs with common msr-index.h Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 03/19] tools arch x86: Sync msr-index.h from kernel sources Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 04/19] x86/intel: Initialize IA32_FEATURE_CONTROL MSR at boot Sean Christopherson 2019-11-19 4:41 ` Kai Huang 2019-11-19 5:03 ` Sean Christopherson 2019-11-21 10:39 ` Jarkko Sakkinen 2019-11-21 10:41 ` Jarkko Sakkinen 2019-11-21 11:05 ` Borislav Petkov 2019-11-21 22:12 ` Sean Christopherson 2019-11-22 12:34 ` Borislav Petkov 2019-11-19 3:12 ` [PATCH v3 05/19] x86/mce: WARN once if IA32_FEATURE_CONTROL MSR is left unlocked Sean Christopherson 2019-11-21 10:45 ` Jarkko Sakkinen 2019-11-19 3:12 ` [PATCH v3 06/19] x86/centaur: Use common IA32_FEATURE_CONTROL MSR initialization Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 07/19] x86/zhaoxin: " Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 08/19] KVM: VMX: Drop initialization of IA32_FEATURE_CONTROL MSR Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 09/19] x86/cpu: Clear VMX feature flag if VMX is not fully enabled Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 10/19] KVM: VMX: Use VMX feature flag to query BIOS enabling Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 11/19] KVM: VMX: Check for full VMX support when verifying CPU compatibility Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 12/19] x86/vmx: Introduce VMX_FEATURES_* Sean Christopherson 2019-11-21 16:52 ` Borislav Petkov 2019-11-21 21:50 ` Sean Christopherson [this message] 2019-11-22 18:36 ` Borislav Petkov 2019-11-22 19:09 ` Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 13/19] x86/cpu: Detect VMX features on Intel, Centaur and Zhaoxin CPUs Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 14/19] x86/cpu: Print VMX flags in /proc/cpuinfo using VMX_FEATURES_* Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 15/19] x86/cpufeatures: Drop synthetic VMX feature flags Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 16/19] KVM: VMX: Use VMX_FEATURE_* flags to define VMCS control bits Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 17/19] x86/cpufeatures: Clean up synthetic virtualization flags Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 18/19] perf/x86: Provide stubs of KVM helpers for non-Intel CPUs Sean Christopherson 2019-11-19 3:12 ` [PATCH v3 19/19] KVM: VMX: Allow KVM_INTEL when building for Centaur and/or Zhaoxin CPUs Sean Christopherson
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20191121215017.GC16617@linux.intel.com \ --firstname.lastname@example.org \ --cc=TonyWWangemail@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-kselftest Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-kselftest/0 linux-kselftest/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-kselftest linux-kselftest/ https://lore.kernel.org/linux-kselftest \ firstname.lastname@example.org public-inbox-index linux-kselftest Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-kselftest AGPL code for this site: git clone https://public-inbox.org/public-inbox.git