From: cov@codeaurora•org (Christopher Covington)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH 0/4] arm64: advertise availability of CRC and crypto instructions
Date: Wed, 18 Dec 2013 09:27:44 -0500 [thread overview]
Message-ID: <52B1B0E0.6030104@codeaurora.org> (raw)
In-Reply-To: <20131218120306.GC28112@arm.com>
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@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@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.
next prev parent reply other threads:[~2013-12-18 14:27 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-16 21:04 [PATCH 0/4] arm64: advertise availability of CRC and crypto instructions Ard Biesheuvel
2013-12-16 21:04 ` [PATCH 1/4] arm64: drop redundant macros from read_cpuid() Ard Biesheuvel
2013-12-17 12:04 ` Catalin Marinas
2013-12-17 12:10 ` Will Deacon
2013-12-17 12:12 ` Catalin Marinas
2013-12-16 21:04 ` [PATCH 2/4] arm64: Add hwcaps for crypto and CRC32 extensions Ard Biesheuvel
2013-12-17 12:08 ` Catalin Marinas
2013-12-17 12:11 ` Catalin Marinas
2013-12-16 21:04 ` [PATCH 3/4] ARM: allocate hwcaps bits for v8 crypto extensions Ard Biesheuvel
2013-12-16 21:04 ` [PATCH 4/4] arm64: add 32-bit compat hwcaps " Ard Biesheuvel
2013-12-17 12:25 ` [PATCH 0/4] arm64: advertise availability of CRC and crypto instructions Catalin Marinas
2013-12-18 9:50 ` Ard Biesheuvel
2013-12-18 10:03 ` Russell King - ARM Linux
2013-12-18 10:25 ` Ard Biesheuvel
2013-12-18 10:55 ` Russell King - ARM Linux
2013-12-18 11:15 ` Ard Biesheuvel
2013-12-18 11:27 ` Catalin Marinas
2013-12-18 11:34 ` Catalin Marinas
2013-12-18 11:42 ` Russell King - ARM Linux
2013-12-18 11:59 ` Ard Biesheuvel
2013-12-18 12:03 ` Catalin Marinas
2013-12-18 14:27 ` Christopher Covington [this message]
2013-12-18 16:13 ` Ard Biesheuvel
2013-12-18 17:29 ` Catalin Marinas
2013-12-18 18:50 ` Ard Biesheuvel
2013-12-19 11:11 ` Catalin Marinas
2013-12-18 19:57 ` Nicolas Pitre
2013-12-18 20:26 ` Ard Biesheuvel
2013-12-18 21:18 ` Nicolas Pitre
2013-12-18 21:57 ` Ard Biesheuvel
2013-12-19 6:48 ` Siarhei Siamashka
2013-12-19 11:48 ` Catalin Marinas
2013-12-20 6:29 ` Siarhei Siamashka
2013-12-20 11:27 ` Catalin Marinas
2013-12-19 17:33 ` Ard Biesheuvel
2013-12-20 1:35 ` Siarhei Siamashka
2013-12-19 18:07 ` Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52B1B0E0.6030104@codeaurora.org \
--to=cov@codeaurora$(echo .)org \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox