KVM Archive on lore.kernel.org
 help / color / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Thomas Gleixner" <tglx@linutronix.de>,
	"Ingo Molnar" <mingo@redhat.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Mark Rutland" <mark.rutland@arm.com>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Jiri Olsa" <jolsa@redhat.com>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Radim Krčmář" <rkrcmar@redhat.com>,
	"Vitaly Kuznetsov" <vkuznets@redhat.com>,
	"Wanpeng Li" <wanpengli@tencent.com>,
	"Jim Mattson" <jmattson@google.com>,
	"Joerg Roedel" <joro@8bytes.org>,
	"Tony Luck" <tony.luck@intel.com>,
	"Tony W Wang-oc" <TonyWWang-oc@zhaoxin.com>,
	"Shuah Khan" <shuah@kernel.org>,
	linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
	linux-edac@vger.kernel.org, linux-kselftest@vger.kernel.org,
	"Jarkko Sakkinen" <jarkko.sakkinen@linux.intel.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.

  reply index

Thread overview: 42+ 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-21 16:24   ` Borislav Petkov
2019-11-21 21:07     ` Sean Christopherson
2019-11-22 16:02       ` Borislav Petkov
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 \
    --to=sean.j.christopherson@intel.com \
    --cc=TonyWWang-oc@zhaoxin.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jarkko.sakkinen@linux.intel.com \
    --cc=jmattson@google.com \
    --cc=jolsa@redhat.com \
    --cc=joro@8bytes.org \
    --cc=kvm@vger.kernel.org \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rkrcmar@redhat.com \
    --cc=shuah@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=tony.luck@intel.com \
    --cc=vkuznets@redhat.com \
    --cc=wanpengli@tencent.com \
    --cc=x86@kernel.org \
    /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

KVM Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/kvm/0 kvm/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 kvm kvm/ https://lore.kernel.org/kvm \
		kvm@vger.kernel.org
	public-inbox-index kvm

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.kvm


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git