From: Catalin Marinas <catalin.marinas@arm.com>
To: Mark Brown <broonie@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>, Will Deacon <will@kernel.org>,
linux-crypto@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Eric Biggers <ebiggers@google.com>
Subject: Re: [PATCH 0/3] arm64: Open code .arch_extension
Date: Wed, 22 Apr 2020 19:00:28 +0100 [thread overview]
Message-ID: <20200422180027.GH3585@gaia> (raw)
In-Reply-To: <20200325115038.GD4346@sirena.org.uk>
On Wed, Mar 25, 2020 at 11:50:38AM +0000, Mark Brown wrote:
> On Wed, Mar 25, 2020 at 12:45:11PM +0100, Ard Biesheuvel wrote:
> > I don't think this is the right fix. What is wrong with keeping these
> > .cpu and .arch directives in the .S files, and simply make
> > SYM_FUNC_START() expand to something that includes .arch_extension pac
> > or .arch_extension bti when needed? That way, we only use
> > .arch_extension when we know the assembler supports it (given that
> > .arch_extension support itself should predate BTI or PAC support in
> > GAS or Clang)
>
> Since BTI is a mandatory feature of v8.5 there is no BTI arch_extension,
> you can only enable it by moving the base architecture to v8.5. You'd
> need to use .arch and that feels likely to find us sharp edges to run
> into.
For MTE, .arch armv8-a+memtag won't work since this is only available
with armv8.5-a. My preference would be to have the highest arch version
supported by the kernel in the assembler.h file, i.e. ".arch armv8.5-a"
followed by .arch_extension in each .S file, as needed.
Forcing .S files to armv8.5 would not cause any problems with
the base armv8.0 that the kernel image support since it shouldn't change
the opcodes gas generates. The .S files would use alternatives anyway
(or simply have code not called).
The inline asm is slightly more problematic, especially with the clang
builtin assembler which goes in a single pass. But we could do something
similar to what we did with the LSE atomics and raising the base of the
inline asm to armv8.5 (or 8.6 etc., whatever we need in the future).
--
Catalin
next prev parent reply other threads:[~2020-04-22 18:00 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 11:41 [PATCH 0/3] arm64: Open code .arch_extension Mark Brown
2020-03-25 11:41 ` [PATCH 1/3] arm64: asm: Provide macro to control enabling architecture extensions Mark Brown
2020-03-25 11:41 ` [PATCH 2/3] arm64: lib: Use ARM64_EXTENSIONS() Mark Brown
2020-03-25 11:41 ` [PATCH 3/3] arm64: crypto: " Mark Brown
2020-03-25 11:45 ` [PATCH 0/3] arm64: Open code .arch_extension Ard Biesheuvel
2020-03-25 11:50 ` Mark Brown
2020-03-25 11:54 ` Ard Biesheuvel
2020-03-25 12:01 ` Mark Brown
2020-03-25 12:03 ` Mark Rutland
2020-03-25 12:24 ` Robin Murphy
2020-04-22 18:00 ` Catalin Marinas [this message]
2020-04-23 11:18 ` Mark Brown
2020-04-23 11:59 ` Catalin Marinas
2020-04-23 13:40 ` Catalin Marinas
2020-03-25 12:31 ` Mark Rutland
2020-03-25 13:26 ` Ard Biesheuvel
2020-03-25 13:30 ` Mark Brown
2020-03-25 13:27 ` Mark Brown
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=20200422180027.GH3585@gaia \
--to=catalin.marinas@arm.com \
--cc=ardb@kernel.org \
--cc=broonie@kernel.org \
--cc=ebiggers@google.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.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).