linux-kernel - Re: [PATCH v5 00/10] drivers/perf: CPU PMU driver for Apple M1

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] [day] [month] [year] [list]

Date:   Tue, 8 Mar 2022 14:10:50 +0000
From:   Will Deacon <will@...nel.org>
To:     Marc Zyngier <maz@...nel.org>
Cc:     linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
        Hector Martin <marcan@...can.st>,
        Sven Peter <sven@...npeter.dev>,
        Alyssa Rosenzweig <alyssa@...enzweig.io>,
        Rob Herring <robh+dt@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Dougall <dougallj@...il.com>, kernel-team@...roid.com
Subject: Re: [PATCH v5 00/10] drivers/perf: CPU PMU driver for Apple M1

On Mon, Mar 07, 2022 at 03:55:44PM +0000, Marc Zyngier wrote:
> On Tue, 08 Feb 2022 18:55:54 +0000,
> Marc Zyngier <maz@...nel.org> wrote:
> > 
> > The M1 SoC embeds a per-CPU PMU that has a very different programming
> > interface compared to the architected PMUv3 that is normally present
> > on standard implementations.
> > 
> > This small series adds a driver for this HW by leveraging the arm_pmu
> > infrastructure, resulting in a rather simple driver.
> > 
> > Of course, we know next to nothing about the actual events this PMU
> > counts, aside from CPU cycles and instructions. Everything else is
> > undocumented (though as Dougall pointed out, someone could extract the
> > relevant information from a macOS install if they wanted -- I don't).
> > I'm looking at allowing the perf userspace tool to load the event
> > descriptions at runtime, which would probably help.
> 
> [...]
> 
> FWIW, I have created two branches:
> 
> - [1] has the full series
> - [2] has the irqchip/DT prefix of [1]
> 
> Both branches are stable, and I expect [2] to be used as a shared
> branch between the irqchip and perf trees.

Cheers, I've picked this up in the arm64 tree (by pulling [2] and applying
the two extra patches from [1] on top) here:

https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git/log/?h=for-next/perf-m1

Will