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

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

[Yangyu Chen]

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@cyyself.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,
-- 
2.45.1

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

[Will Deacon]

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@cyyself.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.

Cheers,

Will

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

[Marc Zyngier]

On Mon, 01 Jul 2024 15:01:48 +0100,
Will Deacon <will@kernel.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@cyyself.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.

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

[Marc Zyngier]

On Mon, 01 Jul 2024 15:19:59 +0100,
Marc Zyngier <maz@kernel.org> wrote:
> 
> On Mon, 01 Jul 2024 15:01:48 +0100,
> Will Deacon <will@kernel.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@cyyself.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@mary-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@mary-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.

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

[Yangyu Chen]

> 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.

There are some other reasons, but I can't say in public.

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.

Thanks,
Yangyu Chen

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

[Marc Zyngier]

On Tue, 02 Jul 2024 11:22:21 +0100,
Yangyu Chen <cyy@cyyself.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.

Thanks,

	M.

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

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

[Will Deacon]

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@cyyself.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

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

[Yangyu Chen]

> On Jul 2, 2024, at 20:13, Will Deacon <will@kernel.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@cyyself.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

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

[Will Deacon]

On Tue, Jul 02, 2024 at 08:43:16PM +0800, Yangyu Chen wrote:
> 
> 
> > On Jul 2, 2024, at 20:13, Will Deacon <will@kernel.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@cyyself.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

I can't say I feel hugely comfortable with this, so I'll leave the code
as-is unless a patch shows up fixing all the events.

Thanks for the reply, though. You've clearly spent a bunch of effort on
this and it's a pity we can't easily apply your results to the driver :/

Will

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

[Hector Martin]

On 2024/07/08 21:00, Will Deacon wrote:
> On Tue, Jul 02, 2024 at 08:43:16PM +0800, Yangyu Chen wrote:
>>
>>
>>> On Jul 2, 2024, at 20:13, Will Deacon <will@kernel.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@cyyself.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
> 
> I can't say I feel hugely comfortable with this, so I'll leave the code
> as-is unless a patch shows up fixing all the events.
> 
> Thanks for the reply, though. You've clearly spent a bunch of effort on
> this and it's a pity we can't easily apply your results to the driver :/
> 
> Will
> 

Putting on my "reverse engineering hardware for over a decade" hat on:
Facts about hardware are not copyrightable. If they were, our entire
effort would be legally questionable to begin with (as would all Linux
porting efforts to undocumented hardware).

Data files can be, but if the information contained within them is
purely non-copyrightable (as an affinity mapping for PMU events would
be), then it is entirely legal and acceptable to use that information to
create a patch, as long as the information itself was legitimately
obtained (which it can be for any macOS user, which by extension means
any owner of an AS Mac since macOS is implicitly licensed).

In other words, if you have macOS, and you run those scripts and
generate some patches for Linux that add the event definitions and
mappings, then it would not cause any copyright infringement concerns
for the Linux kernel side and they can be licensed GPLv2.

I have acquaintances who have consulted lawyers about this issue and am
very confident in this interpretation. More specifically, I'm told there
is legal advice that hardware register names are not copyrightable
(which goes beyond pure hardware facts as there is some freedom to
choose naming schemes). PMU event names are analogous here.

The big no-nos are ripping and redistributing files from macOS verbatim
(when that is necessary, we treat it as firmware and already have a
process in place to avoid redistribution, e.g. what we do for camera
sensor calibration blobs, but that is not the case here), using
*leaked/stolen* information (not legitimately obtained, e.g. actual
internal documentation that was stolen), and potentially
decompiling/reverse engineering actual executable code (things get very
complicated in this case, but it is not impossible to do legally).

For more details, we have a page on our copyright policy for the Asahi
project and how to avoid running into legal issues:
https://asahilinux.org/copyright/

TL;DR I would not have any copyright concerns about submission of a
patch adding all the PMU definitions (general event names and affinity
mappings).

- Hector