From: Peter Zijlstra <peterz@infradead.org>
To: "Xu, Like" <like.xu@intel.com>
Cc: Like Xu <like.xu@linux.intel.com>,
Paolo Bonzini <pbonzini@redhat.com>,
kvm@vger.kernel.org, Andi Kleen <ak@linux.intel.com>,
Jim Mattson <jmattson@google.com>,
Wanpeng Li <wanpengli@tencent.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
Joerg Roedel <joro@8bytes.org>,
Liran Alon <liran.alon@oracle.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Liang Kan <kan.liang@linux.intel.com>,
Wei Wang <wei.w.wang@intel.com>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v9 03/10] perf/x86: Add constraint to create guest LBR event without hw counter
Date: Fri, 17 Apr 2020 12:30:16 +0200 [thread overview]
Message-ID: <20200417103016.GV20730@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <0b89963d-33d8-3b0f-fc56-eff3ccce648d@intel.com>
On Fri, Apr 10, 2020 at 11:03:33AM +0800, Xu, Like wrote:
> On 2020/4/10 0:37, Peter Zijlstra wrote:
> > That should sort the branches in order of: gp,fixed,bts,vlbr
>
> Note the current order is: bts, pebs, fixed, gp.
Yeah, and that means that gp (which is I think the most common case) is
the most expensive.
> Sure, let me try to refactor it in this way.
Thanks!
> > > +static inline bool is_guest_event(struct perf_event *event)
> > > +{
> > > + if (event->attr.exclude_host && is_kernel_event(event))
> > > + return true;
> > > + return false;
> > > +}
> > I don't like this one, what if another in-kernel users generates an
> > event with exclude_host set ?
> Thanks for the clear attitude.
>
> How about:
> - remove the is_guest_event() to avoid potential misuse;
> - move all checks into is_guest_lbr_event() and make it dedicated:
>
> static inline bool is_guest_lbr_event(struct perf_event *event)
> {
> if (is_kernel_event(event) &&
> event->attr.exclude_host && needs_branch_stack(event))
> return true;
> return false;
> }
>
> In this case, it's safe to generate an event with exclude_host set
> and also use LBR to count guest or nothing for other in-kernel users
> because the intel_guest_lbr_event_constraints() makes LBR exclusive.
>
> For this generic usage, I may rename:
> - is_guest_lbr_event() to is_lbr_no_counter_event();
> - intel_guest_lbr_event_constraints() to
> intel_lbr_no_counter_event_constraints();
>
> Is this acceptable to you?
I suppose so, please put a comment on top of that function though, so we
don't forget.
> > > @@ -181,9 +181,19 @@ struct x86_pmu_capability {
> > > #define GLOBAL_STATUS_UNC_OVF BIT_ULL(61)
> > > #define GLOBAL_STATUS_ASIF BIT_ULL(60)
> > > #define GLOBAL_STATUS_COUNTERS_FROZEN BIT_ULL(59)
> > > -#define GLOBAL_STATUS_LBRS_FROZEN BIT_ULL(58)
> > > +#define GLOBAL_STATUS_LBRS_FROZEN_BIT 58
> > > +#define GLOBAL_STATUS_LBRS_FROZEN BIT_ULL(GLOBAL_STATUS_LBRS_FROZEN_BIT)
> > > #define GLOBAL_STATUS_TRACE_TOPAPMI BIT_ULL(55)
> > > +/*
> > > + * We model guest LBR event tracing as another fixed-mode PMC like BTS.
> > > + *
> > > + * We choose bit 58 (LBRS_FROZEN_BIT) which is used to indicate that the LBR
> > > + * stack is frozen on a hardware PMI request in the PERF_GLOBAL_STATUS msr,
> > > + * and the 59th PMC counter (if any) is not supposed to use it as well.
> > Is this saying that STATUS.58 should never be set? I don't really
> > understand the language.
> My fault, and let me make it more clearly:
>
> We choose bit 58 because it's used to indicate LBR stack frozen state
> not like other overflow conditions in the PERF_GLOBAL_STATUS msr,
> and it will not be used for any actual fixed events.
That's only with v4, also we unconditionally mask that bit in
handle_pmi_common(), so it'll never be set in the overflow handling.
That's all fine, I suppose, all you want is means of programming the LBR
registers, we don't actually do anything with then in the host context.
Please write a more elaborate comment here.
next prev parent reply other threads:[~2020-04-17 10:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-13 2:16 [PATCH v9 00/10] Guest Last Branch Recording Enabling Like Xu
2020-03-13 2:16 ` [PATCH v9 01/10] perf/x86: Fix msr variable type for the LBR msrs Like Xu
2020-03-13 2:16 ` [PATCH v9 02/10] perf/x86/lbr: Add interface to get basic information about LBR stack Like Xu
2020-03-13 2:16 ` [PATCH v9 03/10] perf/x86: Add constraint to create guest LBR event without hw counter Like Xu
2020-04-09 16:37 ` Peter Zijlstra
2020-04-10 3:03 ` Xu, Like
2020-04-17 8:40 ` Xu, Like
2020-04-17 10:30 ` Peter Zijlstra [this message]
2020-03-13 2:16 ` [PATCH v9 04/10] perf/x86: Keep LBR stack unchanged on the host for guest LBR event Like Xu
2020-04-09 16:45 ` Peter Zijlstra
2020-04-10 3:10 ` Xu, Like
2020-03-13 2:16 ` [PATCH v9 05/10] KVM: x86: Add KVM_CAP_X86_GUEST_LBR interface to dis/enable LBR feature Like Xu
2020-03-13 2:16 ` [PATCH v9 06/10] KVM: x86/pmu: Tweak kvm_pmu_get_msr to pass 'struct msr_data' in Like Xu
2020-03-13 2:16 ` [PATCH v9 07/10] KVM: x86/pmu: Add LBR feature emulation via guest LBR event Like Xu
2020-03-13 2:16 ` [PATCH v9 08/10] KVM: x86/pmu: Release guest LBR event via vPMU lazy release mechanism Like Xu
2020-03-13 2:16 ` [PATCH v9 09/10] KVM: x86: Expose MSR_IA32_PERF_CAPABILITIES to guest for LBR record format Like Xu
2020-03-13 2:16 ` [PATCH v9 10/10] KVM: x86: Remove the common trap handler of the MSR_IA32_DEBUGCTLMSR Like Xu
2020-03-20 8:45 ` [PATCH v9 00/10] Guest Last Branch Recording Enabling Xu, Like
2020-04-02 12:59 ` Xu, Like
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=20200417103016.GV20730@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=acme@kernel.org \
--cc=ak@linux.intel.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kan.liang@linux.intel.com \
--cc=kvm@vger.kernel.org \
--cc=like.xu@intel.com \
--cc=like.xu@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=liran.alon@oracle.com \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=wanpengli@tencent.com \
--cc=wei.w.wang@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.