Hi,
For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
AA64PFR0[47:44] field is not set, and AMU does not get enabled for them.
Can you please provide support for these CPUs in cpufeature.c?
Thanks
Neeraj
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation
On 2020-11-20 04:30, Neeraj Upadhyay wrote:
> Hi,
>
> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
> them.
> Can you please provide support for these CPUs in cpufeature.c?
If that was the case, that'd be an erratum, and it would need to be
documented as such. It could also be that this is an optional feature
for these cores (though the TRM doesn't suggest that).
Can someone at ARM confirm what is the expected behaviour of these CPUs?
M.
--
Jazz is not dead. It just smells funny...
On 11/20/20 8:56 AM, Marc Zyngier wrote:
> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>> Hi,
>>
>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>> them.
>> Can you please provide support for these CPUs in cpufeature.c?
>
> If that was the case, that'd be an erratum, and it would need to be
> documented as such. It could also be that this is an optional feature
> for these cores (though the TRM doesn't suggest that).
>
> Can someone at ARM confirm what is the expected behaviour of these CPUs?
Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
catches architected one.
Cheers
Vladimir
>
> M.
On 2020-11-20 09:09, Vladimir Murzin wrote:
> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>> Hi,
>>>
>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>> them.
>>> Can you please provide support for these CPUs in cpufeature.c?
>>
>> If that was the case, that'd be an erratum, and it would need to be
>> documented as such. It could also be that this is an optional feature
>> for these cores (though the TRM doesn't suggest that).
>>
>> Can someone at ARM confirm what is the expected behaviour of these
>> CPUs?
>
> Not a confirmation, but IIRC, these are imp def features, while our
> cpufeatures
> catches architected one.
Ah, good point. So these CPUs implement some sort of AMU, and not *the*
AMU.
Yet the register names are the same. Who thought that'd be a good idea?
M.
--
Jazz is not dead. It just smells funny...
On Fri, Nov 20, 2020 at 09:09:00AM +0000, Vladimir Murzin wrote:
> On 11/20/20 8:56 AM, Marc Zyngier wrote:
> > On 2020-11-20 04:30, Neeraj Upadhyay wrote:
> >> Hi,
> >>
> >> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
> >> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
> >> them.
> >> Can you please provide support for these CPUs in cpufeature.c?
> >
> > If that was the case, that'd be an erratum, and it would need to be
> > documented as such. It could also be that this is an optional feature
> > for these cores (though the TRM doesn't suggest that).
> >
> > Can someone at ARM confirm what is the expected behaviour of these CPUs?
>
> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
> catches architected one.
We generally don't make use of IMP-DEF featurees because of all the pain
it brings.
Looking at the Cortex-A76 TRM, the encoding for AMCNTENCLR is:
Op0: 3 (0b11)
Op1: 3 (0b011)
CRn: 15 (0b1111)
CRm: 9 (0b1001)
Op2: 7 (0b111)
... whereas the architected encoding (from our sysreg.h) is:
Op0: 3
Op1: 3
CRn: 13
CRm: 2
Op2: 4
... so that's a different register with the same name, which is
confusing and unfortunate.
The encodings are different (and I haven't checked whether the fields /
semantics are the same), so it's not just a matter of wiring up new
detection code. There are also IMP-DEF traps in ACTLR_EL3 and ACTLR_EL2
which we can't be certain of the configuration of, and as the registers
are in the IMP-DEF encoding space they'll be trapped by HCR_EL2.TIDCP
and emulated as UNDEFINED by a hypervisor. All of that means that going
by the MIDR alone is not sufficient to know we can safely access the
registers.
So as usual for IMP-DEF stuff I don't think we can or should make use of
this.
Thanks,
Mark.
On 11/20/20 9:54 AM, Marc Zyngier wrote:
> On 2020-11-20 09:09, Vladimir Murzin wrote:
>> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>>> Hi,
>>>>
>>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>>> them.
>>>> Can you please provide support for these CPUs in cpufeature.c?
>>>
>>> If that was the case, that'd be an erratum, and it would need to be
>>> documented as such. It could also be that this is an optional feature
>>> for these cores (though the TRM doesn't suggest that).
>>>
>>> Can someone at ARM confirm what is the expected behaviour of these CPUs?
>>
>> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
>> catches architected one.
>
> Ah, good point. So these CPUs implement some sort of AMU, and not *the* AMU.
>
> Yet the register names are the same. Who thought that'd be a good idea?
IMO, it is the case where imp def has been generalized into arch extension, so
something have been moved over.
Cheers
Vladimir
>
> M.
On Fri, Nov 20, 2020 at 08:56:31AM +0000, Marc Zyngier wrote:
> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
> > Hi,
> >
> > For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
> > AA64PFR0[47:44] field is not set, and AMU does not get enabled for
> > them.
> > Can you please provide support for these CPUs in cpufeature.c?
>
> If that was the case, that'd be an erratum, and it would need to be
> documented as such. It could also be that this is an optional feature
> for these cores (though the TRM doesn't suggest that).
>
> Can someone at ARM confirm what is the expected behaviour of these CPUs?
IIRC discussion with Ionela long back, we intentionally decided not to
support IMPDEF(pre 8.4 non-architected so called AMUs) on the CPUs listed
in $subject.
--
Regards,
Sudeep
Thanks Marc, Vladimir, Mark, Sudeep for your inputs!
Thanks
Neeraj
On 11/20/2020 3:43 PM, Mark Rutland wrote:
> On Fri, Nov 20, 2020 at 09:09:00AM +0000, Vladimir Murzin wrote:
>> On 11/20/20 8:56 AM, Marc Zyngier wrote:
>>> On 2020-11-20 04:30, Neeraj Upadhyay wrote:
>>>> Hi,
>>>>
>>>> For ARM cortex A76, A77, A78 cores (which as per TRM, support AMU)
>>>> AA64PFR0[47:44] field is not set, and AMU does not get enabled for
>>>> them.
>>>> Can you please provide support for these CPUs in cpufeature.c?
>>>
>>> If that was the case, that'd be an erratum, and it would need to be
>>> documented as such. It could also be that this is an optional feature
>>> for these cores (though the TRM doesn't suggest that).
>>>
>>> Can someone at ARM confirm what is the expected behaviour of these CPUs?
>>
>> Not a confirmation, but IIRC, these are imp def features, while our cpufeatures
>> catches architected one.
>
> We generally don't make use of IMP-DEF featurees because of all the pain
> it brings.
>
> Looking at the Cortex-A76 TRM, the encoding for AMCNTENCLR is:
>
> Op0: 3 (0b11)
> Op1: 3 (0b011)
> CRn: 15 (0b1111)
> CRm: 9 (0b1001)
> Op2: 7 (0b111)
>
> ... whereas the architected encoding (from our sysreg.h) is:
>
> Op0: 3
> Op1: 3
> CRn: 13
> CRm: 2
> Op2: 4
>
> ... so that's a different register with the same name, which is
> confusing and unfortunate.
>
> The encodings are different (and I haven't checked whether the fields /
> semantics are the same), so it's not just a matter of wiring up new
> detection code. There are also IMP-DEF traps in ACTLR_EL3 and ACTLR_EL2
> which we can't be certain of the configuration of, and as the registers
> are in the IMP-DEF encoding space they'll be trapped by HCR_EL2.TIDCP
> and emulated as UNDEFINED by a hypervisor. All of that means that going
> by the MIDR alone is not sufficient to know we can safely access the
> registers.
>
> So as usual for IMP-DEF stuff I don't think we can or should make use of
> this.
>
> Thanks,
> Mark.
>
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a
member of the Code Aurora Forum, hosted by The Linux Foundation