[PATCH 0/4] arm64: advertise availability of CRC and crypto instructions

[Ard Biesheuvel]

On 18 December 2013 12:42, Russell King - ARM Linux
<linux at arm.linux.org.uk> wrote:
> On Wed, Dec 18, 2013 at 11:27:14AM +0000, Catalin Marinas wrote:
>> On Wed, Dec 18, 2013 at 11:15:45AM +0000, Ard Biesheuvel wrote:
>> > On 18 December 2013 11:55, Russell King - ARM Linux
>> > <linux at arm.linux.org.uk> wrote:
>> > > On Wed, Dec 18, 2013 at 11:25:40AM +0100, Ard Biesheuvel wrote:
>> > >> On 18 December 2013 11:03, Russell King - ARM Linux
>> > >> <linux at arm.linux.org.uk> wrote:
>> > >> > If we allocate the ARM64 private never-will-appear-on-ARM hwcaps in bit
>> > >> > 32 and above, they'll be hidden from 32-bit stuff.  Hopefully, glibc
>> > >> > doesn't concatenate the HWCAP and HWCAP2 fields though - someone should
>> > >> > check that.
>> > >> >
>> > >> > Since the bits in the ARM64 hwcap are different from the ARM32 hwcap, I
>> > >> > don't see any point in defining them for ARM32 - userspace needs to make
>> > >> > the definition conditional anyway, and can't interpret the bits as-is
>> > >> > because ARM64 already omits many of the ARM32 ones.
>> > >>
>> > >> Please note that this is about the compat bits, not the ARM64 specific
>> > >> ones. These correspond 1:1 with the ARM32 ones. The idea is that a
>> > >> binary built for ARM will have access to the extended instructions
>> > >> which ARM64 offers to ARM32 binaries running in 32 bit compatibility
>> > >> mode (such as AES, SHAx etc).
>> > >
>> > > This all sounds rather silly IMHO.  As ARM32 natively doesn't support
>> > > these instructions, why should running an ARM32 binary under ARM64
>> > > end up offering this?
>> > >
>> > > If the ARM64 additional instructions are to be used, surely it's not
>> > > unreasonable to require ARM64 native applications?
>> >
>> > Well, the ARM architects have decided that there shall be Crypto
>> > Extensions instructions not only for ARMv8/Aarch64 but also for
>> > ARMv8/Aarch32. This is fully spec'ed in the latest ARM ARM. For
>> > instance, previously unused NEON opcodes on ARM32 have been allocated
>> > to AES instructions. (for instance, implemented for QEMU here
>> > https://git.linaro.org/people/peter.maydell/qemu-arm.git/commitdiff/9d935509)
>>
>> Indeed. AArch32 is not _dead_ with ARMv8 but getting new features. The
>> point of this patch is to have a common set of bits between compat arm64
>> and arm kernel. The AArch32 applications running on ARMv8 (most likely
>> with an arm64 kernel) may want to make use of the crypto extensions.
>>
>> If you want a more complete solution, we could add ID_ISAR5 checks on
>> the arm kernel.
>
> The point is that they'll never appear on an ARMv7 implementation because
> they're not part of the ARMv7 architecture.  I see no point in needlessly
> polluting ARM32 with ARM64 stuff - in exactly the same way that you see
> no point in polluting ARM64 with ARM32 stuff.
>

You are assuming ARMv7 == ARM32 and ARMv8 == ARM64, while in reality,
they are orthogonal.

The 32-bit kernel you are maintaining can potentially run on 32-bit
only v8 implementations (as Catalin pointed out), and both the arm64
and ARM kernels contain implementations for the Aarch32 userland ABI.

So if the current proposal is unsuitable in your opinion, could we at
least have your input on how it should be done instead? Preferably
using a method that supports ifunc relocations, so the loader can
automatically resolve the correct implementation for the hardware at
hand?

Regards,
Ard.