RE: [RFC/PATCH 1/1] tools headers arm64: Sync arm64's cputype.h with the kernel sources

[Besar Wicaksono]

> -----Original Message-----
> From: Mark Rutland <mark.rutland@xxxxxxx>
> Sent: Wednesday, June 5, 2024 4:32 PM
> To: Leo Yan <leo.yan@xxxxxxx>
> Cc: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>; Besar Wicaksono
> <bwicaksono@xxxxxxxxxx>; Will Deacon <will@xxxxxxxxxx>; Adrian Hunter
> <adrian.hunter@xxxxxxxxx>; Ian Rogers <irogers@xxxxxxxxxx>; Jiri Olsa
> <jolsa@xxxxxxxxxx>; Kan Liang <kan.liang@xxxxxxxxxxxxxxx>; Namhyung Kim
> <namhyung@xxxxxxxxxx>; Linux Kernel Mailing List <linux-
> kernel@xxxxxxxxxxxxxxx>; linux-perf-users@xxxxxxxxxxxxxxx; James Clark
> <james.clark@xxxxxxx>
> Subject: Re: [RFC/PATCH 1/1] tools headers arm64: Sync arm64's cputype.h
> with the kernel sources
> 
> External email: Use caution opening links or attachments
> 
> 
> On Tue, Jun 04, 2024 at 09:01:41PM +0100, Leo Yan wrote:
> > On 6/4/24 19:55, Mark Rutland wrote:
> >
> > [...]
> >
> > > > Now more and more Arm CPUs support the data source in SPE and share
> the same
> > > > data source format. It's not scalable for us to adding every CPU variant
> > > > into the file util/arm-spe.c.
> > > >
> > > > I would like to expose the PMSIDR_EL1.LDS bit (Data source indicator for
> > > > sampled load instructions) via the 'cap' folder, and then we can save this
> > > > info into the perf meta data during record phase.
> > >
> > > I'd be happy to expose fields from PMSIDR_EL1.
> > >
> > > > In the perf report, we can parse the meta data and if the
> > > > PMSIDR_EL1.LDS bit is set, the tool will parse the data source packet
> > > > based on the common format.
> > >
> > > I don't believe that's right.
> > >
> > > PMSIDR_EL1.LDS indicates that the loaded data source field is
> > > implemented, but even when it is implemented, the format is
> > > IMPLEMENTATION DEFINED.
> >
> > Thanks for correction. PMSIDR_EL1.LDS bit is necessary but not sufficient
> > for using the common data source format.
> >
> > > Today, Arm Ltd implementations happen to share a format, but that isn't
> > > implied by PMSIDR_EL1.LDS, and there's no guarantee that future CPUs
> > > will all use the same format.
> > >
> > > For the moment we'll have to keep adding to this list.

I apologize I didn't follow. Do you mean adding new CPU identifier to neoverse_spe[]
list is still the way to go for now?

> >
> > I would like to use an opposite way - we can only maintain CPU variants with
> > special data source format, otherwise, all other CPUs use the common format.
> 
> I think that's not a good idea.
> 
> Today, Arm Ltd CPUs happen to share *a* common format, but that's likely
> to change at some point in future, and CPUs from other vendors are
> likely to use different formats.
> 
> Assuming any format by default means that when CPUs with different
> formats are released, we'll produce incorrect results for those CPU by
> default, we'll need to update tables to exclude those CPUs, and we'll
> probably want to backport that exclusion to minimize the risk of users
> getting incorrect/misleading results.
> 
> While the current situation isn't nice, I think the alternative is
> worse -- it will confuse and anger users.
> 
> I think we need to talk with the Arm architects to see if they can
> define some discovery mechanism for the data source format.

Is there a follow-up on this from Arm?

Thanks,
Besar