From: Sandipan Das <sandipan.das@amd.com>
To: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>,
Atish Patra <atish.patra@linux.dev>,
Anup Patel <anup@brainfault.org>, Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 3/3] perf/riscv: Use Sspesa for precise sample attribution
Date: Thu, 20 Aug 2026 15:50:45 +0530 [thread overview]
Message-ID: <c30e91d3-514a-4fef-8b61-e1744f577d35@amd.com> (raw)
In-Reply-To: <20260817160222.3313295-4-mayuresh.chitale@oss.qualcomm.com>
On 17-08-2026 21:32, Mayuresh Chitale wrote:
> When the Sspesa (Precise Event Sample Attribution) extension is
> available and a counter overflows, the hardware records a sample PC in
> shpmspc register and the counter ID and additional implementation-defined
> data in shpmsdata register.
>
> In the SBI PMU overflow handler, use shpmspc to report sample PC via
> PERF_SAMPLE_IP for the counter that caused the overflow. Shpmsdata is
> exported as raw data to userspace when events request PERF_SAMPLE_RAW
> sample type and it assists in deriving the sample PC from shpmspc if
> precise attribution is not supported for the event.
>
> If sspesa is not available or for counters that don't match
> shpmsdata.CNTRID, fallback to epc for PERF_SAMPLE_IP.
>
> Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
> ---
> drivers/perf/riscv_pmu_sbi.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
> index dfc886dee5ad..1b0b1cc612de 100644
> --- a/drivers/perf/riscv_pmu_sbi.c
> +++ b/drivers/perf/riscv_pmu_sbi.c
> @@ -63,6 +63,8 @@ PMU_FORMAT_ATTR(firmware, "config:62-63");
>
> static bool sbi_v2_available;
> static bool sbi_v3_available;
> +static bool sspesa_available;
> +
> static DEFINE_STATIC_KEY_FALSE(sbi_pmu_snapshot_available);
> #define sbi_pmu_snapshot_available() \
> static_branch_unlikely(&sbi_pmu_snapshot_available)
> @@ -1051,6 +1053,11 @@ static irqreturn_t pmu_sbi_ovf_handler(int irq, void *dev)
> struct cpu_hw_events *cpu_hw_evt = dev;
> u64 start_clock = sched_clock();
> struct riscv_pmu_snapshot_data *sdata = cpu_hw_evt->snapshot_addr;
> + unsigned long sample_pc = 0;
> + unsigned long sample_data = 0;
> + int sample_cntrid = -1;
> + u64 raw_sample;
> + struct perf_raw_record raw = { 0 };
>
> if (WARN_ON_ONCE(!cpu_hw_evt))
> return IRQ_NONE;
> @@ -1088,6 +1095,16 @@ static irqreturn_t pmu_sbi_ovf_handler(int irq, void *dev)
> return IRQ_NONE;
>
> regs = get_irq_regs();
> + /*
> + * Sspesa records the PC and metadata of the overflowing counter in
> + * hardware. The PC is precise only for events that support precise
> + * attribution; otherwise it is best-effort.
> + */
> + if (sspesa_available) {
> + sample_pc = csr_read(CSR_SHPMSPC);
> + sample_data = csr_read(CSR_SHPMSDATA);
> + sample_cntrid = sample_data & SHPMSDATA_CNTRID;
> + }
>
> for_each_set_bit(lidx, cpu_hw_evt->used_hw_ctrs, RISCV_MAX_COUNTERS) {
> struct perf_event *event = cpu_hw_evt->events[lidx];
> @@ -1123,6 +1140,15 @@ static irqreturn_t pmu_sbi_ovf_handler(int irq, void *dev)
> riscv_pmu_event_update(event);
> hw_evt->state |= PERF_HES_UPTODATE;
> perf_sample_data_init(&data, 0, hw_evt->last_period);
> + if (sspesa_available && hidx == sample_cntrid) {
> + data.ip = sample_pc;
Does this need to be tied to event->attr.precise_ip?
> + data.sample_flags |= PERF_SAMPLE_IP;
> +
> + raw_sample = sample_data;
> + raw.frag.size = sizeof(raw_sample);
> + raw.frag.data = &raw_sample;
> + perf_sample_save_raw_data(&data, event, &raw);
> + }
> if (riscv_pmu_event_set_period(event)) {
> /*
> * Unlike other ISAs, RISC-V don't have to disable interrupts
> @@ -1194,6 +1220,9 @@ static int pmu_sbi_setup_irqs(struct riscv_pmu *pmu, struct platform_device *pde
> struct cpu_hw_events __percpu *hw_events = pmu->hw_events;
> struct irq_domain *domain = NULL;
>
> + if (riscv_isa_extension_available(NULL, SSPESA))
> + sspesa_available = true;
> +
> if (riscv_isa_extension_available(NULL, SSCOFPMF)) {
> riscv_pmu_irq_num = RV_IRQ_PMU;
> riscv_pmu_use_irq = true;
WARNING: multiple messages have this Message-ID (diff)
From: Sandipan Das <sandipan.das@amd.com>
To: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>,
Atish Patra <atish.patra@linux.dev>,
Anup Patel <anup@brainfault.org>, Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Paul Walmsley <pjw@kernel.org>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-riscv@lists.infradead.org,
linux-arm-kernel@lists.infradead.org,
linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 3/3] perf/riscv: Use Sspesa for precise sample attribution
Date: Thu, 20 Aug 2026 15:50:45 +0530 [thread overview]
Message-ID: <c30e91d3-514a-4fef-8b61-e1744f577d35@amd.com> (raw)
In-Reply-To: <20260817160222.3313295-4-mayuresh.chitale@oss.qualcomm.com>
On 17-08-2026 21:32, Mayuresh Chitale wrote:
> When the Sspesa (Precise Event Sample Attribution) extension is
> available and a counter overflows, the hardware records a sample PC in
> shpmspc register and the counter ID and additional implementation-defined
> data in shpmsdata register.
>
> In the SBI PMU overflow handler, use shpmspc to report sample PC via
> PERF_SAMPLE_IP for the counter that caused the overflow. Shpmsdata is
> exported as raw data to userspace when events request PERF_SAMPLE_RAW
> sample type and it assists in deriving the sample PC from shpmspc if
> precise attribution is not supported for the event.
>
> If sspesa is not available or for counters that don't match
> shpmsdata.CNTRID, fallback to epc for PERF_SAMPLE_IP.
>
> Signed-off-by: Mayuresh Chitale <mayuresh.chitale@oss.qualcomm.com>
> ---
> drivers/perf/riscv_pmu_sbi.c | 29 +++++++++++++++++++++++++++++
> 1 file changed, 29 insertions(+)
>
> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
> index dfc886dee5ad..1b0b1cc612de 100644
> --- a/drivers/perf/riscv_pmu_sbi.c
> +++ b/drivers/perf/riscv_pmu_sbi.c
> @@ -63,6 +63,8 @@ PMU_FORMAT_ATTR(firmware, "config:62-63");
>
> static bool sbi_v2_available;
> static bool sbi_v3_available;
> +static bool sspesa_available;
> +
> static DEFINE_STATIC_KEY_FALSE(sbi_pmu_snapshot_available);
> #define sbi_pmu_snapshot_available() \
> static_branch_unlikely(&sbi_pmu_snapshot_available)
> @@ -1051,6 +1053,11 @@ static irqreturn_t pmu_sbi_ovf_handler(int irq, void *dev)
> struct cpu_hw_events *cpu_hw_evt = dev;
> u64 start_clock = sched_clock();
> struct riscv_pmu_snapshot_data *sdata = cpu_hw_evt->snapshot_addr;
> + unsigned long sample_pc = 0;
> + unsigned long sample_data = 0;
> + int sample_cntrid = -1;
> + u64 raw_sample;
> + struct perf_raw_record raw = { 0 };
>
> if (WARN_ON_ONCE(!cpu_hw_evt))
> return IRQ_NONE;
> @@ -1088,6 +1095,16 @@ static irqreturn_t pmu_sbi_ovf_handler(int irq, void *dev)
> return IRQ_NONE;
>
> regs = get_irq_regs();
> + /*
> + * Sspesa records the PC and metadata of the overflowing counter in
> + * hardware. The PC is precise only for events that support precise
> + * attribution; otherwise it is best-effort.
> + */
> + if (sspesa_available) {
> + sample_pc = csr_read(CSR_SHPMSPC);
> + sample_data = csr_read(CSR_SHPMSDATA);
> + sample_cntrid = sample_data & SHPMSDATA_CNTRID;
> + }
>
> for_each_set_bit(lidx, cpu_hw_evt->used_hw_ctrs, RISCV_MAX_COUNTERS) {
> struct perf_event *event = cpu_hw_evt->events[lidx];
> @@ -1123,6 +1140,15 @@ static irqreturn_t pmu_sbi_ovf_handler(int irq, void *dev)
> riscv_pmu_event_update(event);
> hw_evt->state |= PERF_HES_UPTODATE;
> perf_sample_data_init(&data, 0, hw_evt->last_period);
> + if (sspesa_available && hidx == sample_cntrid) {
> + data.ip = sample_pc;
Does this need to be tied to event->attr.precise_ip?
> + data.sample_flags |= PERF_SAMPLE_IP;
> +
> + raw_sample = sample_data;
> + raw.frag.size = sizeof(raw_sample);
> + raw.frag.data = &raw_sample;
> + perf_sample_save_raw_data(&data, event, &raw);
> + }
> if (riscv_pmu_event_set_period(event)) {
> /*
> * Unlike other ISAs, RISC-V don't have to disable interrupts
> @@ -1194,6 +1220,9 @@ static int pmu_sbi_setup_irqs(struct riscv_pmu *pmu, struct platform_device *pde
> struct cpu_hw_events __percpu *hw_events = pmu->hw_events;
> struct irq_domain *domain = NULL;
>
> + if (riscv_isa_extension_available(NULL, SSPESA))
> + sspesa_available = true;
> +
> if (riscv_isa_extension_available(NULL, SSCOFPMF)) {
> riscv_pmu_irq_num = RV_IRQ_PMU;
> riscv_pmu_use_irq = true;
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2026-08-20 10:21 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-17 16:02 [RFC PATCH 0/3] RISC-V Sspesa: Linux perf precise sample attribution Mayuresh Chitale
2026-08-17 16:02 ` Mayuresh Chitale
2026-08-17 16:02 ` [RFC PATCH 1/3] dt-bindings: riscv: Add Sspesa and Ssplcofi extensions Mayuresh Chitale
2026-08-17 16:02 ` Mayuresh Chitale
2026-08-17 16:09 ` sashiko-bot
2026-08-18 9:35 ` Conor Dooley
2026-08-18 9:35 ` Conor Dooley
2026-08-17 16:02 ` [RFC PATCH 2/3] riscv: Add detection for " Mayuresh Chitale
2026-08-17 16:02 ` Mayuresh Chitale
2026-08-17 16:02 ` [RFC PATCH 3/3] perf/riscv: Use Sspesa for precise sample attribution Mayuresh Chitale
2026-08-17 16:02 ` Mayuresh Chitale
2026-08-17 16:17 ` sashiko-bot
2026-08-20 10:20 ` Sandipan Das [this message]
2026-08-20 10:20 ` Sandipan Das
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=c30e91d3-514a-4fef-8b61-e1744f577d35@amd.com \
--to=sandipan.das@amd.com \
--cc=alex@ghiti.fr \
--cc=anup@brainfault.org \
--cc=aou@eecs.berkeley.edu \
--cc=atish.patra@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=mayuresh.chitale@oss.qualcomm.com \
--cc=palmer@dabbelt.com \
--cc=pjw@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 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.