linux-kernel - Re: AMU extension v1 support for cortex A76, A77, A78 CPUs

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 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:   Fri, 20 Nov 2020 10:14:50 +0000
From:   Vladimir Murzin <vladimir.murzin@....com>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Neeraj Upadhyay <neeraju@...eaurora.org>, mark.rutland@....com,
        suzuki.poulose@....com, ionela.voinescu@....com,
        MSM <linux-arm-msm@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>, catalin.marinas@....com,
        Will Deacon <will@...nel.org>, valentin.schneider@....com,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: AMU extension v1 support for cortex A76, A77, A78 CPUs

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.