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: <2d73146a-86fc-e0d1-11b9-432c7431d58a@huawei.com>
Date:   Thu, 19 May 2022 08:59:48 +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 15:14, Robin Murphy wrote:
>> 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, 

If size is an issue then we have ways to cut this down, like doing the 
arch standard events fixup dynamically when running perf tool, or even 
not describing those events in the JSONs and rely on reading the CPU PMU 
events folder to learn which of those events are supported.

 > but those are
 > such a minority that it seems like an entirely reasonable compromise.

@Nick, Can you drop the 32b core support for arm64? Or, if you really 
want them, look into ARCH=arm pmu-events support?

thanks,
John