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:43:40 +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:19:59 +0100,
Marc Zyngier <maz@...nel.org> wrote:
> 
> 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.

A quick experiment shows that these events are counting on all 3
expected counters:

maz@...y-lou:~$ sudo taskset -c 8 perf stat -e r096:u -e r096:u -e r096:u sleep 5

 Performance counter stats for 'sleep 5':

            10,775      r096:u                                                                
            10,775      r096:u                                                                
            10,775      r096:u                                                                

       5.000110823 seconds time elapsed

       0.000340000 seconds user
       0.000000000 seconds sys


maz@...y-lou:~$ sudo taskset -c 8 perf stat -e r09b:u -e r09b:u -e r09b:u sleep 5

 Performance counter stats for 'sleep 5':

            41,927      r09b:u                                                                
            41,927      r09b:u                                                                
            41,927      r09b:u                                                                

       5.000109771 seconds time elapsed

       0.000339000 seconds user
       0.000000000 seconds sys

This is on M2 Pro, by the way, and I also checked that my M1 Ultra
counts the exact same way.

Yangyu, can you please clarify how you came to the conclusion that
these events didn't count anywhere other than counter 7?

	M.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