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]

Date: Tue, 4 Jun 2024 15:34:36 +0100
From: Mark Rutland <mark.rutland@....com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: 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
Subject: Re: [RFC/PATCH 1/1] tools headers arm64: Sync arm64's cputype.h with
 the kernel sources

On Tue, Jun 04, 2024 at 10:53:38AM -0300, Arnaldo Carvalho de Melo wrote:
> On Tue, Jun 04, 2024 at 10:11:22AM +0100, Mark Rutland wrote:
> > On Mon, Jun 03, 2024 at 03:33:07PM -0300, Arnaldo Carvalho de Melo wrote:
> > > The changes in the above patch add MIDR_NEOVERSE_V[23] and
> > > MIDR_NEOVERSE_V1 is used in arm-spe.c, so probably we need to add those
> > > and perhaps MIDR_CORTEX_X4 to that array? Or maybe we need to leave this
> > > for later when this is all tested on those machines?
> > 
> > Hmm... looking at where that was added this is somewhat misnamed, this
> > is really saying that these cores use the same IMPLEMENTATION DEFINED
> > encoding of the source field. That's not really a property of Neoverse
> > specifically, and I'm not sure what Arm's policy is here going forwards.
> > 
> > We should probably rename that to something like
> > common_data_source_encoding, with a big comment about exactly what it
> > implies.
> > 
> > I would not touch this for now -- someone would have to go audit the
> 
> Ok, you mean not touch tools/perf/util/arm-spe.c, right, can I just go
> ahead and update the copy of that header so that we have a clean (of
> build warnings) build?

Yes: update the header, but leave arm-spe.c unchanged. Sorry for not
being clear!

It'd be nice if we could update the commit message to note that we're
deliberately leaving that as-is.

Either way:

Acked-by: Mark Rutland <mark.rutland@....com>

Mark.