linux-kernel - Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs

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:   Wed, 18 May 2022 15:14:26 +0100
From:   Robin Murphy <robin.murphy@....com>
To:     John Garry <john.garry@...wei.com>,
        Nick Forrington <nick.forrington@....com>,
        linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org,
        acme@...nel.org
Cc:     Will Deacon <will@...nel.org>,
        Mathieu Poirier <mathieu.poirier@...aro.org>,
        Leo Yan <leo.yan@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...nel.org>,
        Namhyung Kim <namhyung@...nel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Kajol Jain <kjain@...ux.ibm.com>,
        James Clark <james.clark@....com>,
        Andrew Kilroy <andrew.kilroy@....com>
Subject: Re: [PATCH 00/20] perf vendors events arm64: Multiple Arm CPUs

On 2022-05-18 14:48, John Garry wrote:
> On 18/05/2022 13:32, Robin Murphy wrote:
>>> If we were to add to arm32/arm then the common event numbers and 
>>> maybe other JSONs in future would need to be duplicated.
>>>
>>> Would there be any reason to add to arm32/arm apart to from being 
>>> strictly proper? Maybe if lots of other 32b support for other vendors 
>>> came along then it could make sense (to separate them out).
>>
>> That's the heart of the question, really. At best it seems 
>> unnecessarily confusing as-is. 
> 
> I think it comes down to the first core supported was TX2 and the build 
> system relies on the target arch to decide which arch from 
> pmu-events/arch to compile.
> 
>> AFAICS either the naming isn't functional, wherein it would 
>> potentially make the most sense to rename the whole thing 
>> "pmu-events/arch/arm" if it's merely for categorising Arm 
>> architectures in general, or it is actually tied to the host triplet, 
>> in which case the above patches are most likely useless.
> 
> Today ARCH=arm has no pmu-events support. I think that it should be easy 
> to add plumbing for that. It becomes more tricky with supporting a 
> single "arm" folder.
> 
> But then do people really care enough about pmu-events for these 32b 
> cores? Until now, it seems not.
> 
>>
>> I'd agree that there doesn't seem much point in trying to separate 
>> things along relatively arbitrary lines if it *isn't* functionally 
>> necessary - the PMUv2 common events look to be a straightforward 
>> subset of the PMUv3 ones, but then there's Cortex-A32 anyway, plus 
>> most of the already-supported CPUs could equally run an AArch32 perf 
>> tool as well.
> 
> Sure, we should have these 32b cores supported for ARCH=arm if they are 
> supported for ARCH=arm64. But then does it even make sense to have A7 
> support in arch/arm64?

That's what I'm getting at. If it is tied to the build target as you've 
said above, then there is no point in an AArch64 perf tool including 
data for CPUs on which that tool cannot possibly run; it's simply a 
waste of space.

If there is interest in plumbing in support on AArch32 builds as well, 
then I'd still be inclined to have a single arch/arm events directory, 
and either do some build-time path munging or just symlink an arch/arm64 
sibling back to it. Yes, technically there are AArch64-only CPUs whose 
data would then be redundant when building for AArch32, but those are 
such a minority that it seems like an entirely reasonable compromise.

Thanks,
Robin.