Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp1133470ybn; Wed, 2 Oct 2019 11:19:21 -0700 (PDT) X-Google-Smtp-Source: APXvYqwAf+ZvN70rJhjYpuRTFJFPDFYZPHFnB2JfvlIkRYmJ+ECFUuLjC07M4yMiCOQQI/iNK5hA X-Received: by 2002:a05:6402:1585:: with SMTP id c5mr5296266edv.66.1570040361419; Wed, 02 Oct 2019 11:19:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570040361; cv=none; d=google.com; s=arc-20160816; b=0liME1SioE2sVrW5Ugdq+AG9BD0TFy5lSOSmtXS2rMBI6mV49jdPDuCt6letnGl5Yh zpjR74is1YfdPqr0AJfeeoznpaEqbqOKFCguohP6Cv6zGneKiMnoFd69rb/wZCakwG2X QpIJQYZzDIKab71vqNSI8PUVdnI1/hF+GkP76rMdEG8w2Hy1icYd/rul+Iz8U7vS5rqH Bvxxk6+SDRuTW8wpgOo9lnXhtGKncSgJgI66vHE6ljnPQZHzSohdrS/76pVALsokxjVI davSTgID9djsPB9a2DnfrLLK/sYWd+gzHF14WbYgkSbEtHz+GU2y23A1dFiJPrXHuT7R NfrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=sE4hIPJblfldPa9zZyykYwpbgFP0hJyev1rPxUtG4KU=; b=ZBz+ZdG/ELjuYnshHD0YT+SZC4BcFQ3IYN5hX4U0OjKX0p4rQoIBslmMysUvgTeRSV qkv5iBluK/8Q9yR/oQSO5epiRZwNGA57Y2VbH0Hx/Ps4KNjLaI6zoJIhxbjbTzrpdiNg IW8wkkrepFuHxZMlAXn6xjJdZzcKfqzrUrC79JN+AyhgnclowYERzvOGxKRtniZfWmwj pyIoLR/TDm5oEQaYVP/xSOoJvPgI3+pTJ4BKyTgsVKAgK2G1mhstunW/16ok/GoeOuKz zuxxfOhDRGO1lDD0Tx/mxawCsxNLLOnqIYgKBX2GDSbyboRrWE2UKj14qbgkQPhOPqgE PETQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=Mt8Hq+v9; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id oq3si11347459ejb.220.2019.10.02.11.18.56; Wed, 02 Oct 2019 11:19:21 -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; dkim=pass header.i=@google.com header.s=20161025 header.b=Mt8Hq+v9; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728618AbfJBSSq (ORCPT + 99 others); Wed, 2 Oct 2019 14:18:46 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:45355 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726669AbfJBSSq (ORCPT ); Wed, 2 Oct 2019 14:18:46 -0400 Received: by mail-io1-f68.google.com with SMTP id c25so59095953iot.12 for ; Wed, 02 Oct 2019 11:18:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sE4hIPJblfldPa9zZyykYwpbgFP0hJyev1rPxUtG4KU=; b=Mt8Hq+v9ToEnDoCvIp6M0wjAgGNEwNOPReg2epy6vYbvl/pMZPfTqzbi+pk6693Jwo b8M6cYYmjK1ZA9JIQXLHOwAtFvG/hfoywsmkqz4dn+9VfYL+RW0Z4vzptkiFMlh/WvTV 4n3+9gPw8qxd3sMf2A3oEYcnTjtREneF0GiH6EQS4nxh/jBAjNsvGxMry+tnPKU97zq7 kpliKL2gMwMzMOLsTucnIC6kfAP/hCLX2iIoe+Iec4J8CBzhbWYHLrvwfkaOXLhxobVf 21c5xnNTrKj2SdD58SwnMGLOec0RuNnO/eGjNbHIUjTWG2WNNQK4jdsPklpRux3YMHXO GbKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sE4hIPJblfldPa9zZyykYwpbgFP0hJyev1rPxUtG4KU=; b=GSvhc0UCG4l3/kKTlF7CtdruJjU5pAp5QGDR53/X5gLbCm32B+dMVo6wzhsidTjY6b KeDSm53i6BARhhnJrs0UgwIuywbhcS7r38qJawtruizsa20hCR56ARnJarWeHgepow1D rra0w4nJeQ0FRZ/hBmAQO/yzDDQ4fsR8Yz+aOiEAycuIc+cHW3u+dHV3hUmUvI7e1fuH VgBRh3cpj+4GG7oOzXDxTWOgwwdj7lFXKoxZk6pTH7I04e33//nJGhMd3ENL0hAFFoMp HdMZyI6w6M+oluu5peZeKqgBLo7XR7nMP6LN9d4B2N5Nu5ppym+qDZnsbisciU3nKvtP 9Y4A== X-Gm-Message-State: APjAAAXiM67Lt17juMuLgFodK2/XQPVtuNkxOlkjZVFotVTgSJvXStCg /kT7wykDzXUZphjKlUvwT9T2lNUmQSCjVmbYXOvUwDcA X-Received: by 2002:a92:b09:: with SMTP id b9mr1924153ilf.26.1570040323223; Wed, 02 Oct 2019 11:18:43 -0700 (PDT) MIME-Version: 1.0 References: <20190927021927.23057-1-weijiang.yang@intel.com> <20190927021927.23057-4-weijiang.yang@intel.com> In-Reply-To: <20190927021927.23057-4-weijiang.yang@intel.com> From: Jim Mattson Date: Wed, 2 Oct 2019 11:18:32 -0700 Message-ID: Subject: Re: [PATCH v7 3/7] KVM: VMX: Pass through CET related MSRs to Guest To: Yang Weijiang Cc: kvm list , LKML , Paolo Bonzini , Sean Christopherson , "Michael S. Tsirkin" , =?UTF-8?B?UmFkaW0gS3LEjW3DocWZ?= Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Sep 26, 2019 at 7:17 PM Yang Weijiang wrote: > > CET MSRs pass through Guest directly to enhance performance. > CET runtime control settings are stored in MSR_IA32_{U,S}_CET, > Shadow Stack Pointer(SSP) are stored in MSR_IA32_PL{0,1,2,3}_SSP, > SSP table base address is stored in MSR_IA32_INT_SSP_TAB, > these MSRs are defined in kernel and re-used here. All of these new guest MSRs will have to be enumerated by KVM_GET_MSR_INDEX_LIST. > MSR_IA32_U_CET and MSR_IA32_PL3_SSP are used for user mode protection, > the contents could differ from process to process, therefore, > kernel needs to save/restore them during context switch, it makes > sense to pass through them so that the guest kernel can > use xsaves/xrstors to operate them efficiently. Other MSRs are used > for non-user mode protection. See CET spec for detailed info. I assume that XSAVES & XRSTORS bypass the MSR permission bitmap, like other instructions that manipulate MSRs (e.g. SWAPGS, RDTSCP, etc.). Is the guest OS likely to use RDMSR/WRMSR to access these MSRs? > The difference between CET VMCS state fields and xsave components is that, > the former used for CET state storage during VMEnter/VMExit, > whereas the latter used for state retention between Guest task/process > switch. > > Co-developed-by: Zhang Yi Z > Signed-off-by: Zhang Yi Z > Signed-off-by: Yang Weijiang > --- > arch/x86/kvm/cpuid.c | 1 + > arch/x86/kvm/cpuid.h | 2 ++ > arch/x86/kvm/vmx/vmx.c | 39 +++++++++++++++++++++++++++++++++++++++ > 3 files changed, 42 insertions(+) > > diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c > index 1aa86b87b6ab..0a47b9e565be 100644 > --- a/arch/x86/kvm/cpuid.c > +++ b/arch/x86/kvm/cpuid.c > @@ -66,6 +66,7 @@ u64 kvm_supported_xss(void) > { > return KVM_SUPPORTED_XSS & kvm_x86_ops->supported_xss(); > } > +EXPORT_SYMBOL_GPL(kvm_supported_xss); > > #define F(x) bit(X86_FEATURE_##x) > > diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h > index d78a61408243..1d77b880084d 100644 > --- a/arch/x86/kvm/cpuid.h > +++ b/arch/x86/kvm/cpuid.h > @@ -27,6 +27,8 @@ bool kvm_cpuid(struct kvm_vcpu *vcpu, u32 *eax, u32 *ebx, > > int cpuid_query_maxphyaddr(struct kvm_vcpu *vcpu); > > +u64 kvm_supported_xss(void); > + > static inline int cpuid_maxphyaddr(struct kvm_vcpu *vcpu) > { > return vcpu->arch.maxphyaddr; > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index a84198cff397..f720baa7a9ba 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -7001,6 +7001,43 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu) > vmx->pt_desc.ctl_bitmask &= ~(0xfULL << (32 + i * 4)); > } > > +static void vmx_intercept_cet_msrs(struct kvm_vcpu *vcpu) Nit: It seems like this function adjusts the MSR permission bitmap so as *not* to intercept the CET MSRs. > +{ > + struct vcpu_vmx *vmx = to_vmx(vcpu); > + unsigned long *msr_bitmap; > + u64 kvm_xss; > + bool cet_en; > + > + msr_bitmap = vmx->vmcs01.msr_bitmap; What about nested guests? (i.e. vmcs02). > + kvm_xss = kvm_supported_xss(); > + cet_en = guest_cpuid_has(vcpu, X86_FEATURE_SHSTK) || > + guest_cpuid_has(vcpu, X86_FEATURE_IBT); > + /* > + * U_CET is a must for USER CET, per CET spec., U_CET and PL3_SPP are > + * a bundle for USER CET xsaves. > + */ > + if (cet_en && (kvm_xss & XFEATURE_MASK_CET_USER)) { > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_U_CET, MSR_TYPE_RW); > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL3_SSP, MSR_TYPE_RW); > + } Since this is called from vmx_cpuid_update, what happens if cet_en was previously true and now it's false? > + /* > + * S_CET is a must for KERNEL CET, PL0_SSP ... PL2_SSP are a bundle > + * for CET KERNEL xsaves. > + */ > + if (cet_en && (kvm_xss & XFEATURE_MASK_CET_KERNEL)) { > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_S_CET, MSR_TYPE_RW); > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL0_SSP, MSR_TYPE_RW); > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL1_SSP, MSR_TYPE_RW); > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_PL2_SSP, MSR_TYPE_RW); > + > + /* SSP_TAB only available for KERNEL SHSTK.*/ > + if (guest_cpuid_has(vcpu, X86_FEATURE_SHSTK)) > + vmx_disable_intercept_for_msr(msr_bitmap, MSR_IA32_INT_SSP_TAB, > + MSR_TYPE_RW); > + } > +} > + > static void vmx_cpuid_update(struct kvm_vcpu *vcpu) > { > struct vcpu_vmx *vmx = to_vmx(vcpu); > @@ -7025,6 +7062,8 @@ static void vmx_cpuid_update(struct kvm_vcpu *vcpu) > if (boot_cpu_has(X86_FEATURE_INTEL_PT) && > guest_cpuid_has(vcpu, X86_FEATURE_INTEL_PT)) > update_intel_pt_cfg(vcpu); > + > + vmx_intercept_cet_msrs(vcpu); > } > > static void vmx_set_supported_cpuid(u32 func, struct kvm_cpuid_entry2 *entry) > -- > 2.17.2 >