From: Anshuman Khandual <anshuman.khandual@arm.com>
To: linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, peterz@infradead.org,
acme@kernel.org, mark.rutland@arm.com, will@kernel.org,
catalin.marinas@arm.com
Cc: Anshuman Khandual <anshuman.khandual@arm.com>,
James Clark <james.clark@arm.com>, Rob Herring <robh@kernel.org>,
Marc Zyngier <maz@kernel.org>, Ingo Molnar <mingo@redhat.com>
Subject: [PATCH V2 5/7] arm64/perf: Drive BRBE from perf event states
Date: Thu, 8 Sep 2022 10:40:44 +0530 [thread overview]
Message-ID: <20220908051046.465307-6-anshuman.khandual@arm.com> (raw)
In-Reply-To: <20220908051046.465307-1-anshuman.khandual@arm.com>
Branch stack sampling rides along the normal perf event and all the branch
records get captured during the PMU interrupt. This just changes perf event
handling on the arm64 platform to accommodate required BRBE operations that
will enable branch stack sampling support.
It adds a new 'hw_perf_event.flags' element i.e ARMPMU_EVT_PRIV, which will
enable caching perf event privilege information required for capturing some
branch record types.
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: linux-perf-users@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com>
---
arch/arm64/kernel/perf_event.c | 6 ++++
drivers/perf/arm_pmu.c | 50 ++++++++++++++++++++++++++++++++++
include/linux/perf/arm_pmu.h | 4 +++
3 files changed, 60 insertions(+)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index e7013699171f..5bfaba8edad1 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -874,6 +874,12 @@ static irqreturn_t armv8pmu_handle_irq(struct arm_pmu *cpu_pmu)
if (!armpmu_event_set_period(event))
continue;
+ if (has_branch_stack(event)) {
+ cpu_pmu->brbe_read(cpuc, event);
+ data.br_stack = &cpuc->brbe_stack;
+ cpu_pmu->brbe_reset(cpuc);
+ }
+
/*
* Perf event overflow will queue the processing of the event as
* an irq_work which will be taken care of in the handling of
diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c
index 59d3980b8ca2..1fe5d6238b81 100644
--- a/drivers/perf/arm_pmu.c
+++ b/drivers/perf/arm_pmu.c
@@ -271,12 +271,22 @@ armpmu_stop(struct perf_event *event, int flags)
{
struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
+ struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
/*
* ARM pmu always has to update the counter, so ignore
* PERF_EF_UPDATE, see comments in armpmu_start().
*/
if (!(hwc->state & PERF_HES_STOPPED)) {
+ if (has_branch_stack(event)) {
+ WARN_ON_ONCE(!hw_events->brbe_users);
+ hw_events->brbe_users--;
+ if (!hw_events->brbe_users) {
+ hw_events->brbe_context = NULL;
+ armpmu->brbe_disable(hw_events);
+ }
+ }
+
armpmu->disable(event);
armpmu_event_update(event);
hwc->state |= PERF_HES_STOPPED | PERF_HES_UPTODATE;
@@ -287,6 +297,7 @@ static void armpmu_start(struct perf_event *event, int flags)
{
struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
+ struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
/*
* ARM pmu always has to reprogram the period, so ignore
@@ -304,6 +315,14 @@ static void armpmu_start(struct perf_event *event, int flags)
* happened since disabling.
*/
armpmu_event_set_period(event);
+ if (has_branch_stack(event)) {
+ if (event->ctx->task && hw_events->brbe_context != event->ctx) {
+ armpmu->brbe_reset(hw_events);
+ hw_events->brbe_context = event->ctx;
+ }
+ armpmu->brbe_enable(hw_events);
+ hw_events->brbe_users++;
+ }
armpmu->enable(event);
}
@@ -349,6 +368,10 @@ armpmu_add(struct perf_event *event, int flags)
hw_events->events[idx] = event;
hwc->state = PERF_HES_STOPPED | PERF_HES_UPTODATE;
+
+ if (has_branch_stack(event))
+ armpmu->brbe_filter(hw_events, event);
+
if (flags & PERF_EF_START)
armpmu_start(event, PERF_EF_RELOAD);
@@ -443,6 +466,7 @@ __hw_perf_event_init(struct perf_event *event)
{
struct arm_pmu *armpmu = to_arm_pmu(event->pmu);
struct hw_perf_event *hwc = &event->hw;
+ struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
int mapping;
hwc->flags = 0;
@@ -492,6 +516,19 @@ __hw_perf_event_init(struct perf_event *event)
local64_set(&hwc->period_left, hwc->sample_period);
}
+ if (has_branch_stack(event)) {
+ /*
+ * Cache whether the perf event is allowed to capture exception
+ * and exception return branch records. It allows us to perform
+ * the privilege check via perfmon_capable(), in the context of
+ * the event owner, just once, during the pmu->event_init().
+ */
+ if (perfmon_capable())
+ event->hw.flags |= ARMPMU_EVT_PRIV;
+
+ armpmu->brbe_filter(hw_events, event);
+ }
+
return validate_group(event);
}
@@ -520,6 +557,18 @@ static int armpmu_event_init(struct perf_event *event)
return __hw_perf_event_init(event);
}
+static void armpmu_sched_task(struct perf_event_context *ctx, bool sched_in)
+{
+ struct arm_pmu *armpmu = to_arm_pmu(ctx->pmu);
+ struct pmu_hw_events *hw_events = this_cpu_ptr(armpmu->hw_events);
+
+ if (!hw_events->brbe_users)
+ return;
+
+ if (sched_in)
+ armpmu->brbe_reset(hw_events);
+}
+
static void armpmu_enable(struct pmu *pmu)
{
struct arm_pmu *armpmu = to_arm_pmu(pmu);
@@ -877,6 +926,7 @@ static struct arm_pmu *__armpmu_alloc(gfp_t flags)
}
pmu->pmu = (struct pmu) {
+ .sched_task = armpmu_sched_task,
.pmu_enable = armpmu_enable,
.pmu_disable = armpmu_disable,
.event_init = armpmu_event_init,
diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h
index 18e519e4e658..67f44020a736 100644
--- a/include/linux/perf/arm_pmu.h
+++ b/include/linux/perf/arm_pmu.h
@@ -29,6 +29,10 @@
/* Event uses a 47bit counter */
#define ARMPMU_EVT_47BIT 2
+#define ARMPMU_EVT_PRIV 0x00004 /* Event is privileged */
+
+static_assert((PERF_EVENT_FLAG_ARCH & ARMPMU_EVT_PRIV) == ARMPMU_EVT_PRIV);
+
#define HW_OP_UNSUPPORTED 0xFFFF
#define C(_x) PERF_COUNT_HW_CACHE_##_x
#define CACHE_OP_UNSUPPORTED 0xFFFF
--
2.25.1
next prev parent reply other threads:[~2022-09-08 5:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 5:10 [PATCH V2 0/7] arm64/perf: Enable branch stack sampling Anshuman Khandual
2022-09-08 5:10 ` [PATCH V2 1/7] arm64/perf: Add register definitions for BRBE Anshuman Khandual
2022-09-12 9:57 ` Mark Brown
2022-09-13 6:24 ` Anshuman Khandual
2022-09-13 11:30 ` Mark Brown
2022-09-08 5:10 ` [PATCH V2 2/7] arm64/perf: Update struct arm_pmu " Anshuman Khandual
2022-09-08 5:10 ` [PATCH V2 3/7] arm64/perf: Update struct pmu_hw_events " Anshuman Khandual
[not found] ` <202209082022.6BPdyQn8-lkp@intel.com>
2022-09-09 3:11 ` Anshuman Khandual
[not found] ` <202209082259.XDCTMY9g-lkp@intel.com>
2022-09-09 3:14 ` Anshuman Khandual
2022-09-12 10:12 ` Mark Brown
2022-09-13 5:33 ` Anshuman Khandual
2022-09-13 11:43 ` Mark Brown
2022-09-14 3:39 ` Anshuman Khandual
2022-09-14 9:35 ` Mark Brown
2022-09-08 5:10 ` [PATCH V2 4/7] driver/perf/arm_pmu_platform: Add support for BRBE attributes detection Anshuman Khandual
2022-09-08 5:10 ` Anshuman Khandual [this message]
2022-09-08 15:31 ` [PATCH V2 5/7] arm64/perf: Drive BRBE from perf event states kernel test robot
2022-09-08 5:10 ` [PATCH V2 6/7] arm64/perf: Add BRBE driver Anshuman Khandual
2022-09-08 9:23 ` kernel test robot
2022-09-08 10:16 ` Anshuman Khandual
2022-09-13 10:39 ` James Clark
2022-09-13 11:38 ` Anshuman Khandual
2022-09-08 5:10 ` [PATCH V2 7/7] arm64/perf: Enable branch stack sampling Anshuman Khandual
2022-09-13 10:55 ` [PATCH V2 0/7] " James Clark
2022-09-13 12:12 ` Anshuman Khandual
2022-09-13 13:12 ` James Clark
2022-09-14 4:43 ` Anshuman Khandual
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=20220908051046.465307-6-anshuman.khandual@arm.com \
--to=anshuman.khandual@arm.com \
--cc=acme@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.clark@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=maz@kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=robh@kernel.org \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).