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: <a1990b2e-2c10-42b6-93e9-fef324cb91b2@arm.com>
Date: Tue, 4 Jun 2024 18:14:22 +0100
From: Leo Yan <leo.yan@....com>
To: Mark Rutland <mark.rutland@....com>,
 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, James Clark <james.clark@....com>
Subject: Re: [RFC/PATCH 1/1] tools headers arm64: Sync arm64's cputype.h with
 the kernel sources

On 6/4/24 10:11, Mark Rutland wrote:
> Hi Arnaldo,
> 
> On Mon, Jun 03, 2024 at 03:33:07PM -0300, Arnaldo Carvalho de Melo wrote:
>> To get the changes in:
>>
>>    0ce85db6c2141b7f ("arm64: cputype: Add Neoverse-V3 definitions")
>>    02a0a04676fa7796 ("arm64: cputype: Add Cortex-X4 definitions")
>>    f4d9d9dcc70b96b5 ("arm64: Add Neoverse-V2 part")
> 
> As a heads-up, there are likely to be a couple more updates here
> shortly:
> 
>    https://lore.kernel.org/linux-arm-kernel/20240603111812.1514101-1-mark.rutland@arm.com/
> 
>> That makes this perf source code to be rebuilt:
>>
>>    CC      /tmp/build/perf-tools/util/arm-spe.o
>>
>> 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.

Agreed.

I went through Neoverse-V2/V3/V4, Cortex-X4, Cortex-X4, Cortex-A720, and 
Cortex-X925, all of them have the same definition for data source packet 
format. It makes sense to change name to Neoverse specific to a more 
general name.

> I would not touch this for now -- someone would have to go audit the
> TRMs to check that those other cores have the same encoding, and I think
> it'd be better to do that as a follow-up.

So far, it's fine to not change the file util/arm-spe.c.

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

Thanks,
Leo