From: sashiko-bot@kernel.org
To: "Atish Patra" <atish.patra@linux.dev>
Cc: conor+dt@kernel.org, linux-perf-users@vger.kernel.org,
robh@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v9 16/20] RISC-V: perf: Use config2/vendor table for event to counter mapping
Date: Fri, 07 Aug 2026 08:43:41 +0000 [thread overview]
Message-ID: <20260807084342.4DABF1F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807-counter_delegation-v9-16-58658104e487@meta.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Standard host legacy hardware events (e.g., 'perf stat -e cycles') fail to open and cannot map to fixed counters via the vendor driver table.
- [High] Raw events with broad counter masks are unconditionally forced to count cycles or instructions on fixed counters, returning incorrect metrics.
--
--- Patch [16]: [PATCH v9 16/20] RISC-V: perf: Use config2/vendor table for event to counter mapping ---
commit 450780026222524d85a7b60f40dbdc3d52fed837
Author: Atish Patra <atishp@rivosinc.com>
Subject: RISC-V: perf: Use config2/vendor table for event to counter mapping
This patch allows platform vendors to specify custom mapping between
events and hpmcounters using the config2 parameter in perf attributes.
Legacy events are mapped via the vendor event table in the driver, while
the fixed cycle and instruction counters map to legacy events.
> diff --git a/drivers/perf/riscv_pmu_sbi.c b/drivers/perf/riscv_pmu_sbi.c
> index f0b8b6eff2ea7..ee0c077859273 100644
> --- a/drivers/perf/riscv_pmu_sbi.c
> +++ b/drivers/perf/riscv_pmu_sbi.c
[ ... ]
> @@ -1522,24 +1524,85 @@ static int rvpmu_deleg_find_ctrs(void)
> static int get_deleg_fixed_hw_idx(struct cpu_hw_events *cpuc, struct perf_event *event)
> {
> - return -EINVAL;
> + bool guest_events = event->attr.config1 & RISCV_PMU_CONFIG1_GUEST_EVENTS;
> + int idx;
> +
> + /* event_base is 0 on the delegation path; match via the original perf attrs. */
> + if (guest_events) {
> + if (event->attr.type != PERF_TYPE_HARDWARE)
> + return -EINVAL;
> + if (event->attr.config == PERF_COUNT_HW_CPU_CYCLES)
> + idx = 0; /* CY counter */
> + else if (event->attr.config == PERF_COUNT_HW_INSTRUCTIONS)
> + idx = 2; /* IR counter */
> + else
> + return -EINVAL;
> + } else if (event->attr.config2 & RISCV_PMU_CYCLE_FIXED_CTR_MASK) {
> + idx = 0; /* CY counter */
[Severity: High]
Does this unconditionally force raw events with broad counter masks to count
cycles instead of the requested metric?
If a raw event is provided with a broad counterid_mask (e.g., 0xFFFFFFFF)
that allows any counter, config2 will have bit 0 set. This causes
get_deleg_fixed_hw_idx() to immediately assign it to fixed counter 0.
Since fixed counter 0 is architecturally hardwired to count cycles, the
actual raw event ID is ignored and the PMU returns cycle counts, leading to
incorrect metrics.
> + } else if (event->attr.config2 & RISCV_PMU_INSTRUCTION_FIXED_CTR_MASK) {
> + idx = 2; /* IR counter */
> + } else {
> + return -EINVAL;
> + }
> +
> + /* Take the fixed counter only if delegated and free, else fall back. */
> + if (!(cmask & BIT(idx)) || test_bit(idx, cpuc->used_hw_ctrs))
> + return -EINVAL;
> +
> + return idx;
> }
>
> static int get_deleg_next_hpm_hw_idx(struct cpu_hw_events *cpuc, struct perf_event *event)
> {
> - unsigned long hw_ctr_mask = 0;
> + u32 hw_ctr_mask = 0, temp_mask = 0;
> + u32 type = event->attr.type;
> + u64 config = event->attr.config;
> + int ret;
>
> - /*
> - * TODO: Treat every hpmcounter can monitor every event for now.
> - * The event to counter mapping should come from the json file.
> - * The mapping should also tell if sampling is supported or not.
> - */
> + /* Select only available hpmcounters */
> + hw_ctr_mask = cmask & (~0x7) & ~(cpuc->used_hw_ctrs[0]);
[Severity: High]
Will standard host legacy hardware events fail to map to fixed counters if
the vendor map mandates them?
When a user runs a command like "perf stat -e cycles", config2 is 0.
As a result, get_deleg_fixed_hw_idx() ignores current_pmu_hw_event_map and
returns -EINVAL without finding a fixed counter mapping.
This fallback function then explicitly strips out fixed counter bits (~0x7),
which prevents assigning fixed counters even if the vendor table specifically
requests them. If the vendor map requires counter 0 via counterid_mask, the
resulting hw_ctr_mask becomes 0, and the allocation fails entirely with
-ENOENT.
> +
> + switch (type) {
> + case PERF_TYPE_HARDWARE:
> + temp_mask = current_pmu_hw_event_map[config].counterid_mask;
> + break;
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260807-counter_delegation-v9-0-58658104e487@meta.com?part=16
next prev parent reply other threads:[~2026-08-07 8:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 8:08 [PATCH v9 00/20] Add Counter delegation ISA extension support Atish Patra
2026-08-07 8:08 ` [PATCH v9 01/20] RISC-V: perf: fix resource cleanup on driver probe failure Atish Patra
2026-08-07 8:30 ` sashiko-bot
2026-08-07 8:08 ` [PATCH v9 02/20] RISC-V: Add Smcsrind and Sscsrind ISA extension CSR definitions Atish Patra
2026-08-07 8:08 ` [PATCH v9 03/20] RISC-V: Add Smcsrind and Sscsrind ISA extension definition and parsing Atish Patra
2026-08-07 8:08 ` [PATCH v9 04/20] dt-bindings: riscv: add Smcsrind and Sscsrind ISA extension descriptions Atish Patra
2026-08-07 8:09 ` [PATCH v9 05/20] RISC-V: Define indirect CSR access helpers Atish Patra
2026-08-07 8:27 ` sashiko-bot
2026-08-07 8:09 ` [PATCH v9 06/20] RISC-V: Add Smcntrpmf extension parsing Atish Patra
2026-08-07 8:09 ` [PATCH v9 07/20] dt-bindings: riscv: add Smcntrpmf ISA extension description Atish Patra
2026-08-07 8:09 ` [PATCH v9 08/20] RISC-V: Add Ssccfg extension CSR definition Atish Patra
2026-08-07 8:09 ` [PATCH v9 09/20] RISC-V: Add Ssccfg/Smcdeleg ISA extension definition and parsing Atish Patra
2026-08-07 8:25 ` sashiko-bot
2026-08-07 8:09 ` [PATCH v9 10/20] dt-bindings: riscv: add Counter delegation ISA extensions description Atish Patra
2026-08-07 8:09 ` [PATCH v9 11/20] RISC-V: perf: Restructure the SBI PMU code Atish Patra
2026-08-07 8:09 ` [PATCH v9 12/20] RISC-V: perf: Modify the counter discovery mechanism Atish Patra
2026-08-07 8:29 ` sashiko-bot
2026-08-07 8:09 ` [PATCH v9 13/20] RISC-V: perf: Add a mechanism to defined legacy event encoding Atish Patra
2026-08-07 8:09 ` [PATCH v9 14/20] RISC-V: perf: Implement supervisor counter delegation support Atish Patra
2026-08-07 8:34 ` sashiko-bot
2026-08-07 8:09 ` [PATCH v9 15/20] RISC-V: perf: Skip PMU SBI extension when not implemented Atish Patra
2026-08-07 8:09 ` [PATCH v9 16/20] RISC-V: perf: Use config2/vendor table for event to counter mapping Atish Patra
2026-08-07 8:43 ` sashiko-bot [this message]
2026-08-07 8:09 ` [PATCH v9 17/20] RISC-V: perf: Add legacy event encodings via sysfs Atish Patra
2026-08-07 8:40 ` sashiko-bot
2026-08-07 8:09 ` [PATCH v9 18/20] RISC-V: perf: Add Qemu virt machine events Atish Patra
2026-08-07 8:41 ` sashiko-bot
2026-08-07 8:09 ` [PATCH v9 19/20] tools/perf: Support event code for arch standard events Atish Patra
2026-08-07 8:09 ` [PATCH v9 20/20] tools/perf: Add RISC-V CounterIDMask event field Atish Patra
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=20260807084342.4DABF1F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=atish.patra@linux.dev \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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