All of lore.kernel.org
 help / color / mirror / Atom feed
From: Like Xu <like.xu.linux@gmail.com>
To: Yang Weijiang <weijiang.yang@intel.com>,
	Jim Mattson <jmattson@google.com>
Cc: pbonzini@redhat.com, seanjc@google.com, vkuznets@redhat.com,
	wei.w.wang@intel.com, kvm@vger.kernel.org,
	linux-kernel@vger.kernel.org, Like Xu <like.xu@linux.intel.com>
Subject: Re: [PATCH v5 05/13] KVM: vmx/pmu: Emulate MSR_ARCH_LBR_CTL for guest Arch LBR
Date: Mon, 12 Jul 2021 18:10:30 +0800	[thread overview]
Message-ID: <bd386ed1-69d8-39ab-8bee-6e3aed8d2ee2@gmail.com> (raw)
In-Reply-To: <20210712093626.GC12162@intel.com>

On 12/7/2021 5:36 pm, Yang Weijiang wrote:
> On Fri, Jul 09, 2021 at 02:55:35PM -0700, Jim Mattson wrote:
>> On Fri, Jul 9, 2021 at 2:51 AM Yang Weijiang <weijiang.yang@intel.com> wrote:
>>>
>>> From: Like Xu <like.xu@linux.intel.com>
>>>
>>> Arch LBRs are enabled by setting MSR_ARCH_LBR_CTL.LBREn to 1. A new guest
>>> state field named "Guest IA32_LBR_CTL" is added to enhance guest LBR usage.
>>> When guest Arch LBR is enabled, a guest LBR event will be created like the
>>> model-specific LBR does. Clear guest LBR enable bit on host PMI handling so
>>> guest can see expected config.
>>>
>>> On processors that support Arch LBR, MSR_IA32_DEBUGCTLMSR[bit 0] has no
>>> meaning. It can be written to 0 or 1, but reads will always return 0.
>>> Like IA32_DEBUGCTL, IA32_ARCH_LBR_CTL msr is also reserved on INIT.
>>
>> I suspect you mean "preserved" rather than "reserved."
> Yes, should be preserved.
> 
>>
>>> Signed-off-by: Like Xu <like.xu@linux.intel.com>
>>> Signed-off-by: Yang Weijiang <weijiang.yang@intel.com>
>>> ---
>>>   arch/x86/events/intel/lbr.c      |  2 --
>>>   arch/x86/include/asm/msr-index.h |  1 +
>>>   arch/x86/include/asm/vmx.h       |  2 ++
>>>   arch/x86/kvm/vmx/pmu_intel.c     | 31 ++++++++++++++++++++++++++-----
>>>   arch/x86/kvm/vmx/vmx.c           |  9 +++++++++
>>>   5 files changed, 38 insertions(+), 7 deletions(-)
>>>
>>
>>> diff --git a/arch/x86/kvm/vmx/pmu_intel.c b/arch/x86/kvm/vmx/pmu_intel.c
>>> index da68f0e74702..4500c564c63a 100644
>>> --- a/arch/x86/kvm/vmx/pmu_intel.c
>>> +++ b/arch/x86/kvm/vmx/pmu_intel.c
>>> @@ -19,6 +19,11 @@
>>>   #include "pmu.h"
>>>
>>>   #define MSR_PMC_FULL_WIDTH_BIT      (MSR_IA32_PMC0 - MSR_IA32_PERFCTR0)
>>> +/*
>>> + * Regardless of the Arch LBR or legacy LBR, when the LBR_EN bit 0 of the
>>> + * corresponding control MSR is set to 1, LBR recording will be enabled.
>>> + */
>>
>> Is this comment misplaced? It doesn't seem to have anything to do with
>> the macro being defined below.
> Agree, will put this in commit message.
>>
>>> @@ -458,6 +467,14 @@ static int intel_pmu_set_msr(struct kvm_vcpu *vcpu, struct msr_data *msr_info)
>>>                  lbr_desc->records.nr = data;
>>>                  lbr_desc->arch_lbr_reset = true;
>>>                  return 0;
>>> +       case MSR_ARCH_LBR_CTL:
>>> +               if (data & ~KVM_ARCH_LBR_CTL_MASK)
>>
>> Is a static mask sufficient? Per the Intel® Architecture Instruction
>> Set Extensions and Future Features Programming Reference, some of
>> these bits may not be supported on all microarchitectures. See Table
>> 7-8. CPUID Leaf 01CH Enumeration of Architectural LBR Capabilities.
> Yes, more sanity checks are required, thanks!
> 
>>
>>> +                       break;
>>> +               vmcs_write64(GUEST_IA32_LBR_CTL, data);
>>> +               if (intel_pmu_lbr_is_enabled(vcpu) && !lbr_desc->event &&
>>> +                   (data & ARCH_LBR_CTL_LBREN))
>>> +                       intel_pmu_create_guest_lbr_event(vcpu);
>>
>> Nothing has to be done when the LBREN bit goes from 1 to 0?
> Need to release the event and reset related flag when the bit goes from
> 1 to 0. Thanks!

