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

Nicolas Pitre nicolas.pitre at linaro.org
Wed Dec 18 14:57:00 EST 2013


On Wed, 18 Dec 2013, Ard Biesheuvel wrote:

> On 18 December 2013 15:27, Christopher Covington <cov at codeaurora.org> wrote:
> >
> > 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.
> >
> 
> My apologies for adding to the confusion (or creating it in the first place).
> 
> However, the bottom line is that, as the 32 bit and 64 bit kernels are
> both able to support userland processes running in the execution state
> that has retroactively been dubbed 'AArch32', they should both honor
> the same contract with AArch32 userland on how to discover CPU
> capabilities at runtime. I do understand Russell's reservations about
> allocating 6 of the remaining 10 hwcaps bits, and I am open to
> suggestions on a better approach.

What is the reason for eating a grand total of 6 bits at once in the 
first place?

Are those capabilities really going to be independently integrated?  In 
other words, what is the probability for a vendor to integrate some but 
not the others?  If this probability is low then maybe a smaller set of 
wider-covering bits would be good enough in practice, and then some 
kernel emulation could be added for the odd cases.


Nicolas



More information about the linux-arm-kernel mailing list