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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZmAwYjyElYQqQy7c@J2N7QTR9R3>
Date: Wed, 5 Jun 2024 10:32:05 +0100
From: Mark Rutland <mark.rutland@....com>
To: Leo Yan <leo.yan@....com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>,
	Besar Wicaksono <bwicaksono@...dia.com>,
	Will Deacon <will@...nel.org>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Ian Rogers <irogers@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
	Kan Liang <kan.liang@...ux.intel.com>,
	Namhyung Kim <namhyung@...nel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-perf-users@...r.kernel.org, James Clark <james.clark@....com>
Subject: Re: [RFC/PATCH 1/1] tools headers arm64: Sync arm64's cputype.h with
 the kernel sources

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 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.

Mark.