Received: by 10.223.176.5 with SMTP id f5csp2090265wra; Sun, 28 Jan 2018 12:22:27 -0800 (PST) X-Google-Smtp-Source: AH8x225/MLEK7BsQO1Y5UgN8qxO6WXVneaXWMT0DwXxsBw5cofpVH8gwJPC/kt8P1lcI4N8UxEQq X-Received: by 10.98.55.3 with SMTP id e3mr25307736pfa.119.1517170947148; Sun, 28 Jan 2018 12:22:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517170947; cv=none; d=google.com; s=arc-20160816; b=nBWI41gRVKaomv9HvtJJP+wyv9rLFRXXEyL2X/+WbRTQxLUNgbgyt3FHIhbEVyHaYj DlYwZOpJndawCnLwFlz9R1ND2vJaOiBDoirk+bnOMEJ+fCIg9kUTO4H6oP8Xjd7XGG46 IFtWWSFWWiRM2WTk3V28ZVYFBKYdQnzjiO5uSxNXSwLKHQmcRm2ACtblNHMbvpp6umyy LroUWpCr2yw9hPcYXulrELNQapqcC8bK3cBtbfU03aN5Kz8qNOXvs8QamvH0SEZ0lRlF 2ZrwMqgPpD0QZwUICbr5zk6ZfQRZHVaTsWRkg7S9XzTr8yxUv1dl8L7PiC9WvIaOnuj6 eghA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:from:cc:to:subject :content-transfer-encoding:mime-version:references:in-reply-to :user-agent:date:dkim-signature:arc-authentication-results; bh=zKQAcm+Uqo0vyHhitSmLwaGQSaXMs+xiORN+i0tSH/A=; b=rnVsnFswCWYOyup61REf6F0dfva7ClN5gtFQxOR0s0xBa9tIlM+YrdEI7weypbv+V+ w37GTZsEFEVtUEg/sbLyOip1o89KP0gOBRF9h+gfPBVSk+83nKVvl1V283Rx9cG84C/L 4H/kK/ntFh8JnLqTiKZ7G3rKHrSSn8OkF99iAghh7Ime6lNuKOEPLVWNdCoDdaOR5gxt TZM9wNdcWAUKaDkeBE/kkL99ebWmpxnDL4vqtz2AFGFkuWd+5xF1CkyfcpGiyqlF8z1L znPYfBLvEN0Z4SF1e8XhAJExsr4pN22Vt6IXeYOwtY5kp9Uzbw35Uts2n2lC98CgyeJo i0mQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=UuoT3lD9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n7-v6si1543113plp.140.2018.01.28.12.22.12; Sun, 28 Jan 2018 12:22:27 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=UuoT3lD9; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752594AbeA1UVn (ORCPT + 99 others); Sun, 28 Jan 2018 15:21:43 -0500 Received: from aserp2130.oracle.com ([141.146.126.79]:37780 "EHLO aserp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752570AbeA1UVh (ORCPT ); Sun, 28 Jan 2018 15:21:37 -0500 Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w0SKHvJR064707; Sun, 28 Jan 2018 20:21:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=date : in-reply-to : references : mime-version : content-type : content-transfer-encoding : subject : to : cc : from : message-id; s=corp-2017-10-26; bh=zKQAcm+Uqo0vyHhitSmLwaGQSaXMs+xiORN+i0tSH/A=; b=UuoT3lD9MIzUbnjC3qzwmGIdCW7g6sh2fX6ZWX6XZlfljZUASAtHHtMOzEH+0MhRU4uw e8Oskd2JiNzxwKCImk6msW1VT78VIs4470WsTjX1k/BSZH5mzIGQi4nOaPOSVfCLrjj/ Zj4LnzP9Ll42FldUqevyx8Ogf1hlL9m2D1n74+PtGZ5yCcuJ03MbqlZztSxu4ADDc4rK ZQosY1xybioanWQA4q+8txJBHLEu2v3prIE2up+dKhJOt6+dsFybXzbQEDjCxYhRbxY6 p+SUiYJT+wXJwG0+ouMBveSBqD1EaimOdYXbpze9IY0YAF+ZL1769lKUGlOHvoqe5v4d CQ== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp2130.oracle.com with ESMTP id 2fskv2r3c2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 28 Jan 2018 20:21:09 +0000 Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w0SKL8Xk011505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 28 Jan 2018 20:21:08 GMT Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w0SKL7lx029729; Sun, 28 Jan 2018 20:21:07 GMT Received: from [192.168.86.21] (/209.6.200.48) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 28 Jan 2018 12:21:07 -0800 Date: Sun, 28 Jan 2018 15:21:01 -0500 User-Agent: K-9 Mail for Android In-Reply-To: <1517167750-23485-1-git-send-email-karahmed@amazon.de> References: <1517167750-23485-1-git-send-email-karahmed@amazon.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH] x86: vmx: Allow direct access to MSR_IA32_SPEC_CTRL To: KarimAllah Ahmed , kvm@vger.kernel.org, linux-kernel@vger.kernel.org CC: Asit Mallick , Arjan Van De Ven , Dave Hansen , Andi Kleen , Andrea Arcangeli , Linus Torvalds , Tim Chen , Thomas Gleixner , Dan Williams , Jun Nakajima , Paolo Bonzini , David Woodhouse , Greg KH , Andy Lutomirski , Ashok Raj , daniel.kiper@oracle.com From: Konrad Rzeszutek Wilk Message-ID: <4DCAF18F-C86A-4CBC-A9CC-CC01BF63313F@oracle.com> X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8788 signatures=668655 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1801280283 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On January 28, 2018 2:29:10 PM EST, KarimAllah Ahmed = wrote: >Add direct access to MSR_IA32_SPEC_CTRL for guests=2E This is needed for >guests >that will only mitigate Spectre V2 through IBRS+IBPB and will not be >using a >retpoline+IBPB based approach=2E > >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=2E We tried this and found that it was about 3% slower that doing the old way= of rdmsr and wrmsr=2E But that was also with the host doing IBRS as well=2E On what type of hardware did you run this? Ccing Daniel=2E > >Cc: Asit Mallick >Cc: Arjan Van De Ven >Cc: Dave Hansen >Cc: Andi Kleen >Cc: Andrea Arcangeli >Cc: Linus Torvalds >Cc: Tim Chen >Cc: Thomas Gleixner >Cc: Dan Williams >Cc: Jun Nakajima >Cc: Paolo Bonzini >Cc: David Woodhouse >Cc: Greg KH >Cc: Andy Lutomirski >Signed-off-by: KarimAllah Ahmed >Signed-off-by: Ashok Raj >--- > arch/x86/kvm/cpuid=2Ec | 4 +++- > arch/x86/kvm/cpuid=2Eh | 1 + >arch/x86/kvm/vmx=2Ec | 63 >++++++++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 67 insertions(+), 1 deletion(-) > >diff --git a/arch/x86/kvm/cpuid=2Ec b/arch/x86/kvm/cpuid=2Ec >index 0099e10=2E=2Edc78095 100644 >--- a/arch/x86/kvm/cpuid=2Ec >+++ b/arch/x86/kvm/cpuid=2Ec >@@ -70,6 +70,7 @@ u64 kvm_supported_xcr0(void) > /* These are scattered features in cpufeatures=2Eh=2E */ > #define KVM_CPUID_BIT_AVX512_4VNNIW 2 > #define KVM_CPUID_BIT_AVX512_4FMAPS 3 >+#define KVM_CPUID_BIT_SPEC_CTRL 26 > #define KF(x) bit(KVM_CPUID_BIT_##x) >=20 > 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, >=20 > /* cpuid 7=2E0=2Eedx*/ > const u32 kvm_cpuid_7_0_edx_x86_features =3D >- KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS); >+ KF(AVX512_4VNNIW) | KF(AVX512_4FMAPS) | \ >+ (boot_cpu_has(X86_FEATURE_SPEC_CTRL) ? KF(SPEC_CTRL) : 0); >=20 > /* all calls to cpuid_count() should be made on the same cpu */ > get_cpu(); >diff --git a/arch/x86/kvm/cpuid=2Eh b/arch/x86/kvm/cpuid=2Eh >index cdc70a3=2E=2Edcfe227 100644 >--- a/arch/x86/kvm/cpuid=2Eh >+++ b/arch/x86/kvm/cpuid=2Eh >@@ -54,6 +54,7 @@ static const struct cpuid_reg reverse_cpuid[] =3D { > [CPUID_8000_000A_EDX] =3D {0x8000000a, 0, CPUID_EDX}, > [CPUID_7_ECX] =3D { 7, 0, CPUID_ECX}, > [CPUID_8000_0007_EBX] =3D {0x80000007, 0, CPUID_EBX}, >+ [CPUID_7_EDX] =3D { 7, 0, CPUID_EDX}, > }; >=20 >static __always_inline struct cpuid_reg x86_feature_cpuid(unsigned >x86_feature) >diff --git a/arch/x86/kvm/vmx=2Ec b/arch/x86/kvm/vmx=2Ec >index aa8638a=2E=2E1b743a0 100644 >--- a/arch/x86/kvm/vmx=2Ec >+++ b/arch/x86/kvm/vmx=2Ec >@@ -920,6 +920,9 @@ 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); >+ >=20 > static DEFINE_PER_CPU(struct vmcs *, vmxarea); > static DEFINE_PER_CPU(struct vmcs *, current_vmcs); >@@ -2007,6 +2010,28 @@ static void add_atomic_switch_msr(struct >vcpu_vmx *vmx, unsigned msr, > m->host[i]=2Evalue =3D host_val; > } >=20 >+/* do not touch guest_val and host_val if the msr is not found */ >+static int read_atomic_switch_msr(struct vcpu_vmx *vmx, unsigned msr, >+ u64 *guest_val, u64 *host_val) >+{ >+ unsigned i; >+ struct msr_autoload *m =3D &vmx->msr_autoload; >+ >+ for (i =3D 0; i < m->nr; ++i) >+ if (m->guest[i]=2Eindex =3D=3D msr) >+ break; >+ >+ if (i =3D=3D m->nr) >+ return 1; >+ >+ if (guest_val) >+ *guest_val =3D m->guest[i]=2Evalue; >+ if (host_val) >+ *host_val =3D m->host[i]=2Evalue; >+ >+ return 0; >+} >+ >static bool update_transition_efer(struct vcpu_vmx *vmx, int >efer_offset) > { > u64 guest_efer =3D vmx->vcpu=2Earch=2Eefer; >@@ -3203,7 +3228,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 =3D 0; > struct shared_msr_entry *msr; >+ struct vcpu_vmx *vmx =3D to_vmx(vcpu); >=20 > switch (msr_info->index) { > #ifdef CONFIG_X86_64 >@@ -3223,6 +3250,19 @@ static int vmx_get_msr(struct kvm_vcpu *vcpu, >struct msr_data *msr_info) > case MSR_IA32_TSC: > msr_info->data =3D 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 it was never >+ * written to=2E So the MSR value will be '0'=2E >+ */ >+ read_atomic_switch_msr(vmx, MSR_IA32_SPEC_CTRL, &spec_ctrl, NULL); >+ >+ msr_info->data =3D spec_ctrl; >+ break; > case MSR_IA32_SYSENTER_CS: > msr_info->data =3D vmcs_read32(GUEST_SYSENTER_CS); > break; >@@ -3289,6 +3329,13 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, >struct msr_data *msr_info) > int ret =3D 0; > u32 msr_index =3D msr_info->index; > u64 data =3D msr_info->data; >+ unsigned long *msr_bitmap; >+ >+ /* >+ * IBRS is not used (yet) to protect the host=2E Once it does, this >+ * variable needs to be a bit smarter=2E >+ */ >+ u64 host_spec_ctrl =3D 0; >=20 > switch (msr_index) { > case MSR_EFER: >@@ -3330,6 +3377,22 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, >struct msr_data *msr_info) > case MSR_IA32_TSC: > kvm_write_tsc(vcpu, msr_info); > break; >+ case MSR_IA32_SPEC_CTRL: >+ if (!msr_info->host_initiated && >+ !guest_cpuid_has(vcpu, X86_FEATURE_SPEC_CTRL)) >+ return 1; >+ >+ /* >+ * Now we know that the guest is actually using the MSR, so >+ * atomically load and save the SPEC_CTRL MSR and pass it >+ * through to the guest=2E >+ */ >+ add_atomic_switch_msr(vmx, MSR_IA32_SPEC_CTRL, msr_info->data, >+ host_spec_ctrl); >+ msr_bitmap =3D vmx->vmcs01=2Emsr_bitmap; >+ vmx_disable_intercept_for_msr(msr_bitmap, MSR_FS_BASE, MSR_TYPE_RW); >+ >+ break; > case MSR_IA32_CR_PAT: > if (vmcs_config=2Evmentry_ctrl & VM_ENTRY_LOAD_IA32_PAT) { > if (!kvm_mtrr_valid(vcpu, MSR_IA32_CR_PAT, data))