* [PATCH 1/2] arm64: lib: Use .arch_extension @ 2020-03-23 19:18 Mark Brown 2020-03-23 19:18 ` [PATCH 2/2] arm64: crypto: " Mark Brown ` (2 more replies) 0 siblings, 3 replies; 9+ messages in thread From: Mark Brown @ 2020-03-23 19:18 UTC (permalink / raw) To: Catalin Marinas, Will Deacon, Eric Biggers, Ard Biesheuvel Cc: Mark Brown, linux-arm-kernel Currently when implementing optimised assembler routines using architecture extensions we override the base architecture along with enabling the new extensions, causing problems for in kernel BTI support which needs to raise the base architecture level for assembler files in order to generate BTI landing pads. We did this due to a lack of support for the .arch_extension gas feature in older versions of the clang built in assembler but since current versions of clang now have support for .arch_extension we can use that. Signed-off-by: Mark Brown <broonie@kernel.org> --- arch/arm64/lib/crc32.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S index 243e107e9896..7420dea6afc1 100644 --- a/arch/arm64/lib/crc32.S +++ b/arch/arm64/lib/crc32.S @@ -9,7 +9,7 @@ #include <asm/alternative.h> #include <asm/assembler.h> - .cpu generic+crc + .arch_extension crc .macro __crc32, c cmp x2, #16 -- 2.20.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [PATCH 2/2] arm64: crypto: Use .arch_extension 2020-03-23 19:18 [PATCH 1/2] arm64: lib: Use .arch_extension Mark Brown @ 2020-03-23 19:18 ` Mark Brown 2020-03-24 16:45 ` Catalin Marinas 2020-03-24 16:48 ` [PATCH 1/2] arm64: lib: " Catalin Marinas 2020-03-24 18:19 ` Ard Biesheuvel 2 siblings, 1 reply; 9+ messages in thread From: Mark Brown @ 2020-03-23 19:18 UTC (permalink / raw) To: Catalin Marinas, Will Deacon, Eric Biggers, Ard Biesheuvel Cc: Mark Brown, linux-arm-kernel Currently when implementing optimised assembler routines using architecture extensions we override the base architecture along with enabling the new extensions, causing problems for in kernel BTI support which needs to raise the base architecture level for assembler files in order to generate BTI landing pads. We did this due to a lack of support for the .arch_extension gas feature in older versions of the clang built in assembler but since current versions of clang now have support for .arch_extension we can use that. Signed-off-by: Mark Brown <broonie@kernel.org> --- arch/arm64/crypto/aes-ce-ccm-core.S | 2 +- arch/arm64/crypto/aes-ce-core.S | 2 +- arch/arm64/crypto/aes-ce.S | 2 +- arch/arm64/crypto/crct10dif-ce-core.S | 2 +- arch/arm64/crypto/ghash-ce-core.S | 2 +- arch/arm64/crypto/sha1-ce-core.S | 2 +- arch/arm64/crypto/sha2-ce-core.S | 2 +- 7 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/arm64/crypto/aes-ce-ccm-core.S b/arch/arm64/crypto/aes-ce-ccm-core.S index 99a028e298ed..90fde12f8253 100644 --- a/arch/arm64/crypto/aes-ce-ccm-core.S +++ b/arch/arm64/crypto/aes-ce-ccm-core.S @@ -9,7 +9,7 @@ #include <asm/assembler.h> .text - .arch armv8-a+crypto + .arch_extension crypto /* * void ce_aes_ccm_auth_data(u8 mac[], u8 const in[], u32 abytes, diff --git a/arch/arm64/crypto/aes-ce-core.S b/arch/arm64/crypto/aes-ce-core.S index e52e13eb8fdb..4dbc0052ffbe 100644 --- a/arch/arm64/crypto/aes-ce-core.S +++ b/arch/arm64/crypto/aes-ce-core.S @@ -6,7 +6,7 @@ #include <linux/linkage.h> #include <asm/assembler.h> - .arch armv8-a+crypto + .arch_extension crypto SYM_FUNC_START(__aes_ce_encrypt) sub w3, w3, #2 diff --git a/arch/arm64/crypto/aes-ce.S b/arch/arm64/crypto/aes-ce.S index 1dc5bbbfeed2..d57516308cf1 100644 --- a/arch/arm64/crypto/aes-ce.S +++ b/arch/arm64/crypto/aes-ce.S @@ -12,7 +12,7 @@ #define AES_FUNC_START(func) SYM_FUNC_START(ce_ ## func) #define AES_FUNC_END(func) SYM_FUNC_END(ce_ ## func) - .arch armv8-a+crypto + .arch_extension crypto xtsmask .req v16 cbciv .req v16 diff --git a/arch/arm64/crypto/crct10dif-ce-core.S b/arch/arm64/crypto/crct10dif-ce-core.S index 5a95c2628fbf..c6b8b387f3bd 100644 --- a/arch/arm64/crypto/crct10dif-ce-core.S +++ b/arch/arm64/crypto/crct10dif-ce-core.S @@ -66,7 +66,7 @@ #include <asm/assembler.h> .text - .cpu generic+crypto + .arch_extension crypto init_crc .req w19 buf .req x20 diff --git a/arch/arm64/crypto/ghash-ce-core.S b/arch/arm64/crypto/ghash-ce-core.S index 6b958dcdf136..65ed5690735a 100644 --- a/arch/arm64/crypto/ghash-ce-core.S +++ b/arch/arm64/crypto/ghash-ce-core.S @@ -57,7 +57,7 @@ HH34 .req v19 .text - .arch armv8-a+crypto + .arch_extension crypto .macro __pmull_p64, rd, rn, rm pmull \rd\().1q, \rn\().1d, \rm\().1d diff --git a/arch/arm64/crypto/sha1-ce-core.S b/arch/arm64/crypto/sha1-ce-core.S index 92d0d2753e81..8cfd30c5f605 100644 --- a/arch/arm64/crypto/sha1-ce-core.S +++ b/arch/arm64/crypto/sha1-ce-core.S @@ -9,7 +9,7 @@ #include <asm/assembler.h> .text - .arch armv8-a+crypto + .arch_extension crypto k0 .req v0 k1 .req v1 diff --git a/arch/arm64/crypto/sha2-ce-core.S b/arch/arm64/crypto/sha2-ce-core.S index 3f9d0f326987..a7ea4fc8d570 100644 --- a/arch/arm64/crypto/sha2-ce-core.S +++ b/arch/arm64/crypto/sha2-ce-core.S @@ -9,7 +9,7 @@ #include <asm/assembler.h> .text - .arch armv8-a+crypto + .arch_extension crypto dga .req q20 dgav .req v20 -- 2.20.1 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [PATCH 2/2] arm64: crypto: Use .arch_extension 2020-03-23 19:18 ` [PATCH 2/2] arm64: crypto: " Mark Brown @ 2020-03-24 16:45 ` Catalin Marinas 0 siblings, 0 replies; 9+ messages in thread From: Catalin Marinas @ 2020-03-24 16:45 UTC (permalink / raw) To: Mark Brown; +Cc: Will Deacon, Ard Biesheuvel, linux-arm-kernel, Eric Biggers On Mon, Mar 23, 2020 at 07:18:07PM +0000, Mark Brown wrote: > Currently when implementing optimised assembler routines using > architecture extensions we override the base architecture along with > enabling the new extensions, causing problems for in kernel BTI support > which needs to raise the base architecture level for assembler files in > order to generate BTI landing pads. We did this due to a lack of > support for the .arch_extension gas feature in older versions of the > clang built in assembler but since current versions of clang now have > support for .arch_extension we can use that. > > Signed-off-by: Mark Brown <broonie@kernel.org> It make sense (I got burnt by this with the MTE patches). Acked-by: Catalin Marinas <catalin.marinas@arm.com> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] arm64: lib: Use .arch_extension 2020-03-23 19:18 [PATCH 1/2] arm64: lib: Use .arch_extension Mark Brown 2020-03-23 19:18 ` [PATCH 2/2] arm64: crypto: " Mark Brown @ 2020-03-24 16:48 ` Catalin Marinas 2020-03-24 18:19 ` Ard Biesheuvel 2 siblings, 0 replies; 9+ messages in thread From: Catalin Marinas @ 2020-03-24 16:48 UTC (permalink / raw) To: Mark Brown; +Cc: Will Deacon, Ard Biesheuvel, linux-arm-kernel, Eric Biggers On Mon, Mar 23, 2020 at 07:18:06PM +0000, Mark Brown wrote: > Currently when implementing optimised assembler routines using > architecture extensions we override the base architecture along with > enabling the new extensions, causing problems for in kernel BTI support > which needs to raise the base architecture level for assembler files in > order to generate BTI landing pads. We did this due to a lack of > support for the .arch_extension gas feature in older versions of the > clang built in assembler but since current versions of clang now have > support for .arch_extension we can use that. > > Signed-off-by: Mark Brown <broonie@kernel.org> I'll queue this through the arm64 tree. Thanks. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] arm64: lib: Use .arch_extension 2020-03-23 19:18 [PATCH 1/2] arm64: lib: Use .arch_extension Mark Brown 2020-03-23 19:18 ` [PATCH 2/2] arm64: crypto: " Mark Brown 2020-03-24 16:48 ` [PATCH 1/2] arm64: lib: " Catalin Marinas @ 2020-03-24 18:19 ` Ard Biesheuvel 2020-03-24 18:58 ` Mark Brown 2 siblings, 1 reply; 9+ messages in thread From: Ard Biesheuvel @ 2020-03-24 18:19 UTC (permalink / raw) To: Mark Brown; +Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, Eric Biggers On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote: > > Currently when implementing optimised assembler routines using > architecture extensions we override the base architecture along with > enabling the new extensions, causing problems for in kernel BTI support > which needs to raise the base architecture level for assembler files in > order to generate BTI landing pads. We did this due to a lack of > support for the .arch_extension gas feature in older versions of the > clang built in assembler but since current versions of clang now have > support for .arch_extension we can use that. This is not 100% accurate. Support for .arch_extension was added to GAS/aarch64 much later, so we should at least double check that it works on the oldest binutils that we do support. > > Signed-off-by: Mark Brown <broonie@kernel.org> > --- > arch/arm64/lib/crc32.S | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/arch/arm64/lib/crc32.S b/arch/arm64/lib/crc32.S > index 243e107e9896..7420dea6afc1 100644 > --- a/arch/arm64/lib/crc32.S > +++ b/arch/arm64/lib/crc32.S > @@ -9,7 +9,7 @@ > #include <asm/alternative.h> > #include <asm/assembler.h> > > - .cpu generic+crc > + .arch_extension crc > > .macro __crc32, c > cmp x2, #16 > -- > 2.20.1 > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] arm64: lib: Use .arch_extension 2020-03-24 18:19 ` Ard Biesheuvel @ 2020-03-24 18:58 ` Mark Brown 2020-03-24 22:17 ` Ard Biesheuvel 0 siblings, 1 reply; 9+ messages in thread From: Mark Brown @ 2020-03-24 18:58 UTC (permalink / raw) To: Ard Biesheuvel Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, Eric Biggers [-- Attachment #1.1: Type: text/plain, Size: 1333 bytes --] On Tue, Mar 24, 2020 at 07:19:17PM +0100, Ard Biesheuvel wrote: > On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote: > > order to generate BTI landing pads. We did this due to a lack of > > support for the .arch_extension gas feature in older versions of the > > clang built in assembler but since current versions of clang now have > > support for .arch_extension we can use that. > This is not 100% accurate. Support for .arch_extension was added to > GAS/aarch64 much later, so we should at least double check that it > works on the oldest binutils that we do support. Ah, OK - the information I figured out from history was misleading sorry. We've already got quite a lot of usages of .arch_extension in the kernel for arm and a couple for arm64 (one in TF and another for LSE). It looks like the feature was added in binutils 2.26 which is newer than the current advertised minimum binutils version of 2.21 but dates from 2016 (the code was added in 2014 and looks like it might've appeared in downstream releases earlier) so is pretty old in arm64 terms. If that's not OK I've got an open coded version for BTI that does this with macros but it's obviously not as nice. I do wish the binutils docs included information on when features were added, it'd make life easier :/ [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] arm64: lib: Use .arch_extension 2020-03-24 18:58 ` Mark Brown @ 2020-03-24 22:17 ` Ard Biesheuvel 2020-03-25 11:05 ` Catalin Marinas 0 siblings, 1 reply; 9+ messages in thread From: Ard Biesheuvel @ 2020-03-24 22:17 UTC (permalink / raw) To: Mark Brown; +Cc: Catalin Marinas, Will Deacon, linux-arm-kernel, Eric Biggers On Tue, 24 Mar 2020 at 19:58, Mark Brown <broonie@kernel.org> wrote: > > On Tue, Mar 24, 2020 at 07:19:17PM +0100, Ard Biesheuvel wrote: > > On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote: > > > > order to generate BTI landing pads. We did this due to a lack of > > > support for the .arch_extension gas feature in older versions of the > > > clang built in assembler but since current versions of clang now have > > > support for .arch_extension we can use that. > > > This is not 100% accurate. Support for .arch_extension was added to > > GAS/aarch64 much later, so we should at least double check that it > > works on the oldest binutils that we do support. > > Ah, OK - the information I figured out from history was misleading > sorry. > > We've already got quite a lot of usages of .arch_extension in the kernel > for arm and a couple for arm64 (one in TF and another for LSE). ARM had support for this way before it was added to AArch64 as well. In the LSE case, it doesn't matter since LSE itself was not implemented by the assembler before that. For other things, we should really avoid .arch_extension as long as we still support binutils < 2.26 > It > looks like the feature was added in binutils 2.26 which is newer than > the current advertised minimum binutils version of 2.21 but dates from > 2016 (the code was added in 2014 and looks like it might've appeared in > downstream releases earlier) so is pretty old in arm64 terms. If that's > not OK I've got an open coded version for BTI that does this with macros > but it's obviously not as nice. > > I do wish the binutils docs included information on when features were > added, it'd make life easier :/ _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] arm64: lib: Use .arch_extension 2020-03-24 22:17 ` Ard Biesheuvel @ 2020-03-25 11:05 ` Catalin Marinas 2020-03-25 11:07 ` Mark Brown 0 siblings, 1 reply; 9+ messages in thread From: Catalin Marinas @ 2020-03-25 11:05 UTC (permalink / raw) To: Ard Biesheuvel; +Cc: Mark Brown, Will Deacon, linux-arm-kernel, Eric Biggers On Tue, Mar 24, 2020 at 11:17:05PM +0100, Ard Biesheuvel wrote: > On Tue, 24 Mar 2020 at 19:58, Mark Brown <broonie@kernel.org> wrote: > > > > On Tue, Mar 24, 2020 at 07:19:17PM +0100, Ard Biesheuvel wrote: > > > On Mon, 23 Mar 2020 at 20:18, Mark Brown <broonie@kernel.org> wrote: > > > > > > order to generate BTI landing pads. We did this due to a lack of > > > > support for the .arch_extension gas feature in older versions of the > > > > clang built in assembler but since current versions of clang now have > > > > support for .arch_extension we can use that. > > > > > This is not 100% accurate. Support for .arch_extension was added to > > > GAS/aarch64 much later, so we should at least double check that it > > > works on the oldest binutils that we do support. > > > > Ah, OK - the information I figured out from history was misleading > > sorry. > > > > We've already got quite a lot of usages of .arch_extension in the kernel > > for arm and a couple for arm64 (one in TF and another for LSE). > > ARM had support for this way before it was added to AArch64 as well. > In the LSE case, it doesn't matter since LSE itself was not > implemented by the assembler before that. For other things, we should > really avoid .arch_extension as long as we still support binutils < > 2.26 Good point. So we can add .arch_extension for new features which are already dependent on newer gas options. I'll drop this patch for now but we should try to find a solution because of the overriding effect of .arch. In self-contained .S files (like crypto) that's not an issue but once we start adding more architecture feature in a single file, things will get more complicated. -- Catalin _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH 1/2] arm64: lib: Use .arch_extension 2020-03-25 11:05 ` Catalin Marinas @ 2020-03-25 11:07 ` Mark Brown 0 siblings, 0 replies; 9+ messages in thread From: Mark Brown @ 2020-03-25 11:07 UTC (permalink / raw) To: Catalin Marinas Cc: Will Deacon, Ard Biesheuvel, linux-arm-kernel, Eric Biggers [-- Attachment #1.1: Type: text/plain, Size: 419 bytes --] On Wed, Mar 25, 2020 at 11:05:04AM +0000, Catalin Marinas wrote: > I'll drop this patch for now but we should try to find a solution > because of the overriding effect of .arch. In self-contained .S files > (like crypto) that's not an issue but once we start adding more > architecture feature in a single file, things will get more complicated. It's fine I think, you can open code .arch_extension in the assembler. [-- Attachment #1.2: signature.asc --] [-- Type: application/pgp-signature, Size: 488 bytes --] [-- Attachment #2: Type: text/plain, Size: 176 bytes --] _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-03-25 11:07 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-23 19:18 [PATCH 1/2] arm64: lib: Use .arch_extension Mark Brown 2020-03-23 19:18 ` [PATCH 2/2] arm64: crypto: " Mark Brown 2020-03-24 16:45 ` Catalin Marinas 2020-03-24 16:48 ` [PATCH 1/2] arm64: lib: " Catalin Marinas 2020-03-24 18:19 ` Ard Biesheuvel 2020-03-24 18:58 ` Mark Brown 2020-03-24 22:17 ` Ard Biesheuvel 2020-03-25 11:05 ` Catalin Marinas 2020-03-25 11:07 ` Mark Brown
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.