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

From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Will Deacon <will@kernel.org>, Mark Brown <broonie@kernel.org>,
	Richard Henderson <richard.henderson@linaro.org>,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v10 1/3] arm64: Implement archrandom.h for ARMv8.5-RNG
Date: Thu, 16 Jan 2020 12:10:28 +0100	[thread overview]
Message-ID: <CAKv+Gu_Y3agWT1nOWHygc3An7zd2fAERcEq6Nav4geE0ahb+Xg@mail.gmail.com> (raw)
In-Reply-To: <20200116110245.GB10277@arrakis.emea.arm.com>

On Thu, 16 Jan 2020 at 12:02, Catalin Marinas <catalin.marinas@arm.com> wrote:
>
> On Wed, Jan 15, 2020 at 02:23:39PM -1000, Richard Henderson wrote:
> > On 1/15/20 4:26 AM, Catalin Marinas wrote:
> > > On Wed, Jan 15, 2020 at 11:07:20AM +0000, Mark Brown wrote:
> > >> On Wed, Jan 15, 2020 at 10:24:21AM +0100, Ard Biesheuvel wrote:
> > >>> On Wed, 15 Jan 2020 at 10:16, Will Deacon <will@kernel.org> wrote:
> > >>
> > >>>> 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 ;)
> > >>
> > >>>> The way I see it, we'll soon run out of HWCAP2 bits and then we'll have
> > >>>> our hand forced.
> > >>
> > >>> 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.

> > 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