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.
