Message ID | 20221125040604.5051-13-weijiang.yang@intel.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp3797504wrr; Thu, 24 Nov 2022 22:12:50 -0800 (PST) X-Google-Smtp-Source: AA0mqf7UedUfrahl6bVvRnecmSz694uHmcu3N4Ndw6+jnXnWGshMGtL+2bPCM8sCSltGQDVpzSdI X-Received: by 2002:a17:902:cad4:b0:189:e4e:7943 with SMTP id y20-20020a170902cad400b001890e4e7943mr19540670pld.33.1669356769814; Thu, 24 Nov 2022 22:12:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669356769; cv=none; d=google.com; s=arc-20160816; b=P5Icek7srzdQ8VTBYYViVagrQPWJTFgn6SUqWEsdGQFOP0TyK1LM+wnV5iUHJDc+up 8uIWH5VwdvujFLVumkOTaNUYN8JXTCyhSUqyoOiWZ8L5/yXVMSkMWFzprro6FPyrLC5i lMFcNXryFEYlwsUeH/p1ZHKBPOKwwtbTeLLuzOMdlhQ4DkK/rY0QqOaoqj6lE0+olYPw 3uygnWGAIPVxuS1q8fV3qJOjgqwcCH2/D77SB0rV5/G+kJYeFf77/c/B9OOZ/9z4ouPh L4KKyHDpGOoCkVSebuc7jfqo/6Ijwkj1swz3IOOli0UBY360ROurgGjXRqUB21khYCYn bHDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=Jn5gN5zZ9t91vOxrwaSSZ0lGcw0lY7VPCBZ6XgakwTI=; b=VGRq3jVQT2PPI3rGf7Lyv4LMCKKaAAEaIXq8VqfHGDGO/FSMcM2H4ByVcQJMa8ZxdE HaRV2pG3hJ3TYKfyDwIp+AmqT3SWe/EXGNfCw1+39x6nAZr2HZgn7v+Gi/5ah28F18/H lIjF+G8OIVZgTH+VCzy2wqriRuTTEDsJpeBAeU8JE91/drVrDsBq99t8bU5Ae9VK5rpt VtdhS/tZAf6VdyqvkpAe5/ZAfMTfeKHIA+ypCHb+gPP8kXEox6SVcOjwzXeyLud5L0aT C4RxzkMMKW0ktrirnm3HpUM9DYKis+SmCCEFBln41GE4DAe5iw3xof0cLac4mnu5Fttg x5rA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nLcoIkm0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b5-20020a170902e94500b00188bee77e8fsi2834974pll.35.2022.11.24.22.12.36; Thu, 24 Nov 2022 22:12:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=nLcoIkm0; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229723AbiKYGKv (ORCPT <rfc822;zxc52fgh@gmail.com> + 99 others); Fri, 25 Nov 2022 01:10:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46688 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229754AbiKYGKU (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 25 Nov 2022 01:10:20 -0500 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id CBA9E22B1C; Thu, 24 Nov 2022 22:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1669356613; x=1700892613; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=B/nXKs95F6cYlY8EdEbdbW8W7+97emyxpTHZVVLBCto=; b=nLcoIkm0rcAFXHqueAmyZzoi8L60l7Cm70dS/10EctVGC18pY4JvFWJ1 0xCrcSKyAbgcaacAw8KF0xIfOBOo3fMzJZxewvi6/Y4ofKaXFuRl7dIib dSGX2NbC/0bzoF7uGEIVef0IIF1INCnubbsl1smr9Lm1CsTEbvm+XKwR6 zmgEy0aEI92E9IaAJqfnRBjv3gancxGNLqp9dkvHjylyZ/HZFNQZIuyWg bdkuVPKfTDwQDlGIqUP23eIdKvS3phGy0x6VUUdPjHwNMN28N94h/j+dk DwA1aU8CFiTSiIloH4vp1nuIQa3t78L5aH//cmR7NNoJ24KW3fY1wZ0pl g==; X-IronPort-AV: E=McAfee;i="6500,9779,10541"; a="313116833" X-IronPort-AV: E=Sophos;i="5.96,192,1665471600"; d="scan'208";a="313116833" Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2022 22:10:08 -0800 X-IronPort-AV: E=McAfee;i="6500,9779,10541"; a="784838505" X-IronPort-AV: E=Sophos;i="5.96,192,1665471600"; d="scan'208";a="784838505" Received: from embargo.jf.intel.com ([10.165.9.183]) by fmsmga001-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 24 Nov 2022 22:10:08 -0800 From: Yang Weijiang <weijiang.yang@intel.com> To: seanjc@google.com, pbonzini@redhat.com, jmattson@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org Cc: like.xu.linux@gmail.com, kan.liang@linux.intel.com, wei.w.wang@intel.com, weijiang.yang@intel.com Subject: [PATCH v2 12/15] KVM: x86/vmx: Disable Arch LBREn bit in #DB and warm reset Date: Thu, 24 Nov 2022 23:06:01 -0500 Message-Id: <20221125040604.5051-13-weijiang.yang@intel.com> X-Mailer: git-send-email 2.27.0 In-Reply-To: <20221125040604.5051-1-weijiang.yang@intel.com> References: <20221125040604.5051-1-weijiang.yang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1750447444726406862?= X-GMAIL-MSGID: =?utf-8?q?1750447444726406862?= |
Series |
Introduce Architectural LBR for vPMU
|
|
Commit Message
Yang, Weijiang
Nov. 25, 2022, 4:06 a.m. UTC
Per SDM 3B, Chapter 18:
“On a debug breakpoint event (#DB), IA32_LBR_CTL.LBREn is cleared.”
and "On a warm reset, all LBR MSRs, including IA32_LBR_DEPTH, have their
values preserved. However, IA32_LBR_CTL.LBREn is cleared to 0, disabling
LBRs.", clear the bit manually before inject #DB or when vCPU is in warm
reset.
Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
---
arch/x86/kvm/vmx/vmx.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
Comments
On 25/11/2022 12:06 pm, Yang Weijiang wrote: > +static void disable_arch_lbr_ctl(struct kvm_vcpu *vcpu) > +{ > + struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu); > + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > + > + if (kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR) && > + test_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use) && > + lbr_desc->event) { > + u64 ctl = vmcs_read64(GUEST_IA32_LBR_CTL); > + > + vmcs_write64(GUEST_IA32_LBR_CTL, ctl & ~ARCH_LBR_CTL_LBREN); > + } > +} > + > static void vmx_inject_exception(struct kvm_vcpu *vcpu) > { > struct kvm_queued_exception *ex = &vcpu->arch.exception; > @@ -1738,6 +1752,9 @@ static void vmx_inject_exception(struct kvm_vcpu *vcpu) > vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info); > > vmx_clear_hlt(vcpu); > + > + if (ex->vector == DB_VECTOR) > + disable_arch_lbr_ctl(vcpu); Please verify this with KUT testcase, once I failed and did not confirm if it is a hardware issue. Good Luck. > }
On 12/22/2022 7:22 PM, Like Xu wrote: > On 25/11/2022 12:06 pm, Yang Weijiang wrote: >> +static void disable_arch_lbr_ctl(struct kvm_vcpu *vcpu) >> +{ >> + struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu); >> + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); >> + >> + if (kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR) && >> + test_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use) && >> + lbr_desc->event) { >> + u64 ctl = vmcs_read64(GUEST_IA32_LBR_CTL); >> + >> + vmcs_write64(GUEST_IA32_LBR_CTL, ctl & ~ARCH_LBR_CTL_LBREN); >> + } >> +} >> + >> static void vmx_inject_exception(struct kvm_vcpu *vcpu) >> { >> struct kvm_queued_exception *ex = &vcpu->arch.exception; >> @@ -1738,6 +1752,9 @@ static void vmx_inject_exception(struct >> kvm_vcpu *vcpu) >> vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info); >> vmx_clear_hlt(vcpu); >> + >> + if (ex->vector == DB_VECTOR) >> + disable_arch_lbr_ctl(vcpu); > > Please verify this with KUT testcase, once I failed and did not confirm > if it is a hardware issue. Good Luck. Can you detail what you want to verify with? > >> }
On Thu, Nov 24, 2022, Yang Weijiang wrote: > Per SDM 3B, Chapter 18: > “On a debug breakpoint event (#DB), IA32_LBR_CTL.LBREn is cleared.” > and "On a warm reset, all LBR MSRs, including IA32_LBR_DEPTH, have their > values preserved. However, IA32_LBR_CTL.LBREn is cleared to 0, disabling > LBRs.", clear the bit manually before inject #DB or when vCPU is in warm > reset. > > Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> > --- > arch/x86/kvm/vmx/vmx.c | 24 +++++++++++++++++++++++- > 1 file changed, 23 insertions(+), 1 deletion(-) > > diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c > index 3bc892e8cf7a..6ad765ea4059 100644 > --- a/arch/x86/kvm/vmx/vmx.c > +++ b/arch/x86/kvm/vmx/vmx.c > @@ -1695,6 +1695,20 @@ static void vmx_clear_hlt(struct kvm_vcpu *vcpu) > vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE); > } > > +static void disable_arch_lbr_ctl(struct kvm_vcpu *vcpu) > +{ > + struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu); > + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); > + > + if (kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR) && > + test_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use) && > + lbr_desc->event) { I don't see any reason to check that an event is actually assigned. The behavior is architectural, whether or not KVM is actively exposing LBRs to the guest is irrelevant. > + u64 ctl = vmcs_read64(GUEST_IA32_LBR_CTL); > + > + vmcs_write64(GUEST_IA32_LBR_CTL, ctl & ~ARCH_LBR_CTL_LBREN); > + } > +} > + > static void vmx_inject_exception(struct kvm_vcpu *vcpu) > { > struct kvm_queued_exception *ex = &vcpu->arch.exception; > @@ -1738,6 +1752,9 @@ static void vmx_inject_exception(struct kvm_vcpu *vcpu) > vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info); > > vmx_clear_hlt(vcpu); > + > + if (ex->vector == DB_VECTOR) > + disable_arch_lbr_ctl(vcpu); > } > > static void vmx_setup_uret_msr(struct vcpu_vmx *vmx, unsigned int msr, > @@ -4796,7 +4813,9 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) > > vmx_update_fb_clear_dis(vcpu, vmx); > > - if (!init_event && cpu_has_vmx_arch_lbr()) > + if (init_event) INIT and warm RESET are not the same thing, i.e. this is flat out wrong. > + disable_arch_lbr_ctl(vcpu); > + else if (cpu_has_vmx_arch_lbr()) > vmcs_write64(GUEST_IA32_LBR_CTL, 0); > } > > @@ -4873,6 +4892,9 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu) > INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK | NMI_VECTOR); > > vmx_clear_hlt(vcpu); > + > + if (vcpu->arch.exception.vector == DB_VECTOR) Huh? This is _very_ obviously injecting NMIs, not #DBs. > + disable_arch_lbr_ctl(vcpu); > } > > bool vmx_get_nmi_mask(struct kvm_vcpu *vcpu) > -- > 2.27.0 >
On 1/28/2023 6:09 AM, Sean Christopherson wrote: > On Thu, Nov 24, 2022, Yang Weijiang wrote: >> Per SDM 3B, Chapter 18: >> “On a debug breakpoint event (#DB), IA32_LBR_CTL.LBREn is cleared.” >> and "On a warm reset, all LBR MSRs, including IA32_LBR_DEPTH, have their >> values preserved. However, IA32_LBR_CTL.LBREn is cleared to 0, disabling >> LBRs.", clear the bit manually before inject #DB or when vCPU is in warm >> reset. >> >> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com> >> --- >> arch/x86/kvm/vmx/vmx.c | 24 +++++++++++++++++++++++- >> 1 file changed, 23 insertions(+), 1 deletion(-) >> >> diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c >> index 3bc892e8cf7a..6ad765ea4059 100644 >> --- a/arch/x86/kvm/vmx/vmx.c >> +++ b/arch/x86/kvm/vmx/vmx.c >> @@ -1695,6 +1695,20 @@ static void vmx_clear_hlt(struct kvm_vcpu *vcpu) >> vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE); >> } >> >> +static void disable_arch_lbr_ctl(struct kvm_vcpu *vcpu) >> +{ >> + struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu); >> + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); >> + >> + if (kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR) && >> + test_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use) && >> + lbr_desc->event) { > I don't see any reason to check that an event is actually assigned. The behavior > is architectural, whether or not KVM is actively exposing LBRs to the guest is > irrelevant Agree, will remove them. > >> + u64 ctl = vmcs_read64(GUEST_IA32_LBR_CTL); >> + >> + vmcs_write64(GUEST_IA32_LBR_CTL, ctl & ~ARCH_LBR_CTL_LBREN); >> + } >> +} >> + >> static void vmx_inject_exception(struct kvm_vcpu *vcpu) >> { >> struct kvm_queued_exception *ex = &vcpu->arch.exception; >> @@ -1738,6 +1752,9 @@ static void vmx_inject_exception(struct kvm_vcpu *vcpu) >> vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info); >> >> vmx_clear_hlt(vcpu); >> + >> + if (ex->vector == DB_VECTOR) >> + disable_arch_lbr_ctl(vcpu); >> } >> >> static void vmx_setup_uret_msr(struct vcpu_vmx *vmx, unsigned int msr, >> @@ -4796,7 +4813,9 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) >> >> vmx_update_fb_clear_dis(vcpu, vmx); >> >> - if (!init_event && cpu_has_vmx_arch_lbr()) >> + if (init_event) > INIT and warm RESET are not the same thing, i.e. this is flat out wrong. I was confused a bit. Is there's a way to intercept guest warm RESET so as to disable the bit? Or what should be followed per spec.? > >> + disable_arch_lbr_ctl(vcpu); >> + else if (cpu_has_vmx_arch_lbr()) >> vmcs_write64(GUEST_IA32_LBR_CTL, 0); >> } >> >> @@ -4873,6 +4892,9 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu) >> INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK | NMI_VECTOR); >> >> vmx_clear_hlt(vcpu); >> + >> + if (vcpu->arch.exception.vector == DB_VECTOR) > Huh? This is _very_ obviously injecting NMIs, not #DBs. My fault, will remove it. > >> + disable_arch_lbr_ctl(vcpu); >> } >> >> bool vmx_get_nmi_mask(struct kvm_vcpu *vcpu) >> -- >> 2.27.0 >>
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c index 3bc892e8cf7a..6ad765ea4059 100644 --- a/arch/x86/kvm/vmx/vmx.c +++ b/arch/x86/kvm/vmx/vmx.c @@ -1695,6 +1695,20 @@ static void vmx_clear_hlt(struct kvm_vcpu *vcpu) vmcs_write32(GUEST_ACTIVITY_STATE, GUEST_ACTIVITY_ACTIVE); } +static void disable_arch_lbr_ctl(struct kvm_vcpu *vcpu) +{ + struct lbr_desc *lbr_desc = vcpu_to_lbr_desc(vcpu); + struct kvm_pmu *pmu = vcpu_to_pmu(vcpu); + + if (kvm_cpu_cap_has(X86_FEATURE_ARCH_LBR) && + test_bit(INTEL_PMC_IDX_FIXED_VLBR, pmu->pmc_in_use) && + lbr_desc->event) { + u64 ctl = vmcs_read64(GUEST_IA32_LBR_CTL); + + vmcs_write64(GUEST_IA32_LBR_CTL, ctl & ~ARCH_LBR_CTL_LBREN); + } +} + static void vmx_inject_exception(struct kvm_vcpu *vcpu) { struct kvm_queued_exception *ex = &vcpu->arch.exception; @@ -1738,6 +1752,9 @@ static void vmx_inject_exception(struct kvm_vcpu *vcpu) vmcs_write32(VM_ENTRY_INTR_INFO_FIELD, intr_info); vmx_clear_hlt(vcpu); + + if (ex->vector == DB_VECTOR) + disable_arch_lbr_ctl(vcpu); } static void vmx_setup_uret_msr(struct vcpu_vmx *vmx, unsigned int msr, @@ -4796,7 +4813,9 @@ static void vmx_vcpu_reset(struct kvm_vcpu *vcpu, bool init_event) vmx_update_fb_clear_dis(vcpu, vmx); - if (!init_event && cpu_has_vmx_arch_lbr()) + if (init_event) + disable_arch_lbr_ctl(vcpu); + else if (cpu_has_vmx_arch_lbr()) vmcs_write64(GUEST_IA32_LBR_CTL, 0); } @@ -4873,6 +4892,9 @@ static void vmx_inject_nmi(struct kvm_vcpu *vcpu) INTR_TYPE_NMI_INTR | INTR_INFO_VALID_MASK | NMI_VECTOR); vmx_clear_hlt(vcpu); + + if (vcpu->arch.exception.vector == DB_VECTOR) + disable_arch_lbr_ctl(vcpu); } bool vmx_get_nmi_mask(struct kvm_vcpu *vcpu)