[PATCH v3 01/14] drivers/perf: arm_spe: Expose event filter
Will Deacon
will at kernel.org
Thu Jul 17 04:43:46 PDT 2025
On Tue, Jul 15, 2025 at 12:15:07PM +0100, James Clark wrote:
> 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?
That might be the best option.
Looking back at older versions of the architecture, unallocated fields
in PMSEVFR_EL1 were RES0 in revision D.a of the Arm ARM but everything
became RAZ/WI in revision D.b, so the whole reason we were maintaining
these masks in the driver is no longer relevant.
As you say, we can just probe the thing and report the result back to
userspace.
Will
More information about the linux-arm-kernel
mailing list