Re: [PATCH 0/3] arm64: Open code .arch_extension

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Apr 22, 2020 at 07:00:28PM +0100, Catalin Marinas wrote:
> On Wed, Mar 25, 2020 at 11:50:38AM +0000, Mark Brown wrote:

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

I think we decided that .arch_extension was too new to be used for
things like the crypto stuff where we still support older toolchains?

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

We do loose the checking that the assembler does that nobody used a
newer feature by mistake but yeah, shouldn't affect the output.

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

FWIW I did something different to this for BTI so I wasn't using the
instructions directly so I was going to abandon this series.

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux