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

[Catalin Marinas]

On Wed, Dec 18, 2013 at 11:42:12AM +0000, Russell King - ARM Linux 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.

I'm not sure whether you are confusing architecture versions with
instruction sets / exception models or you are simply stating that the
32-bit arm kernel will stop at ARMv7.

> So, frankly, find a different way to this.  We don't need to needlessly
> waste HWCAP bits on ARM32.

So in your opinion 32-bit only ARMv8-R profile won't be fully supported
in the mainline kernel.

(I mistakenly said uClinux in my previous email; the normal/rich OS part
of the ARMv8-R is AArch32 MMU capable, the Hyp and real-time
capabilities are MMU-less, only MPU)

-- 
Catalin