linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
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 11:40:49 +0000	[thread overview]
Message-ID: <20200116114049.GD10277@arrakis.emea.arm.com> (raw)
In-Reply-To: <CAKv+Gu_Y3agWT1nOWHygc3An7zd2fAERcEq6Nav4geE0ahb+Xg@mail.gmail.com>

On Thu, Jan 16, 2020 at 12:10:28PM +0100, Ard Biesheuvel wrote:
> 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:
> > > > 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.

If you write the resolver yourself, it should work. I was thinking of
function multiversioning (which I thought using ifunc behind the scenes)
but I'm not sure what the aarch64 support level is (in gcc or clang).

Anyway, I'm not aware of anyone using the MRS emulation (maybe they do
and I haven't heard). I guess it doesn't help that we keep adding HWCAP
bits ;).

-- 
Catalin

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

  reply	other threads:[~2020-01-16 11:41 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-10 12:23 [PATCH v10 0/3] ARMv8.5-RNG support Mark Brown
2020-01-10 12:23 ` [PATCH v10 1/3] arm64: Implement archrandom.h for ARMv8.5-RNG Mark Brown
2020-01-14 17:44   ` Will Deacon
2020-01-15  7:40     ` Ard Biesheuvel
2020-01-15  9:16       ` Will Deacon
2020-01-15  9:24         ` Ard Biesheuvel
2020-01-15 11:07           ` Mark Brown
2020-01-15 11:16             ` Will Deacon
2020-01-15 14:26             ` Catalin Marinas
2020-01-16  0:23               ` Richard Henderson
2020-01-16 11:02                 ` Catalin Marinas
2020-01-16 11:10                   ` Ard Biesheuvel
2020-01-16 11:40                     ` Catalin Marinas [this message]
2020-01-10 12:23 ` [PATCH v10 2/3] arm64: random: Add data to pool from setup_arch() Mark Brown
2020-01-10 12:35   ` Mark Rutland
2020-01-13 19:09   ` Richard Henderson
2020-01-15  7:48   ` Ard Biesheuvel
2020-01-15  9:16     ` Will Deacon
2020-01-15  9:22       ` Ard Biesheuvel
2020-01-15 10:11         ` Mark Rutland
2020-01-15 14:01           ` Mark Brown
2020-01-15 12:07       ` Mark Brown
2020-01-15 12:42         ` Will Deacon
2020-01-15 13:36           ` Ard Biesheuvel
2020-01-15 17:04             ` Mark Brown
2020-01-16 11:33               ` Will Deacon
2020-01-15 15:40           ` Mark Brown
2020-01-10 12:23 ` [PATCH v10 3/3] arm64: Use v8.5-RNG entropy for KASLR seed Mark Brown
2020-01-10 12:35   ` Mark Rutland
2020-01-13 19:09   ` Richard Henderson

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=20200116114049.GD10277@arrakis.emea.arm.com \
    --to=catalin.marinas@arm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=mark.rutland@arm.com \
    --cc=richard.henderson@linaro.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).