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

[Christopher Covington]

On 12/18/2013 07:03 AM, Catalin Marinas wrote:
> 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.

I do not think that Russell is the source of the confusion. Ard wrote, "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)." I think s/ARM64/ARMv8/ is
necessary to make the statement correct, and hopefully less confusing.

Christopher

-- 
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by the Linux Foundation.