[PATCH V7 6/6] arm64/perf: Enable branch stack events via FEAT_BRBE
Mark Rutland
mark.rutland at arm.com
Wed Feb 8 12:03:18 PST 2023
On Thu, Jan 19, 2023 at 08:18:47AM +0530, Anshuman Khandual wrote:
> On 1/12/23 22:21, Mark Rutland wrote:
> > On Thu, Jan 05, 2023 at 08:40:39AM +0530, Anshuman Khandual wrote:
> >> +bool armv8pmu_branch_valid(struct perf_event *event)
> >> +{
> >> + u64 branch_type = event->attr.branch_sample_type;
> >> +
> >> + /*
> >> + * If the event does not have at least one of the privilege
> >> + * branch filters as in PERF_SAMPLE_BRANCH_PLM_ALL, the core
> >> + * perf will adjust its value based on perf event's existing
> >> + * privilege level via attr.exclude_[user|kernel|hv].
> >> + *
> >> + * As event->attr.branch_sample_type might have been changed
> >> + * when the event reaches here, it is not possible to figure
> >> + * out whether the event originally had HV privilege request
> >> + * or got added via the core perf. Just report this situation
> >> + * once and continue ignoring if there are other instances.
> >> + */
> >> + if ((branch_type & PERF_SAMPLE_BRANCH_HV) && !is_kernel_in_hyp_mode())
> >> + pr_warn_once("%s - hypervisor privilege\n", branch_filter_error_msg);
> >> +
> >> + if (branch_type & PERF_SAMPLE_BRANCH_ABORT_TX) {
> >> + pr_warn_once("%s - aborted transaction\n", branch_filter_error_msg);
> >> + return false;
> >> + }
> >> +
> >> + if (branch_type & PERF_SAMPLE_BRANCH_NO_TX) {
> >> + pr_warn_once("%s - no transaction\n", branch_filter_error_msg);
> >> + return false;
> >> + }
> >> +
> >> + if (branch_type & PERF_SAMPLE_BRANCH_IN_TX) {
> >> + pr_warn_once("%s - in transaction\n", branch_filter_error_msg);
> >> + return false;
> >> + }
> >> + return true;
> >> +}
> >
> > Is this called when validating user input? If so, NAK to printing anything to a
> > higher leval than debug. If there are constraints the user needs to be aware of
>
> You mean pr_debug() based prints ?
Yes.
> > It would be better to whitelist what we do support rather than blacklisting
> > what we don't.
>
> But with a negative list, user would know what is not supported via these pr_debug()
> based output when enabled ? But I dont have a strong opinion either way.
With a negative list, when new options are added the driver will erroneously
and silently accept them, which is worse.
>
> >
> >> +
> >> +static void branch_records_alloc(struct arm_pmu *armpmu)
> >> +{
> >> + struct pmu_hw_events *events;
> >> + int cpu;
> >> +
> >> + for_each_possible_cpu(cpu) {
> >> + events = per_cpu_ptr(armpmu->hw_events, cpu);
> >> +
> >> + events->branches = kzalloc(sizeof(struct branch_records), GFP_KERNEL);
> >> + WARN_ON(!events->branches);
> >> + }
> >> +}
> >
> > It would be simpler for this to be a percpu allocation.
>
> Could you please be more specific ? alloc_percpu_gfp() cannot be used here
> because 'events->branches' is not a __percpu variable unlike its parent
> 'events' which is derived from armpmu.
You can allocate it per-cpu, then grab each of the cpu's pointers using
per_cpu() and place those into events->branches.
That way you only make one allocation which can fail, which makes the error
path much simpler.
[...]
> >> +static int brbe_attributes_probe(struct arm_pmu *armpmu, u32 brbe)
> >> +{
> >> + struct brbe_hw_attr *brbe_attr = kzalloc(sizeof(struct brbe_hw_attr), GFP_KERNEL);
> >
> > Same comments as for the failure path in branch_records_alloc().
> >
> >> + u64 brbidr = read_sysreg_s(SYS_BRBIDR0_EL1);
> >
> > Which context is this run in? Unless this is affine to a relevant CPU we can't
> > read the sysreg safely, and if we're in a cross-call we cannot allocate memory,
> > so this doesn't look right to me.
>
> Called from smp_call_function_any() context via __armv8pmu_probe_pmu().
Ok; so the read is safe, but the allocation is not.
[...]
> >> + WARN_ON(!brbe_attr);
> >> + armpmu->private = brbe_attr;
> >> +
> >> + brbe_attr->brbe_version = brbe;
> >> + brbe_attr->brbe_format = brbe_fetch_format(brbidr);
> >> + brbe_attr->brbe_cc = brbe_fetch_cc_bits(brbidr);
> >> + brbe_attr->brbe_nr = brbe_fetch_numrec(brbidr);
> >
> > As a minor thing, could we please s/fetch/get/ ? To me, 'fetch' sounds like a
> > memory operation, and elsewhere we use 'get' for this sort of getter function.
>
> Sure, but shall we change fetch as get for entire BRBE implementation (where ever
> there is a determination of field from a register value) or just the above function ?
> Default, will change all places.
I had meant in all cases, so that's perfect, thanks.
[...]
> >> + WARN_ON_ONCE(!(brbcr & BRBCR_EL1_MPRED));
> >
> > Huh? Why does the value of BRBCR matter here?
>
> This is just a code hardening measure here. Before recording branch record
> cycles or its flags, ensure BRBCR_EL1 was configured correctly to produce
> these additional information along with the branch records.
I don't think that's necessary. Where is brbcr written such that this could be
misconfigured?
At the least, this needs a comment as to why we need to check, and what we're
checking for.
[...]
> >> +/*
> >> + * A branch record with BRBINF_EL1.LASTFAILED set, implies that all
> >> + * preceding consecutive branch records, that were in a transaction
> >> + * (i.e their BRBINF_EL1.TX set) have been aborted.
> >> + *
> >> + * Similarly BRBFCR_EL1.LASTFAILED set, indicate that all preceding
> >> + * consecutive branch records upto the last record, which were in a
> >> + * transaction (i.e their BRBINF_EL1.TX set) have been aborted.
> >> + *
> >> + * --------------------------------- -------------------
> >> + * | 00 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX success]
> >> + * --------------------------------- -------------------
> >> + * | 01 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX success]
> >> + * --------------------------------- -------------------
> >> + * | 02 | BRBSRC | BRBTGT | BRBINF | | TX = 0 | LF = 0 |
> >> + * --------------------------------- -------------------
> >> + * | 03 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed]
> >> + * --------------------------------- -------------------
> >> + * | 04 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed]
> >> + * --------------------------------- -------------------
> >> + * | 05 | BRBSRC | BRBTGT | BRBINF | | TX = 0 | LF = 1 |
> >> + * --------------------------------- -------------------
> >> + * | .. | BRBSRC | BRBTGT | BRBINF | | TX = 0 | LF = 0 |
> >> + * --------------------------------- -------------------
> >> + * | 61 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed]
> >> + * --------------------------------- -------------------
> >> + * | 62 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed]
> >> + * --------------------------------- -------------------
> >> + * | 63 | BRBSRC | BRBTGT | BRBINF | | TX = 1 | LF = 0 | [TX failed]
> >> + * --------------------------------- -------------------
> >
> > Are we guaranteed to have a record between two transactions with TX = 0?
>
> With TX = 0 i.e no transaction was active, indicates normal sequence of branches
> creating their own branch records. How can there be a transaction with TX = 0 ?
> Could you please be more specific here ?
Consider a sequence of a successful transaction followed by a cancelled
transation, with not branches between the first transation being commited and
the second transaction starting:
TSTART // TX=1
... // TX=1
TCOMMIT // TX=1
TSTART // TX=1
... // TX=1
<failure>
// TX=0, LF=1
AFAICT, we are not guaranteed to have a record with TX=0 between that
successful TCOMMIT and the subsequent TSTART, and so the LASTFAILED field
doesn't indicate that *all* preceding records with TX set are part of the
failed transaction.
Am I missing something? e.g. does the TCOMMIT get records with TX=0?
> > AFAICT you could have a sequence where a TCOMMIT is immediately followed by a
> > TSTART, and IIUC in that case you could have back-to-back records for distinct
> > transactions all with TX = 1, where the first transaction could be commited,
> > and the second might fail/cancel.
> >
> > ... or do TCOMMIT/TCANCEL/TSTART get handled specially?
>
> I guess these are micro-architectural implementation details which unfortunately
> BRBINF_EL1/BRBCR_EL1 specifications do not capture in detail. But all it says is
> that upon encountering BRBINF_EL1.LASTFAILED or BRBFCR_EL1.LASTFAILED (just for
> the last record) all previous in-transaction branch records (BRBINF_EL1.TX = 1)
> should be considered aborted for branch record reporting purpose.
Ok, so we're throwing away data?
If we're going to do that, it would be good to at least have a comment
explaining why we're forced to do so. Ideally we'd get the architecture
clarified/fixed, since AFAIK no-one has actually built TME yet, and it might be
a simple fix (as above).
[...]
> >> +void armv8pmu_branch_read(struct pmu_hw_events *cpuc, struct perf_event *event)
> >> +{
> >> + struct brbe_hw_attr *brbe_attr = (struct brbe_hw_attr *)cpuc->percpu_pmu->private;
> >> + u64 brbinf, brbfcr, brbcr;
> >> + int idx;
> >> +
> >> + brbcr = read_sysreg_s(SYS_BRBCR_EL1);
> >> + brbfcr = read_sysreg_s(SYS_BRBFCR_EL1);
> >> +
> >> + /* Ensure pause on PMU interrupt is enabled */
> >> + WARN_ON_ONCE(!(brbcr & BRBCR_EL1_FZP));
> >
> > As above, I think this needs commentary in the interrupt handler, since this
> > presumably needs us to keep the IRQ asserted until we're done
> > reading/manipulating records in the IRQ handler.
>
> The base IRQ handler armv8pmu_handle_irq() is in ARMV8 PMU code inside perf_event.c
> which could/should not access BRBE specific details without adding an another new
> abstraction function. But I guess adding a comment should be fine.
I think it's fine to have a comment there saying that we *must not* do
something that woukd break BRBE.
> >> +
> >> + /* Save and clear the privilege */
> >> + write_sysreg_s(brbcr & ~(BRBCR_EL1_E0BRE | BRBCR_EL1_E1BRE), SYS_BRBCR_EL1);
> >
> > Why? Later on we restore this, and AFAICT we don't modify it.
> >
> > If it's paused, why do we care about the privilege?
>
> This disables BRBE completely (not only pause) providing confidence that no
> branch record can come in while the existing records are being processed.
I thought from earlier that it was automatically paused by HW upon raising the
IRQ. Have I misunderstood, and we *must* stop it, or is this a belt-and-braces
additional disable?
Is that not the case, or do we not trust the pause for some reason?
Regardless, the comment should expalin *why* we're doing this (i.e. that this
is about ensuring BRBE does not create new records while we're manipulating
it).
> >> + /* Unpause the buffer */
> >> + write_sysreg_s(brbfcr & ~BRBFCR_EL1_PAUSED, SYS_BRBFCR_EL1);
> >> + isb();
> >> + armv8pmu_branch_reset();
> >> +}
> >
> > Why do we enable it before we reset it?
>
> This is the last opportunity for a clean slate start for BRBE buffer before it is
> back recording the branches. Basically helps in ensuring a clean start.
My point is why do we start if *before* resetting it, rather than restting it
first? Why give it the opportunity to create records that we're going to
discard immediately thereafter?
> > Surely it would make sense to reset it first, and ammortize the cost of the ISB?
> >
> > That said, as above, do we actually need to pause/unpause it? Or is it already
> > paused by virtue of the IRQ?
>
> Yes, it should be paused after an IRQ but it is also enforced before reading along
> with privilege level disable.
I'm very confused as to why we're not trusting the HW to remain paused. Why do
we need to enforce what th e hardware should already be doing?
> Regardless the buffer needs to be un-paused and also
> enabled for required privilege levels before exiting from here.
I agree this needs to be balanced, it just seems to me that we're doing
redundant work here.
Thanks,
Mark.
More information about the linux-arm-kernel
mailing list