linux-kernel - Re: [PATCH v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b

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: Tue, 2 Jul 2024 20:43:16 +0800
From: Yangyu Chen <cyy@...self.name>
To: Will Deacon <will@...nel.org>
Cc: Marc Zyngier <maz@...nel.org>,
 linux-arm-kernel@...ts.infradead.org,
 Mark Rutland <mark.rutland@....com>,
 Janne Grunau <j@...nau.net>,
 Hector Martin <marcan@...can.st>,
 Asahi Lina <lina@...hilina.net>,
 asahi@...ts.linux.dev,
 Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v1] drivers/perf: apple_m1: fix affinity table for event
 0x96 and 0x9b



> On Jul 2, 2024, at 20:13, Will Deacon <will@...nel.org> wrote:
> 
> On Tue, Jul 02, 2024 at 11:58:00AM +0100, Marc Zyngier wrote:
>> On Tue, 02 Jul 2024 11:22:21 +0100,
>> Yangyu Chen <cyy@...self.name> wrote:
>>> 
>>>> Yangyu, can you please clarify how you came to the conclusion that
>>>> these events didn't count anywhere other than counter 7?
>>>> 
>>> 
>>> IIRC, I came across some web page that says events 0x96 and 0x9b
>>> can only be installed on counter 7 to count Apple AMX, but I can't
>>> find the page now. Since AMX is not usable in Linux, I don't know
>>> if this will affect some other instructions that are usable in
>>> Linux.
>> 
>> As you said, AMX cannot be used with Linux, and that's unlikely to
>> ever change. But when it comes to the standard ARM ISA, we can only
>> witness counters 5,6 and 7 being incremented with at the exact same
>> rate.
>> 
>> So reading between the lines, what I understand is that AMX
>> instructions would only have their effects counted in counter 7 for
>> these events, while other instructions would be counted in all 3
>> counters.
>> 
>> By extension, such behaviour could be applied to SME on HW that
>> supports it (wild guess).
>> 
>>> There are some other reasons, but I can't say in public.
>> 
>> Fair enough, I'm not asking for the disclosure of anything that isn't
>> public (the least I know, the better).
>> 
>>> Even though I can't find the actual usage, I think using count 7
>>> only for these 2 events is safer. If this reason is insufficient,
>>> we can ignore this patch until we find other evidence that this
>>> affinity affects some instructions usable in Linux.
>> 
>> I honestly don't mind.
>> 
>> The whole thing is a black box, and is more useful as an interrupt
>> generator than an actual PMU, due to the lack of freely available
>> documentation. If the PMU maintainers want to merge this, I won't
>> oppose it.
> 
> I'd rather leave the code as-is than tweak specific counters based on
> a combination of guesswork and partial information.
> 
> Of course, if somebody who knows better wants to fix up all of the
> mappings (because this surely isn't the only corner-case), then we can
> take that. But at least what we have today has _some_ sort of consistent
> rationale behind it.

Actually, anyone who has macOS software can learn the whole affinity
table of PMU. The detailed information can be extracted from a plist
file stored in the macOS root filesystem. I also provide that script
[1] to extract this information.

However, I can't directly use this information for legal concerns.
Would this be acceptable if the information I provide matches Apple's
information? I can't say whether it matches or not in public. I can
only say we can easily find someone who uploaded this file to the
internet.

[1] https://github.com/cyyself/m1-pmu-gen

> 
> Will