[PATCH v3 01/14] drivers/perf: arm_spe: Expose event filter
Leo Yan
leo.yan at arm.com
Mon Jul 14 08:42:51 PDT 2025
On Mon, Jul 14, 2025 at 04:13:49PM +0100, Will Deacon wrote:
[...]
> > > In other words, remove arm_spe_pmsevfr_res0() and the two checks that
> > > use it in arm_spe_pmu_event_init(). If userspace tries to filter events
> > > that aren't implemented, then it gets to keep the pieces.
> >
> > Then the question is: what information should be exposed to userspace
> > so that tools can decide which events are valid?
> >
> > I would suggest to expose a new entry, "caps/version", to indicate the
> > SPE version number. Tools can use this to apply the appropriate event
> > validation. Please let me know if this works for you.
>
> I thought userspace typically had midr-based json files to figure this
> stuff out?
Yes, the perf tool records the CPU MIDR in the metadata.
However, I deliberately tried to avoid relying on this approach,
because the perf would then need to maintain a mapping between:
MIDR -> Arm SPE version -> Events
Given the large number of CPU variants, maintaining this relationship
between CPU ID and SPE version, and subsequently mapping it to supported
events, would be quite complex. Additional effort would be required each
time a new CPU variant is introduced.
> The supported events aren't probe-able afaict so I don't
> think the driver can help.
Although the events are not probe-able, some events are specific to
certain Arm SPE versions. For example, E[23]:
| Data snooped.
| When FEAT_SPEv1p4 is implemented
With SPE version information, the perf tool can decode E[23] == 0 as:
"No snooping" for SPEv4
"No available information for snooping" for earlier SPE versions
Without SPE version information, it's impossible to distinguish
between these two cases.
Thanks,
Leo
More information about the linux-arm-kernel
mailing list