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

[James Clark]

On 14/07/2025 4:42 pm, Leo Yan wrote:
> 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.
> 

If the RAZ/WI for not implemented is guaranteed, can we not discover the 
supported filter by writing all ones and reading back what stuck?

> 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
I think Leo has a point that some of these shouldn't require any MIDR 
mappings, and if we're using a filter for some builtin part of the Perf 
tool then it would be good to have that work everywhere, rather than 
having to update for every new CPU.

We're already publishing the SPE version in dmesg so if we decide to not 
publish the filters we'd probably go and try to parse that instead. At 
that point maybe we should publish the SPE version in sysfs properly. At 
least that's scalable unlike having to update the filters all the time.

James