Received: by 2002:ac0:bc90:0:0:0:0:0 with SMTP id a16csp1590392img; Tue, 19 Mar 2019 10:56:24 -0700 (PDT) X-Google-Smtp-Source: APXvYqw7bv+5oR30osk36DbzmWu4qir3pZ2Gzb+EbAO7Uqoi7EBGUNC/ar32y/vF2Tw83xZ0ZAQ/ X-Received: by 2002:a63:f84c:: with SMTP id v12mr2994465pgj.323.1553018184733; Tue, 19 Mar 2019 10:56:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553018184; cv=none; d=google.com; s=arc-20160816; b=kfTXJvp7QCUUdR768qUvPdNUS8wFBhAAXb5agWdAlt+DahRuG1aXWVr+k32JR5Lv/q ogg6lF8Zkm7rq4A6bRhbgayvoEkUJbQ7Hit+k2UDhDupVYOdi6H+VXPPpE/b/FPd9Kt1 bvgMsNtoSo6mmsSEnqqboKrRDAl3Zyp37qhWNoA5gAbESH1AaseGRoUEnBXZb2ZA50Cm iHpk2bbBcK+yTL/AmKoY9mUaya5SMx4hdgWsRI0N8HSY1BPSSfcYDQ+lcVHIgOTSNAMd Cvv533Xr13v4GeCzcV8DjZ4GDNBi+GUg6fXWzCwQ8vxb+L4pVaMCVc9ombmnKX+oTXlA +36w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:date:cc:to:from:subject:message-id; bh=9NmBUEz4hBOhHV7ZCrYw6t0AuFg6G3I+tTm+rw2nf6s=; b=wdekLMy8ig1mOgiKNqX7Tw65oZk82yemCI6sA5lww9E4SyLvOMex7GRgpDic4jgAeu 0Eb6GTePjvM9Z7TlQE86m0fKX64G9cKn3Vfvrfx6XcUOx0IYWpWx3IpdJx6Q13YgXMQM YIGm/NpexECZRPd7eEWZjGiR7h6e5gQB2z78v+eAxXu/M1SA/y+sO2dDCKWcNSFkkng+ 9V+w5JJP2CzXUYGRTqN4KtDd6UZoAeMIPEGP0C6bJfs9WwesbsxqkLCG3ga7IQgupvjf 09y2hPguzKm0FaJMQEFt5lz/5S4BI6MLiuj/cBRHruAyOC9MqT6LF11+ckSmQQNEdNxw hS/w== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 64si13045997plk.279.2019.03.19.10.56.08; Tue, 19 Mar 2019 10:56:24 -0700 (PDT) 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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727674AbfCSRyz (ORCPT + 99 others); Tue, 19 Mar 2019 13:54:55 -0400 Received: from mga09.intel.com ([134.134.136.24]:26544 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726926AbfCSRyz (ORCPT ); Tue, 19 Mar 2019 13:54:55 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Mar 2019 10:54:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,245,1549958400"; d="scan'208";a="328708716" Received: from lxy-dell.sh.intel.com ([10.239.159.145]) by fmsmga006.fm.intel.com with ESMTP; 19 Mar 2019 10:54:51 -0700 Message-ID: <73fefa02cafb0e94de0c2928185560e092fe137e.camel@linux.intel.com> Subject: Re: [PATCH v2 2/2] kvm/vmx: Using hardware cpuid faulting to avoid emulation overhead From: Xiaoyao Li To: Sean Christopherson Cc: kvm@vger.kernel.org, Paolo Bonzini , Radim =?UTF-8?Q?Kr=C4=8Dm=C3=A1=C5=99?= , Thomas Gleixner , Ingo Molnar , Borislav Petkov , "H. Peter Anvin" , linux-kernel@vger.kernel.org, chao.gao@intel.com Date: Wed, 20 Mar 2019 01:51:28 +0800 In-Reply-To: <20190319142849.GB25575@linux.intel.com> References: <20190318114324.14198-1-xiaoyao.li@linux.intel.com> <20190318114324.14198-3-xiaoyao.li@linux.intel.com> <20190318163832.GB13528@linux.intel.com> <085cc389df4d734ee173bb4c199776591d197a21.camel@linux.intel.com> <20190319142849.GB25575@linux.intel.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 (3.28.5-2.el7) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2019-03-19 at 07:28 -0700, Sean Christopherson wrote: > On Tue, Mar 19, 2019 at 12:37:23PM +0800, Xiaoyao Li wrote: > > On Mon, 2019-03-18 at 09:38 -0700, Sean Christopherson wrote: > > > On Mon, Mar 18, 2019 at 07:43:24PM +0800, Xiaoyao Li wrote: > > > > Current cpuid faulting of guest is purely emulated in kvm, which > > > > exploits > > > > CPUID vm exit to inject #GP to guest. However, if host hardware cpu has > > > > X86_FEATURE_CPUID_FAULT, we can just use the hardware cpuid faulting for > > > > guest to avoid the vm exit overhead. > > > > > > Heh, I obviously didn't look at this patch before responding to patch 1/2. > > > > > > > Note: cpuid faulting takes higher priority over CPUID instruction vm > > > > exit (Intel SDM vol3.25.1.1). > > > > > > > > Since cpuid faulting only exists on some Intel's cpu, just apply this > > > > optimization to vmx. > > > > > > > > Signed-off-by: Xiaoyao Li > > > > --- > > > > arch/x86/include/asm/kvm_host.h | 2 ++ > > > > arch/x86/kvm/vmx/vmx.c | 19 +++++++++++++++---- > > > > arch/x86/kvm/x86.c | 15 ++++++++++++--- > > > > 3 files changed, 29 insertions(+), 7 deletions(-) > > > > > > > > diff --git a/arch/x86/include/asm/kvm_host.h > > > > b/arch/x86/include/asm/kvm_host.h > > > > index ce79d7bfe1fd..14cad587b804 100644 > > > > --- a/arch/x86/include/asm/kvm_host.h > > > > +++ b/arch/x86/include/asm/kvm_host.h > > > > @@ -1339,6 +1339,8 @@ void kvm_lmsw(struct kvm_vcpu *vcpu, unsigned long > > > > msw); > > > > void kvm_get_cs_db_l_bits(struct kvm_vcpu *vcpu, int *db, int *l); > > > > int kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr); > > > > > > > > +int kvm_supported_msr_misc_features_enables(struct kvm_vcpu *vcpu, u64 > > > > data); > > > > + > > > > int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr); > > > > int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data *msr); > > > > > > > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > > > > index 2c59e0209e36..6b413e471dca 100644 > > > > --- a/arch/x86/kvm/vmx/vmx.c > > > > +++ b/arch/x86/kvm/vmx/vmx.c > > > > @@ -1037,7 +1037,7 @@ static void pt_guest_exit(struct vcpu_vmx *vmx) > > > > > > > > static void vmx_save_host_cpuid_fault(struct vcpu_vmx *vmx) > > > > { > > > > - u64 host_val; > > > > + u64 host_val, guest_val; > > > > > > > > if (!boot_cpu_has(X86_FEATURE_CPUID_FAULT)) > > > > return; > > > > @@ -1045,10 +1045,12 @@ static void vmx_save_host_cpuid_fault(struct > > > > vcpu_vmx *vmx) > > > > rdmsrl(MSR_MISC_FEATURES_ENABLES, host_val); > > > > vmx->host_msr_misc_features_enables = host_val; > > > > > > > > - /* clear cpuid fault bit to avoid it leak to guest */ > > > > - if (host_val & MSR_MISC_FEATURES_ENABLES_CPUID_FAULT) { > > > > + guest_val = vmx->vcpu.arch.msr_misc_features_enables; > > > > + > > > > + /* we can use the hardware cpuid faulting to avoid emulation > > > > overhead */ > > > > + if ((host_val ^ guest_val) & > > > > MSR_MISC_FEATURES_ENABLES_CPUID_FAULT) { > > > > wrmsrl(MSR_MISC_FEATURES_ENABLES, > > > > - host_val & > > > > ~MSR_MISC_FEATURES_ENABLES_CPUID_FAULT); > > > > + host_val ^ > > > > MSR_MISC_FEATURES_ENABLES_CPUID_FAULT); > > > > } > > > > } > > > > > > > > @@ -2057,6 +2059,15 @@ static int vmx_set_msr(struct kvm_vcpu *vcpu, > > > > struct > > > > msr_data *msr_info) > > > > else > > > > vmx->pt_desc.guest.addr_a[index / 2] = data; > > > > break; > > > > + case MSR_MISC_FEATURES_ENABLES: > > > > + if (!kvm_supported_msr_misc_features_enables(vcpu, > > > > data)) > > > > + return 1; > > > > + if (boot_cpu_has(X86_FEATURE_CPUID_FAULT)) { > > > > + if (vmx->loaded_cpu_state) > > > > > > No need for two separate if statements. And assuming we're checking the > > > existing shadow value when loading guest/host state, the WRMSR should > > > only be done if the host's value is non-zero. > > > > I'll combine these two if statements into one. > > > > I cannot understand why the WRMSR should only be done if the host's value is > > non-zero. I think there is no depedency with host's value, if using the > > hardware > > cpuid faulting. We just need to set the value to real hardware MSR. > > What I was trying to say in patch 1/2 regarding save/restore, is that I > don't think it is worthwhile to voluntarily switch hardware's value. In > other words, do the WRMSR if and only if it's absolutely necessary. And > that means only installing the guest's value if the host's value is > non-zero and host_val != guest_val. If the host's value is zero, then > the guest's value is irrelevant as CPUID faulting behavior will naturally > be taken care of when intercepting CPUID. And for obvious reasons the > WRMSR can be skipped if host and guest want the same value. The purpose of this patch is always using hardware cpuid fault if hardware cpu has this feature. Because emuated cpuid faulting needs entire vmexit process, but using hardware cpuid faulting just adds two WRMSR in save/restore cycle only when host_val != guest_val. Also I conclude the handling ou said as below: When host's value is zero, we do nothing to this MSR, and let guest ues emulated cpuid faulting through CPUID intercepting. When host's value is non-zero, we load the guest'value into hardware MSR, which means we use hardware cpuid faulting. So the difference is when host value is zero, you choose to use emulated cpuid faulting. What's meaning of chooseing emualtion or hardware feature based on host's value? > As it pertains to this code, we should not modify any hardware value that > isn't saved/restored. If we go with the above approach, then we're only > switching the hardware MSR when the host's value is non-zero. Ergo this > code should not write the actual MSR if the host value is zero as the MSR > will not be restored to the host's value when putting the vCPU. > > > > > + wrmsrl(MSR_MISC_FEATURES_ENABLES, data); > > > > + } > > > > + vcpu->arch.msr_misc_features_enables = data; > > > > + break; > > > > case MSR_TSC_AUX: > > > > if (!msr_info->host_initiated && > > > > !guest_cpuid_has(vcpu, X86_FEATURE_RDTSCP)) > > > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > > > > index 434ec113cc79..33a8c95b2f2e 100644 > > > > --- a/arch/x86/kvm/x86.c > > > > +++ b/arch/x86/kvm/x86.c > > > > @@ -2449,6 +2449,17 @@ static void record_steal_time(struct kvm_vcpu > > > > *vcpu) > > > > &vcpu->arch.st.steal, sizeof(struct kvm_steal_time)); > > > > } > > > > > > > > +int kvm_supported_msr_misc_features_enables(struct kvm_vcpu *vcpu, u64 > > > > data) > > > > +{ > > > > + if (data & ~MSR_MISC_FEATURES_ENABLES_CPUID_FAULT || > > > > + (data & MSR_MISC_FEATURES_ENABLES_CPUID_FAULT && > > > > + !supports_cpuid_fault(vcpu))) > > > > + return 0; > > > > + else > > > > + return 1; > > > > +} > > > > +EXPORT_SYMBOL_GPL(kvm_supported_msr_misc_features_enables); > > > > + > > > > int kvm_set_msr_common(struct kvm_vcpu *vcpu, struct msr_data > > > > *msr_info) > > > > { > > > > bool pr = false; > > > > @@ -2669,9 +2680,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, > > > > struct > > > > msr_data *msr_info) > > > > vcpu->arch.msr_platform_info = data; > > > > break; > > > > case MSR_MISC_FEATURES_ENABLES: > > > > - if (data & ~MSR_MISC_FEATURES_ENABLES_CPUID_FAULT || > > > > - (data & MSR_MISC_FEATURES_ENABLES_CPUID_FAULT && > > > > - !supports_cpuid_fault(vcpu))) > > > > + if (!kvm_supported_msr_misc_features_enables(vcpu, > > > > data)) > > > > return 1; > > > > vcpu->arch.msr_misc_features_enables = data; > > > > break; > > > > -- > > > > 2.19.1 > > > >