Re: [PATCH v3 01/14] drivers/perf: arm_spe: Expose event filter

[Leo Yan <leo.yan@arm.com>]

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