linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: KarimAllah Ahmed <karahmed@amazon.de>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	x86@kernel.org
Cc: Asit Mallick <asit.k.mallick@intel.com>,
	Arjan Van De Ven <arjan.van.de.ven@intel.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Andi Kleen <ak@linux.intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	 Thomas Gleixner <tglx@linutronix.de>,
	Dan Williams <dan.j.williams@intel.com>,
	Jun Nakajima <jun.nakajima@intel.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Greg KH <gregkh@linuxfoundation.org>,
	Andy Lutomirski <luto@kernel.org>,
	 Ashok Raj <ashok.raj@intel.com>
Subject: Re: [PATCH v2 2/4] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL
Date: Mon, 29 Jan 2018 08:15:49 +0000	[thread overview]
Message-ID: <1517213749.6624.103.camel@infradead.org> (raw)
In-Reply-To: <1517187532-32286-3-git-send-email-karahmed@amazon.de>

[-- Attachment #1: Type: text/plain, Size: 6143 bytes --]

On Mon, 2018-01-29 at 01:58 +0100, KarimAllah Ahmed wrote:
> Add direct access to MSR_IA32_SPEC_CTRL for guests. This is needed for
> guests that will only mitigate Spectre V2 through IBRS+IBPB and will not
> be using a retpoline+IBPB based approach.
> 
> To avoid the overhead of atomically saving and restoring the
> MSR_IA32_SPEC_CTRL for guests that do not actually use the MSR, only
> add_atomic_switch_msr when a non-zero is written to it.
> 
> Cc: Asit Mallick <asit.k.mallick@intel.com>
> Cc: Arjan Van De Ven <arjan.van.de.ven@intel.com>
> Cc: Dave Hansen <dave.hansen@intel.com>
> Cc: Andi Kleen <ak@linux.intel.com>
> Cc: Andrea Arcangeli <aarcange@redhat.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Tim Chen <tim.c.chen@linux.intel.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Jun Nakajima <jun.nakajima@intel.com>
> Cc: Paolo Bonzini <pbonzini@redhat.com>
> Cc: David Woodhouse <dwmw@amazon.co.uk>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Ashok Raj <ashok.raj@intel.com>
> Signed-off-by: KarimAllah Ahmed <karahmed@amazon.de>
> 
> ---
> v2:
> - remove 'host_spec_ctrl' in favor of only a comment (dwmw@).
> - special case writing '0' in SPEC_CTRL to avoid confusing live-migration
>   when the instance never used the MSR (dwmw@).

Possibly wants a comment in the code explaining this in slightly more
detail. The point being that if we migrate a guest which has never used
the MSR, we don't want the act of setting it to zero on resume to flip
it into the auto-saved mode.
 
> - depend on X86_FEATURE_IBRS instead of X86_FEATURE_SPEC_CTRL (dwmw@).
> - add MSR_IA32_SPEC_CTRL to the list of MSRs to save (dropped it by accident).
> ---
>  arch/x86/kvm/cpuid.c |  4 +++-
>  arch/x86/kvm/vmx.c   | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++
>  arch/x86/kvm/x86.c   |  1 +
>  3 files changed, 69 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 0099e10..32c0c14 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -70,6 +70,7 @@ u64 kvm_supported_xcr0(void)
>  /* These are scattered features in cpufeatures.h. */
>  #define KVM_CPUID_BIT_AVX512_4VNNIW     2
>  #define KVM_CPUID_BIT_AVX512_4FMAPS     3
> +#define KVM_CPUID_BIT_IBRS              26
>  #define KF(x) bit(KVM_CPUID_BIT_##x)
>  
>  int kvm_update_cpuid(struct kvm_vcpu *vcpu)
> @@ -392,7 +393,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 *entry, u32 function,
>  
>  	/* cpuid 7.0.edx*/
>  	const u32 kvm_cpuid_7_0_edx_x86_features =
> -		KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS);
> +		KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS) | \
> +		(boot_cpu_has(X86_FEATURE_IBRS) ? KF(IBRS) : 0);
>  	/* all calls to cpuid_count() should be made on the same cpu */
>  	get_cpu();

I think we need to expose more feature bits than that. See
https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86/pti&id=2961298efe1ea1b6fc0d7ee8b76018fa6c0bcef2

There are three AMD bits for IBRS, IBPB & STIBP which are the user-
visible ones in /proc/cpuinfo, and the ones we use within the kernel to
indicate the hardware availability (there are separate feature bits for
when we're *using* IBPB etc., but that's only because feature bits are
the only thing that ALTERNATIVEs can work from).