No need to release the LBR event and it will be lazily released.

>>
>>> +               return 0;
>>>          default:
>>>                  if ((pmc = get_gp_pmc(pmu, msr, MSR_IA32_PERFCTR0)) ||
>>>                      (pmc = get_gp_pmc(pmu, msr, MSR_IA32_PMC0))) {
>>
>> Per the Intel® Architecture Instruction Set Extensions and Future
>> Features Programming Reference, "IA32_LBR_CTL.LBREn is saved and
>> cleared on #SMI, and restored on RSM." I don't see that happening
>> anywhere. That manual also says, "On a warm reset...IA32_LBR_CTL.LBREn
>> is cleared to 0, disabling LBRs." I don't see that happening either.
> 
> Yes, I'll add related code to make it consistent with spec, thanks!
>>
>> I have a question about section 7.1.4.4 in that manual. It says, "On a
>> debug breakpoint event (#DB), IA32_LBR_CTL.LBREn is cleared." When,
>> exactly, does that happen? In particular, if kvm synthesizes such an
>> event (for example, in kvm_vcpu_do_singlestep), does
>> IA32_LBR_CTL.LBREn automatically get cleared (after loading the guest
>> IA32_LBR_CTL value from the VMCS)? Or does kvm need to explicitly
>> clear that bit in the VMCS before injecting the #DB?
> OK, I don't have answer now, will ask the Arch to get clear answer on this,
> thanks for raising the question!

I think we also need a kvm-unit-tests to cover it (as well as the legacy 
LBR).

> 

  reply	other threads:[~2021-07-12 10:12 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-09 10:04 [PATCH v5 00/13] Introduce Architectural LBR for vPMU Yang Weijiang
2021-07-09 10:04 ` [PATCH v5 01/13] perf/x86/intel: Fix the comment about guest LBR support on KVM Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 02/13] perf/x86/lbr: Simplify the exposure check for the LBR_INFO registers Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 03/13] KVM: x86: Add arch LBR MSRs to msrs_to_save_all list Yang Weijiang
2021-07-09 18:24   ` Jim Mattson
2021-07-12  8:55     ` Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 04/13] KVM: vmx/pmu: Emulate MSR_ARCH_LBR_DEPTH for guest Arch LBR Yang Weijiang
2021-07-09 20:35   ` Jim Mattson
2021-07-12  9:17     ` Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 05/13] KVM: vmx/pmu: Emulate MSR_ARCH_LBR_CTL " Yang Weijiang
2021-07-09 21:55   ` Jim Mattson
2021-07-12  9:36     ` Yang Weijiang
2021-07-12 10:10       ` Like Xu [this message]
2021-07-13  9:05         ` Yang Weijiang
2021-07-10  0:42   ` kernel test robot
2021-07-10  0:42     ` kernel test robot
2021-07-09 10:05 ` [PATCH v5 06/13] KVM: x86/vmx: Save/Restore host MSR_ARCH_LBR_CTL state Yang Weijiang
2021-07-09 22:54   ` Jim Mattson
2021-07-09 23:41     ` Jim Mattson
2021-07-12  9:53       ` Yang Weijiang
2021-07-12 10:19         ` Like Xu
2021-07-12 17:20           ` Jim Mattson
2021-07-12 17:45             ` Jim Mattson
2021-07-13  9:49               ` Like Xu
2021-07-13 17:00                 ` Jim Mattson
2021-07-14 13:33                   ` Like Xu
2021-07-14 16:15                     ` Jim Mattson
2021-07-13  9:53             ` Yang Weijiang
2021-07-12  9:50     ` Yang Weijiang
2021-07-12 17:23       ` Jim Mattson
2021-07-13  9:47         ` Yang Weijiang
2021-07-13 10:16           ` Like Xu
2021-07-13 17:12             ` Jim Mattson
2021-07-14 13:55               ` Like Xu
2021-07-09 10:05 ` [PATCH v5 07/13] KVM: x86/pmu: Refactor code to support guest Arch LBR Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 08/13] KVM: x86: Refresh CPUID on writes to MSR_IA32_XSS Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 09/13] KVM: x86: Report XSS as an MSR to be saved if there are supported features Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 10/13] KVM: x86: Refine the matching and clearing logic for supported_xss Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 11/13] KVM: x86: Add XSAVE Support for Architectural LBR Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 12/13] KVM: x86/vmx: Check Arch LBR config when return perf capabilities Yang Weijiang
2021-07-09 10:05 ` [PATCH v5 13/13] KVM: x86/cpuid: Advise Arch LBR feature in CPUID Yang Weijiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bd386ed1-69d8-39ab-8bee-6e3aed8d2ee2@gmail.com \
    --to=like.xu.linux@gmail.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=like.xu@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=vkuznets@redhat.com \
    --cc=wei.w.wang@intel.com \
    --cc=weijiang.yang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.