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 13:13:40 +0100
From: Will Deacon <will@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Yangyu Chen <cyy@...self.name>, 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 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.

Will