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]

Message-ID: <cf7d8003-9700-880f-0e46-ff40e6348bb1@huawei.com>
Date:   Wed, 18 May 2022 14:48:17 +0100
From:   John Garry <john.garry@...wei.com>
To:     Robin Murphy <robin.murphy@....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 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?

Thanks,
John