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: Mon, 01 Jul 2024 15:19:59 +0100
From: Marc Zyngier <maz@...nel.org>
To: Yangyu Chen <cyy@...self.name>, Will Deacon <will@...nel.org>
Cc: 	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@...r.kernel.org
Subject: Re: [PATCH v1] drivers/perf: apple_m1: fix affinity table for event 0x96 and 0x9b

On Mon, 01 Jul 2024 15:01:48 +0100,
Will Deacon <will@...nel.org> wrote:
> 
> On Thu, Jun 20, 2024 at 11:04:28AM +0800, Yangyu Chen wrote:
> > Events 0x96 and 0x9b can be installed on counter 7 only. Fix this to avoid
> > getting the wrong counter value.
> > 
> > Signed-off-by: Yangyu Chen <cyy@...self.name>
> > ---
> >  drivers/perf/apple_m1_cpu_pmu.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/perf/apple_m1_cpu_pmu.c b/drivers/perf/apple_m1_cpu_pmu.c
> > index f322e5ca1114..b8127e5428e1 100644
> > --- a/drivers/perf/apple_m1_cpu_pmu.c
> > +++ b/drivers/perf/apple_m1_cpu_pmu.c
> > @@ -107,12 +107,12 @@ static const u16 m1_pmu_event_affinity[M1_PMU_PERFCTR_LAST + 1] = {
> >  	[M1_PMU_PERFCTR_UNKNOWN_93]	= ONLY_5_6_7,
> >  	[M1_PMU_PERFCTR_UNKNOWN_94]	= ONLY_5_6_7,
> >  	[M1_PMU_PERFCTR_UNKNOWN_95]	= ONLY_5_6_7,
> > -	[M1_PMU_PERFCTR_UNKNOWN_96]	= ONLY_5_6_7,
> > +	[M1_PMU_PERFCTR_UNKNOWN_96]	= BIT(7),
> >  	[M1_PMU_PERFCTR_UNKNOWN_97]	= BIT(7),
> >  	[M1_PMU_PERFCTR_UNKNOWN_98]	= ONLY_5_6_7,
> >  	[M1_PMU_PERFCTR_UNKNOWN_99]	= ONLY_5_6_7,
> >  	[M1_PMU_PERFCTR_UNKNOWN_9a]	= BIT(7),
> > -	[M1_PMU_PERFCTR_UNKNOWN_9b]	= ONLY_5_6_7,
> > +	[M1_PMU_PERFCTR_UNKNOWN_9b]	= BIT(7),
> >  	[M1_PMU_PERFCTR_UNKNOWN_9c]	= ONLY_5_6_7,
> >  	[M1_PMU_PERFCTR_UNKNOWN_9f]	= BIT(7),
> >  	[M1_PMU_PERFCTR_UNKNOWN_bf]	= ONLY_5_6_7,
> 
> It would be great if somebody with access to M1 hardware (and/or any
> PMU insight) could Test or Ack this, please.

I'm a bit concerned by this.

I originally generated this table by hacking the counter setup so that
it would try and count everywhere, and then feed the observations back
into the driver.

So either my methodology was flaky (not unlikely), but I'd then expect
more of these mis-assignments, or this applies to an implementation
that is different from the one I wrote this driver against (the
original M1). Could it be that this for M2 only, and not M1? Or
another flavour of M1?

Either way, it would be good to understand how this has been
established.

In the meantime, I'll try and resurrect my original experiment and see
if I spot the same issue.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.