[PATCH] ARM: advertise availability of v8 Crypto instructions

Ard Biesheuvel ard.biesheuvel at linaro.org
Wed Mar 4 08:31:00 PST 2015


On 4 March 2015 at 17:20, Catalin Marinas <catalin.marinas at arm.com> wrote:
> On Tue, Mar 03, 2015 at 02:43:01PM +0100, Ard Biesheuvel wrote:
>> On 27 February 2015 at 17:36, Ard Biesheuvel <ard.biesheuvel at linaro.org> wrote:
>> > When running the 32-bit ARM kernel on ARMv8 capable bare metal (e.g.,
>> > 32-bit Android userland and kernel on a Cortex-A53), or as a KVM guest
>> > on a 64-bit host, we should advertise the availability of the Crypto
>> > instructions, so that userland libraries such as OpenSSL may use them.
>> > (Support for the v8 Crypto instructions in the 32-bit build was added
>> > to OpenSSL more than six months ago)
>> >
>> > This adds the ID feature bit detection, and sets elf_hwcap2 accordingly.
>> >
>> > Signed-off-by: Ard Biesheuvel <ard.biesheuvel at linaro.org>
>> > ---
>> >  arch/arm/kernel/setup.c | 16 ++++++++++++++++
>> >  1 file changed, 16 insertions(+)
>> >
>> > diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
>> > index e55408e96559..8d4cb1c1c9ac 100644
>> > --- a/arch/arm/kernel/setup.c
>> > +++ b/arch/arm/kernel/setup.c
>> > @@ -393,6 +393,22 @@ static void __init cpuid_init_hwcaps(void)
>> >         vmsa = (read_cpuid_ext(CPUID_EXT_MMFR0) & 0xf) >> 0;
>> >         if (vmsa >= 5)
>> >                 elf_hwcap |= HWCAP_LPAE;
>> > +
>> > +       /* check for supported v8 Crypto instructions on non v7-M CPUs */
>>
>> Perhaps this should be 'on v7+ (non v7-M) CPUs'
>>
>> > +       if (cpu_architecture() == CPU_ARCH_ARMv7) {
>>
>> @Russell: any thoughts on this?
>>
>> Currently, v8 CPUs are identified as CPU_ARCH_ARMv7, and there is no
>> point in performing this test on other architectures (including v7-M)
>
> With the new CPUID scheme introduced around v6/v7, the OS is no longer
> meant to read much into the architecture version. Even the current
> __get_cpu_architecture() function that we have returns the VMSA version
> and not the actual CPU architecture version (for example, ARM11MPCore is
> reported as ARMv7 by Linux when it's clearly an ARMv6). With ARMv8, the
> ID_MMFR0 would still report VMSAv7 with LPAE (0b0101) like on a
> Cortex-A15. You may be able to guess it's an ARMv8 from other fields
> like ID_ISAR2[3:0] (acquire/release semantics for load/store) but that's
> not how CPUID registers are meant to be used.
>

It doesn't really matter which architecture it is. I just want to be
reasonably sure that reading ID_ISAR5 isn't going to explode. If there
are other/better ways to guarantee that, I am happy to use those as
well. (I noticed that there is a v7-M specific definition of ID_ISAR5
in the source which I couldn't find any reference to in any of the
Cortex-M TRMs on the infocenter web site.)

> If we are bothered by the ARMv7 name, we could redefine some of these
> macros to make it clear that the arch version is no longer relevant,
> something like below (covering the profile names as well):
>
>         CPU_ARCH_CPUID_A
>         CPU_ARCH_CPUID_R
>         CPU_ARCH_CPUID_M
>
> Once you find such cpu arch number, you know you have access to the
> architected CPUID registers.
>

Let's just rename 7 to 7up  and be done with it :-)



More information about the linux-arm-kernel mailing list