In addition to those bits, Intel has its own. The Intel SPEC_CTRL CPUID
bit (which you're setting above) indicates *both* IBRS and IBPB
capability. The kernel sets the corresponding AMD bits when it sees
SPEC_CTRL. Likewise Intel has a different bit for STIBP.

You could construct a set of CPUID bits for the guest based on what the
host has. So all three of the AMD IBRS/IBPB/STIBP bits in 80000008/EBX
should just be passed through, and you could set the Intel SPEC_CTRL
bit (7/EDX bit 26 that you're looking at above) only when you have
X86_FEATURE_IBPB && X86_FEATURE_IBRS. And the Intel STIBP when you have
X86_FEATURE_STIBP.

The Intel ARCH_CAPABILITIES CPUID bit is separate. Pass that through if
you have it, and expose the corresponding MSR read-only.


> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index aa8638a..dac564d 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -920,6 +920,8 @@ static void vmx_set_nmi_mask(struct kvm_vcpu *vcpu, bool masked);
>  static bool nested_vmx_is_page_fault_vmexit(struct vmcs12 *vmcs12,
>  					    u16 error_code);
>  static void vmx_update_msr_bitmap(struct kvm_vcpu *vcpu);
> +static void __always_inline vmx_disable_intercept_for_msr(unsigned long *msr_bitmap,
> +							  u32 msr, int type);
>  
>  static DEFINE_PER_CPU(struct vmcs *, vmxarea);
>  static DEFINE_PER_CPU(struct vmcs *, current_vmcs);

Perhaps move that whole function further up?

>  static bool update_transition_efer(struct vcpu_vmx *vmx, int efer_offset)
>  {
>  	u64 guest_efer = vmx->vcpu.arch.efer;
> @@ -3203,7 +3227,9 @@ static inline bool vmx_feature_control_msr_valid(struct kvm_vcpu *vcpu,
>   */
>  static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  {
> +	u64 spec_ctrl = 0;

Could you ditch this additional variable and...

>  	struct shared_msr_entry *msr;
> +	struct vcpu_vmx *vmx = to_vmx(vcpu);
>  
>  	switch (msr_info->index) {
>  #ifdef CONFIG_X86_64
> @@ -3223,6 +3249,20 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>  	case MSR_IA32_TSC:
>  		msr_info->data = guest_read_tsc(vcpu);
>  		break;
> +	case MSR_IA32_SPEC_CTRL:
> +		if (!msr_info->host_initiated &&
> +		    !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL))
> +			return 1;
> +
> +		/*
> +		 * If the MSR is not in the atomic list yet, then the guest
> +		 * never wrote a non-zero value to it yet i.e. the MSR value is
> +		 * '0'.
> +		 */

...
    if (read_atomic_switch_msr(vmx, MSR_IA32_SPEC_CTRL, &msr_info->data, NULL))
        msr_info->data = 0;

[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5213 bytes --]

  reply	other threads:[~2018-01-29  8:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-29  0:58 [PATCH v2 0/4] KVM: Expose speculation control feature to guests KarimAllah Ahmed
2018-01-29  0:58 ` [PATCH v2 1/4] x86: kvm: Update the reverse_cpuid list to include CPUID_7_EDX KarimAllah Ahmed
2018-01-29 10:37   ` Paolo Bonzini
2018-01-29 18:58   ` Jim Mattson
2018-01-29  0:58 ` [PATCH v2 2/4] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL KarimAllah Ahmed
2018-01-29  8:15   ` David Woodhouse [this message]
2018-01-29 10:44   ` Paolo Bonzini
2018-01-29 12:12     ` KarimAllah Ahmed
2018-01-29 19:03   ` Jim Mattson
2018-01-29  0:58 ` [PATCH v2 3/4] x86/kvm: Add IBPB support KarimAllah Ahmed
2018-01-29 19:19   ` Jim Mattson
2018-01-29  0:58 ` [PATCH v2 4/4] x86: vmx: Allow direct access to MSR_IA32_ARCH_CAPABILITIES KarimAllah Ahmed
2018-01-29 10:45   ` Paolo Bonzini
2018-01-29 14:18     ` Van De Ven, Arjan
2018-01-29 18:55   ` Jim Mattson
2018-01-29 18:57     ` KarimAllah Ahmed

Reply instructions:

You may reply publicly 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=1517213749.6624.103.camel@infradead.org \
    --to=dwmw2@infradead.org \
    --cc=aarcange@redhat.com \
    --cc=ak@linux.intel.com \
    --cc=arjan.van.de.ven@intel.com \
    --cc=ashok.raj@intel.com \
    --cc=asit.k.mallick@intel.com \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jun.nakajima@intel.com \
    --cc=karahmed@amazon.de \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    --cc=torvalds@linux-foundation.org \
    --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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).