Re: [PATCH v10 1/3] arm64: Implement archrandom.h for ARMv8.5-RNG

On Thu, 16 Jan 2020 at 12:02, Catalin Marinas [off-list ref] wrote:

On Wed, Jan 15, 2020 at 02:23:39PM -1000, Richard Henderson wrote:

quoted

On 1/15/20 4:26 AM, Catalin Marinas wrote:

quoted

On Wed, Jan 15, 2020 at 11:07:20AM +0000, Mark Brown wrote:

quoted

On Wed, Jan 15, 2020 at 10:24:21AM +0100, Ard Biesheuvel wrote:

quoted

On Wed, 15 Jan 2020 at 10:16, Will Deacon [off-list ref] wrote:

quoted

quoted

I see your argument, but I was just going on the side of consistency because
we're continuing to expose other features as HWCAPs when the capability is
just a proxy for the cpuid field. I was in favour of stopping the addition
of such HWCAPs years ago, but I couldn't convince Catalin ;)

quoted

quoted

The way I see it, we'll soon run out of HWCAP2 bits and then we'll have
our hand forced.

quoted

I don't have a strong opinion either way.

Me either, or at least not enough to object to doing it - Will?
Catalin?

Until the ifunc resolver can work with CPUID, I think we should keep
adding HWCAPn bits. We can revisit this with the toolchain people before
introducing HWCAP3.

Why would the ifunc resolver not be able to use HWCAP_CPUID?

It can indeed check the HWCAP_CPUID but I haven't seen any plans to
implement the next part, actual use of an MRS instruction to read the
corresponding ID_AA64* regs. This MRS emulation was requested by (some
of) the toolchain people, even the architecture gained a feature to
simplify the emulation, but followed by complete silence from the
toolchain folk.

But what infrastructure would the toolchain folks need to provide
here? An ifunc resolver would simply do

void generic_func(...);
void foo_func(...);

void *resolve_foo(long hwcap)
{
   if (hwcap & HWCAP_CPUID) {
       long l;
       asm ("mrs %1, ID_AA64_...") : "=r"(l));
       if (l has 'foo')
         return foo_func;
   }
   return generic_func;
}

so all that is needed for using ID registers to do ifunc resolution is
already there.

quoted

That said, speaking as a toolchain guy, you should conserve HWCAP2 bits so
that, by preference, you do not need to introduce AT_HWCAP3.  Or at least delay
adding it.

We still have some time before AT_HWCAP3. Also, we have 32-bit spare in
both HWCAP and HWCAP2 which we can use. IIRC we didn't go into the top
32-bit of HWCAP because we were still debating whether ILP32 makes
sense (and now I'm 100% convinced it doesn't ;)).

--
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel