From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 30A49C61DA4 for ; Fri, 27 Jan 2023 22:09:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231686AbjA0WJr (ORCPT ); Fri, 27 Jan 2023 17:09:47 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46224 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229681AbjA0WJp (ORCPT ); Fri, 27 Jan 2023 17:09:45 -0500 Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76E5C1555A for ; Fri, 27 Jan 2023 14:09:44 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id d3so6322510plr.10 for ; Fri, 27 Jan 2023 14:09:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=YE+20ePuR5Q/rSYA8Kgx1qIQvuBjNbnsIq3ynDe/WNA=; b=lrPE+NQJISKzbSzuSk7SXCzc7j/+D9EpaJD9K7rzwRWNg1kSVQNYFtP1rQ0l84SpST rRyMv3exis4Bu4Mpm1x2KAq90VRt3XpaBN+ZNdbAjDbtqUwBa8wvYFUNUuDklKESaE7r I8G7soOT/vdp4aGepBWXgqIvgelXysNDiHs6Sx6SzPOSC2P6xo8isrjFK99t4iF0pRgn qIg69R5L2CZ5mSGbigoxw2wC+Ryl15wK/J5+DDaSAcyG167+uPY4z7BZWCG5LujUY3I0 pFtbL+TdJDVbVFk68Wd5jUHG2+6VAtXhfeyeDmiUTxjA+SOVGHAEKefreamLZtNve1Kt 8MLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=YE+20ePuR5Q/rSYA8Kgx1qIQvuBjNbnsIq3ynDe/WNA=; b=czDmmPR7BHZU53Ormr754rNq3ZPZn+cy7U0Tqm02QI6mb5r9Xvy3pqt57yox/84F1x 3ow+O+ym6m39ppizGfYJ1CruMA8ZuJi99Le1LRMYji1mwARQt0yzvbz3gx+3uAp6sviB Buj+HIJ0K75TTPx6LNShUR6nvy05/tuUlMTRg8LjxCc5iYD/gCJ+nenYciY6bdtdhF0A afwRzuw9Cy02WLXI5P58rnMhtvH/Oj3Ti5x/VpMEyfLodlLPcU3SJ4qAJ7N6q0gRc+k5 cCd/+8X7Q1RMeF43OATedCliZivQyvQtInhm4yxrq2urVpcvLiOJAaU5THUi7dlpKdAo LTiQ== X-Gm-Message-State: AO0yUKVZ0ZE2nOQZsWdnogiMaE1m1n57evH5v/JEHglfP5S9qKyT6Y9R NJzkZ9KKsUGVEo1jzWTrixIDRg== X-Google-Smtp-Source: AK7set8qBf7H7/N8KBYOlsoFn/st9/Zevw7PG0vkJYPKrtvPFqWTu5e70qoyxrKgou2jY23lLsL7mQ== X-Received: by 2002:a05:6a20:3ca8:b0:b8:c859:7fc4 with SMTP id b40-20020a056a203ca800b000b8c8597fc4mr162205pzj.1.1674857383797; Fri, 27 Jan 2023 14:09:43 -0800 (PST) Received: from google.com (7.104.168.34.bc.googleusercontent.com. [34.168.104.7]) by smtp.gmail.com with ESMTPSA id y12-20020a17090a2b4c00b002293b1aa2b6sm5441275pjc.30.2023.01.27.14.09.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jan 2023 14:09:42 -0800 (PST) Date: Fri, 27 Jan 2023 22:09:39 +0000 From: Sean Christopherson To: Yang Weijiang Cc: pbonzini@redhat.com, jmattson@google.com, kvm@vger.kernel.org, linux-kernel@vger.kernel.org, like.xu.linux@gmail.com, kan.liang@linux.intel.com, wei.w.wang@intel.com Subject: Re: [PATCH v2 12/15] KVM: x86/vmx: Disable Arch LBREn bit in #DB and warm reset Message-ID: References: <20221125040604.5051-1-weijiang.yang@intel.com> <20221125040604.5051-13-weijiang.yang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20221125040604.5051-13-weijiang.yang@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 > --- > 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 >