[PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Eric Biggers]

The new library APIs for AES encryption modes were wired up to the
traditional crypto API via crypto/aes.c.  However, for now the kernel is
still in a transitional state where various architectures still have
architecture-optimized implementations of AES modes in arch/*/crypto/,
wired up to the traditional crypto API only.  Because of that, the
crypto/aes.c algorithms were given a cra_priority of only 110 to prevent
them from overriding arch/*/crypto/ in the traditional crypto API.

However, because of how the traditional crypto API works, the
cra_priority trick doesn't work in cases where the relevant algorithm
isn't directly implemented by arch/*/crypto/ but rather is provided by a
template instance using other code in arch/*/crypto/.

For example, x86 doesn't have its own "ccm(aes)" but rather relies on
the "ccm" template constructing it from the x86-optimized "ctr(aes)".
The existence of the library-based "ccm(aes)" prevents that, even though
its priority is lower than what the template would produce.

Thus, "ccm(aes)" ends up using the slower single-block AES code.

Therefore, skip wiring up the relevant library-based code to the
traditional crypto API on architectures where this problem can occur, as
determined by what exists in arch/*/crypto/ for each architecture.

This is ugly, but it's also temporary: these conditions will go away as
architecture-optimized implementations of AES modes are migrated into
the library.  But until then, we need to prevent performance regressions
by ensuring that the optimized code continues to be used.

Fixes: 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using library")
Fixes: 8ca62072faa1 ("crypto: aes - Add GCM support using library")
Fixes: f70ad727d1d6 ("crypto: aes - Add CCM support using library")
Fixes: 94efa0c9fb36 ("crypto: aes - Add XTS support using library")
Closes: https://github.com/sparclinux/issues/issues/106
Signed-off-by: Eric Biggers <ebiggers@kernel.org>
---

This patch is intended to taken through libcrypto-fixes

v3: Also suppress xts(aes) on SPARC, and improved comments
v2: Fixed PowerPC config option, and resent as standalone patch

 crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 47 insertions(+), 4 deletions(-)

diff --git a/crypto/aes.c b/crypto/aes.c
index 94791f481e98..51eee78396ea 100644
--- a/crypto/aes.c
+++ b/crypto/aes.c
@@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = {
 		.decrypt = crypto_aes_cbc_decrypt,
 	},
 #endif
-#if IS_ENABLED(CONFIG_CRYPTO_CTS)
+	/*
+	 * Don't register library-based "cts(cbc(aes))" on architectures where
+	 * it might block a "better" implementation from being instantiated via
+	 * the "cts" template.  These exclusions are temporary and will go away
+	 * as the arch-optimized AES code is migrated into the library.
+	 */
+#if IS_ENABLED(CONFIG_CRYPTO_CTS) && \
+	!(IS_ENABLED(CONFIG_ARM) || \
+	  IS_ENABLED(CONFIG_ARM64) || \
+	  IS_ENABLED(CONFIG_PPC) || \
+	  IS_ENABLED(CONFIG_S390) || \
+	  IS_ENABLED(CONFIG_SPARC))
 	{
 		.base.cra_name = "cts(cbc(aes))",
 		.base.cra_driver_name = "cts-cbc-aes-lib",
@@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = {
 		.decrypt = crypto_aes_xctr_crypt,
 	},
 #endif
-#if IS_ENABLED(CONFIG_CRYPTO_XTS)
+	/*
+	 * Don't register library-based "xts(aes)" on architectures where it
+	 * might block a "better" implementation from being instantiated via the
+	 * "xts" template.  This exclusion is temporary and will go away when
+	 * the library AES-XTS is optimized for SPARC.
+	 */
+#if IS_ENABLED(CONFIG_CRYPTO_XTS) && !IS_ENABLED(CONFIG_SPARC)
 	{
 		.base.cra_name = "xts(aes)",
 		.base.cra_driver_name = "xts-aes-lib",
@@ -980,7 +997,20 @@ static __maybe_unused int crypto_aes_ccm_decrypt(struct aead_request *req)
 }
 
 static struct aead_alg aead_algs[] = {
-#if IS_ENABLED(CONFIG_CRYPTO_GCM)
+	/*
+	 * Don't register library-based "gcm(aes)" and "rfc4106(gcm(aes))" on
+	 * architectures where they might block a "better" implementation from
+	 * being instantiated via the "gcm" and "rfc4106" templates.  These
+	 * exclusions are temporary and will go away as the arch-optimized AES
+	 * code is migrated into the library.
+	 */
+#if IS_ENABLED(CONFIG_CRYPTO_GCM) && \
+	!(IS_ENABLED(CONFIG_ARM) || \
+	  IS_ENABLED(CONFIG_ARM64) || \
+	  IS_ENABLED(CONFIG_PPC) || \
+	  IS_ENABLED(CONFIG_RISCV) || \
+	  IS_ENABLED(CONFIG_S390) || \
+	  IS_ENABLED(CONFIG_SPARC))
 	{
 		.base.cra_name = "gcm(aes)",
 		.base.cra_driver_name = "gcm-aes-lib",
@@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = {
 		.chunksize = AES_BLOCK_SIZE,
 	},
 #endif /* CONFIG_CRYPTO_GCM */
-#if IS_ENABLED(CONFIG_CRYPTO_CCM)
+	/*
+	 * Don't register library-based "ccm(aes)" on architectures where it
+	 * might block a "better" implementation from being instantiated via the
+	 * "ccm" template.  These exclusions are temporary and will go away as
+	 * the arch-optimized AES code is migrated into the library.
+	 */
+#if IS_ENABLED(CONFIG_CRYPTO_CCM) && \
+	!(IS_ENABLED(CONFIG_ARM) || \
+	  IS_ENABLED(CONFIG_ARM64) || \
+	  IS_ENABLED(CONFIG_PPC) || \
+	  IS_ENABLED(CONFIG_RISCV) || \
+	  IS_ENABLED(CONFIG_S390) || \
+	  IS_ENABLED(CONFIG_SPARC) || \
+	  IS_ENABLED(CONFIG_X86))
 	{
 		.base.cra_name = "ccm(aes)",
 		.base.cra_driver_name = "ccm-aes-lib",

base-commit: 93f51579e7df248780214094418f205253383cc5
-- 
2.55.0

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Ard Biesheuvel]

On Wed, 30 Sep 2026, at 00:27, Eric Biggers wrote:
> The new library APIs for AES encryption modes were wired up to the
> traditional crypto API via crypto/aes.c.  However, for now the kernel is
> still in a transitional state where various architectures still have
> architecture-optimized implementations of AES modes in arch/*/crypto/,
> wired up to the traditional crypto API only.  Because of that, the
> crypto/aes.c algorithms were given a cra_priority of only 110 to prevent
> them from overriding arch/*/crypto/ in the traditional crypto API.
>
> However, because of how the traditional crypto API works, the
> cra_priority trick doesn't work in cases where the relevant algorithm
> isn't directly implemented by arch/*/crypto/ but rather is provided by a
> template instance using other code in arch/*/crypto/.
>
> For example, x86 doesn't have its own "ccm(aes)" but rather relies on
> the "ccm" template constructing it from the x86-optimized "ctr(aes)".
> The existence of the library-based "ccm(aes)" prevents that, even though
> its priority is lower than what the template would produce.
>
> Thus, "ccm(aes)" ends up using the slower single-block AES code.
>
> Therefore, skip wiring up the relevant library-based code to the
> traditional crypto API on architectures where this problem can occur, as
> determined by what exists in arch/*/crypto/ for each architecture.
>
> This is ugly, but it's also temporary: these conditions will go away as
> architecture-optimized implementations of AES modes are migrated into
> the library.  But until then, we need to prevent performance regressions
> by ensuring that the optimized code continues to be used.
>
> Fixes: 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using library")
> Fixes: 8ca62072faa1 ("crypto: aes - Add GCM support using library")
> Fixes: f70ad727d1d6 ("crypto: aes - Add CCM support using library")
> Fixes: 94efa0c9fb36 ("crypto: aes - Add XTS support using library")
> Closes: https://github.com/sparclinux/issues/issues/106
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
>
> This patch is intended to taken through libcrypto-fixes
>
> v3: Also suppress xts(aes) on SPARC, and improved comments
> v2: Fixed PowerPC config option, and resent as standalone patch
>

Acked-by: Ard Biesheuvel <ardb@kernel.org>


>  crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 47 insertions(+), 4 deletions(-)
>
> diff --git a/crypto/aes.c b/crypto/aes.c
> index 94791f481e98..51eee78396ea 100644
> --- a/crypto/aes.c
> +++ b/crypto/aes.c
> @@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = {
>  		.decrypt = crypto_aes_cbc_decrypt,
>  	},
>  #endif
> -#if IS_ENABLED(CONFIG_CRYPTO_CTS)
> +	/*
> +	 * Don't register library-based "cts(cbc(aes))" on architectures where
> +	 * it might block a "better" implementation from being instantiated 
> via
> +	 * the "cts" template.  These exclusions are temporary and will go 
> away
> +	 * as the arch-optimized AES code is migrated into the library.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_CTS) && \
> +	!(IS_ENABLED(CONFIG_ARM) || \
> +	  IS_ENABLED(CONFIG_ARM64) || \
> +	  IS_ENABLED(CONFIG_PPC) || \
> +	  IS_ENABLED(CONFIG_S390) || \
> +	  IS_ENABLED(CONFIG_SPARC))
>  	{
>  		.base.cra_name = "cts(cbc(aes))",
>  		.base.cra_driver_name = "cts-cbc-aes-lib",
> @@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = {
>  		.decrypt = crypto_aes_xctr_crypt,
>  	},
>  #endif
> -#if IS_ENABLED(CONFIG_CRYPTO_XTS)
> +	/*
> +	 * Don't register library-based "xts(aes)" on architectures where it
> +	 * might block a "better" implementation from being instantiated via 
> the
> +	 * "xts" template.  This exclusion is temporary and will go away when
> +	 * the library AES-XTS is optimized for SPARC.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_XTS) && !IS_ENABLED(CONFIG_SPARC)
>  	{
>  		.base.cra_name = "xts(aes)",
>  		.base.cra_driver_name = "xts-aes-lib",
> @@ -980,7 +997,20 @@ static __maybe_unused int 
> crypto_aes_ccm_decrypt(struct aead_request *req)
>  }
> 
>  static struct aead_alg aead_algs[] = {
> -#if IS_ENABLED(CONFIG_CRYPTO_GCM)
> +	/*
> +	 * Don't register library-based "gcm(aes)" and "rfc4106(gcm(aes))" on
> +	 * architectures where they might block a "better" implementation from
> +	 * being instantiated via the "gcm" and "rfc4106" templates.  These
> +	 * exclusions are temporary and will go away as the arch-optimized AES
> +	 * code is migrated into the library.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_GCM) && \
> +	!(IS_ENABLED(CONFIG_ARM) || \
> +	  IS_ENABLED(CONFIG_ARM64) || \
> +	  IS_ENABLED(CONFIG_PPC) || \
> +	  IS_ENABLED(CONFIG_RISCV) || \
> +	  IS_ENABLED(CONFIG_S390) || \
> +	  IS_ENABLED(CONFIG_SPARC))
>  	{
>  		.base.cra_name = "gcm(aes)",
>  		.base.cra_driver_name = "gcm-aes-lib",
> @@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = {
>  		.chunksize = AES_BLOCK_SIZE,
>  	},
>  #endif /* CONFIG_CRYPTO_GCM */
> -#if IS_ENABLED(CONFIG_CRYPTO_CCM)
> +	/*
> +	 * Don't register library-based "ccm(aes)" on architectures where it
> +	 * might block a "better" implementation from being instantiated via the
> +	 * "ccm" template.  These exclusions are temporary and will go away as
> +	 * the arch-optimized AES code is migrated into the library.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_CCM) && \
> +	!(IS_ENABLED(CONFIG_ARM) || \
> +	  IS_ENABLED(CONFIG_ARM64) || \
> +	  IS_ENABLED(CONFIG_PPC) || \
> +	  IS_ENABLED(CONFIG_RISCV) || \
> +	  IS_ENABLED(CONFIG_S390) || \
> +	  IS_ENABLED(CONFIG_SPARC) || \
> +	  IS_ENABLED(CONFIG_X86))
>  	{
>  		.base.cra_name = "ccm(aes)",
>  		.base.cra_driver_name = "ccm-aes-lib",
>
> base-commit: 93f51579e7df248780214094418f205253383cc5
> -- 
> 2.55.0

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Stian Halseth]

[-- Attachment #1: Type: text/plain, Size: 6215 bytes --]


On Tue, 2026-09-29 at 15:27 -0700, Eric Biggers wrote:
> The new library APIs for AES encryption modes were wired up to the
> traditional crypto API via crypto/aes.c.  However, for now the kernel
> is
> still in a transitional state where various architectures still have
> architecture-optimized implementations of AES modes in
> arch/*/crypto/,
> wired up to the traditional crypto API only.  Because of that, the
> crypto/aes.c algorithms were given a cra_priority of only 110 to
> prevent
> them from overriding arch/*/crypto/ in the traditional crypto API.
> 
> However, because of how the traditional crypto API works, the
> cra_priority trick doesn't work in cases where the relevant algorithm
> isn't directly implemented by arch/*/crypto/ but rather is provided
> by a
> template instance using other code in arch/*/crypto/.
> 
> For example, x86 doesn't have its own "ccm(aes)" but rather relies on
> the "ccm" template constructing it from the x86-optimized "ctr(aes)".
> The existence of the library-based "ccm(aes)" prevents that, even
> though
> its priority is lower than what the template would produce.
> 
> Thus, "ccm(aes)" ends up using the slower single-block AES code.
> 
> Therefore, skip wiring up the relevant library-based code to the
> traditional crypto API on architectures where this problem can occur,
> as
> determined by what exists in arch/*/crypto/ for each architecture.
> 
> This is ugly, but it's also temporary: these conditions will go away
> as
> architecture-optimized implementations of AES modes are migrated into
> the library.  But until then, we need to prevent performance
> regressions
> by ensuring that the optimized code continues to be used.
> 
> Fixes: 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using
> library")
> Fixes: 8ca62072faa1 ("crypto: aes - Add GCM support using library")
> Fixes: f70ad727d1d6 ("crypto: aes - Add CCM support using library")
> Fixes: 94efa0c9fb36 ("crypto: aes - Add XTS support using library")
> Closes: https://github.com/sparclinux/issues/issues/106
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> 
> This patch is intended to taken through libcrypto-fixes
> 
> v3: Also suppress xts(aes) on SPARC, and improved comments
> v2: Fixed PowerPC config option, and resent as standalone patch
> 
> 
Tested on a SPARC T7-1 (M7) on top of v7.3-rc5. xts(aes) resolves to
xts(ecb-aes-sparc64) again. cryptsetup benchmark aes-xts goes from
152/147 MiB/s back to 429/404 (AES-128/AES-256), the 7.2 figures.
CRYPTO_SELFTESTS_FULL passes and XTS matches OpenSSL.

Tested-by: Stian Halseth stian@itx.no
>  crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++---
> -
>  1 file changed, 47 insertions(+), 4 deletions(-)
> 
> diff --git a/crypto/aes.c b/crypto/aes.c
> index 94791f481e98..51eee78396ea 100644
> --- a/crypto/aes.c
> +++ b/crypto/aes.c
> @@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = {
>  		.decrypt = crypto_aes_cbc_decrypt,
>  	},
>  #endif
> -#if IS_ENABLED(CONFIG_CRYPTO_CTS)
> +	/*
> +	 * Don't register library-based "cts(cbc(aes))" on
> architectures where
> +	 * it might block a "better" implementation from being
> instantiated via
> +	 * the "cts" template.  These exclusions are temporary and
> will go away
> +	 * as the arch-optimized AES code is migrated into the
> library.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_CTS) && \
> +	!(IS_ENABLED(CONFIG_ARM) || \
> +	  IS_ENABLED(CONFIG_ARM64) || \
> +	  IS_ENABLED(CONFIG_PPC) || \
> +	  IS_ENABLED(CONFIG_S390) || \
> +	  IS_ENABLED(CONFIG_SPARC))
>  	{
>  		.base.cra_name = "cts(cbc(aes))",
>  		.base.cra_driver_name = "cts-cbc-aes-lib",
> @@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = {
>  		.decrypt = crypto_aes_xctr_crypt,
>  	},
>  #endif
> -#if IS_ENABLED(CONFIG_CRYPTO_XTS)
> +	/*
> +	 * Don't register library-based "xts(aes)" on architectures
> where it
> +	 * might block a "better" implementation from being
> instantiated via the
> +	 * "xts" template.  This exclusion is temporary and will go
> away when
> +	 * the library AES-XTS is optimized for SPARC.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_XTS) && !IS_ENABLED(CONFIG_SPARC)
>  	{
>  		.base.cra_name = "xts(aes)",
>  		.base.cra_driver_name = "xts-aes-lib",
> @@ -980,7 +997,20 @@ static __maybe_unused int
> crypto_aes_ccm_decrypt(struct aead_request *req)
>  }
>  
>  static struct aead_alg aead_algs[] = {
> -#if IS_ENABLED(CONFIG_CRYPTO_GCM)
> +	/*
> +	 * Don't register library-based "gcm(aes)" and
> "rfc4106(gcm(aes))" on
> +	 * architectures where they might block a "better"
> implementation from
> +	 * being instantiated via the "gcm" and "rfc4106"
> templates.  These
> +	 * exclusions are temporary and will go away as the arch-
> optimized AES
> +	 * code is migrated into the library.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_GCM) && \
> +	!(IS_ENABLED(CONFIG_ARM) || \
> +	  IS_ENABLED(CONFIG_ARM64) || \
> +	  IS_ENABLED(CONFIG_PPC) || \
> +	  IS_ENABLED(CONFIG_RISCV) || \
> +	  IS_ENABLED(CONFIG_S390) || \
> +	  IS_ENABLED(CONFIG_SPARC))
>  	{
>  		.base.cra_name = "gcm(aes)",
>  		.base.cra_driver_name = "gcm-aes-lib",
> @@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = {
>  		.chunksize = AES_BLOCK_SIZE,
>  	},
>  #endif /* CONFIG_CRYPTO_GCM */
> -#if IS_ENABLED(CONFIG_CRYPTO_CCM)
> +	/*
> +	 * Don't register library-based "ccm(aes)" on architectures
> where it
> +	 * might block a "better" implementation from being
> instantiated via the
> +	 * "ccm" template.  These exclusions are temporary and will
> go away as
> +	 * the arch-optimized AES code is migrated into the library.
> +	 */
> +#if IS_ENABLED(CONFIG_CRYPTO_CCM) && \
> +	!(IS_ENABLED(CONFIG_ARM) || \
> +	  IS_ENABLED(CONFIG_ARM64) || \
> +	  IS_ENABLED(CONFIG_PPC) || \
> +	  IS_ENABLED(CONFIG_RISCV) || \
> +	  IS_ENABLED(CONFIG_S390) || \
> +	  IS_ENABLED(CONFIG_SPARC) || \
> +	  IS_ENABLED(CONFIG_X86))
>  	{
>  		.base.cra_name = "ccm(aes)",
>  		.base.cra_driver_name = "ccm-aes-lib",
> 
> base-commit: 93f51579e7df248780214094418f205253383cc5

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[John Paul Adrian Glaubitz]

Hi Stian,

On Wed, 2026-09-30 at 09:32 +0200, Stian Halseth wrote:
> On Tue, 2026-09-29 at 15:27 -0700, Eric Biggers wrote:
> > The new library APIs for AES encryption modes were wired up to the
> > traditional crypto API via crypto/aes.c.  However, for now the kernel
> > is
> > still in a transitional state where various architectures still have
> > architecture-optimized implementations of AES modes in
> > arch/*/crypto/,
> > wired up to the traditional crypto API only.  Because of that, the
> > crypto/aes.c algorithms were given a cra_priority of only 110 to
> > prevent
> > them from overriding arch/*/crypto/ in the traditional crypto API.
> > 
> > However, because of how the traditional crypto API works, the
> > cra_priority trick doesn't work in cases where the relevant algorithm
> > isn't directly implemented by arch/*/crypto/ but rather is provided
> > by a
> > template instance using other code in arch/*/crypto/.
> > 
> > For example, x86 doesn't have its own "ccm(aes)" but rather relies on
> > the "ccm" template constructing it from the x86-optimized "ctr(aes)".
> > The existence of the library-based "ccm(aes)" prevents that, even
> > though
> > its priority is lower than what the template would produce.
> > 
> > Thus, "ccm(aes)" ends up using the slower single-block AES code.
> > 
> > Therefore, skip wiring up the relevant library-based code to the
> > traditional crypto API on architectures where this problem can occur,
> > as
> > determined by what exists in arch/*/crypto/ for each architecture.
> > 
> > This is ugly, but it's also temporary: these conditions will go away
> > as
> > architecture-optimized implementations of AES modes are migrated into
> > the library.  But until then, we need to prevent performance
> > regressions
> > by ensuring that the optimized code continues to be used.
> > 
> > Fixes: 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using
> > library")
> > Fixes: 8ca62072faa1 ("crypto: aes - Add GCM support using library")
> > Fixes: f70ad727d1d6 ("crypto: aes - Add CCM support using library")
> > Fixes: 94efa0c9fb36 ("crypto: aes - Add XTS support using library")
> > Closes: https://github.com/sparclinux/issues/issues/106
> > Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> > ---
> > 
> > This patch is intended to taken through libcrypto-fixes
> > 
> > v3: Also suppress xts(aes) on SPARC, and improved comments
> > v2: Fixed PowerPC config option, and resent as standalone patch
> > 
> > 
> Tested on a SPARC T7-1 (M7) on top of v7.3-rc5. xts(aes) resolves to
> xts(ecb-aes-sparc64) again. cryptsetup benchmark aes-xts goes from
> 152/147 MiB/s back to 429/404 (AES-128/AES-256), the 7.2 figures.
> CRYPTO_SELFTESTS_FULL passes and XTS matches OpenSSL.
> 
> Tested-by: Stian Halseth stian@itx.no

Very nice! Do you know which SPARC CPUs support these instructions?

Adrian

> >  crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++---
> > -
> >  1 file changed, 47 insertions(+), 4 deletions(-)
> > 
> > diff --git a/crypto/aes.c b/crypto/aes.c
> > index 94791f481e98..51eee78396ea 100644
> > --- a/crypto/aes.c
> > +++ b/crypto/aes.c
> > @@ -637,7 +637,18 @@ static struct skcipher_alg skcipher_algs[] = {
> >  		.decrypt = crypto_aes_cbc_decrypt,
> >  	},
> >  #endif
> > -#if IS_ENABLED(CONFIG_CRYPTO_CTS)
> > +	/*
> > +	 * Don't register library-based "cts(cbc(aes))" on
> > architectures where
> > +	 * it might block a "better" implementation from being
> > instantiated via
> > +	 * the "cts" template.  These exclusions are temporary and
> > will go away
> > +	 * as the arch-optimized AES code is migrated into the
> > library.
> > +	 */
> > +#if IS_ENABLED(CONFIG_CRYPTO_CTS) && \
> > +	!(IS_ENABLED(CONFIG_ARM) || \
> > +	  IS_ENABLED(CONFIG_ARM64) || \
> > +	  IS_ENABLED(CONFIG_PPC) || \
> > +	  IS_ENABLED(CONFIG_S390) || \
> > +	  IS_ENABLED(CONFIG_SPARC))
> >  	{
> >  		.base.cra_name = "cts(cbc(aes))",
> >  		.base.cra_driver_name = "cts-cbc-aes-lib",
> > @@ -687,7 +698,13 @@ static struct skcipher_alg skcipher_algs[] = {
> >  		.decrypt = crypto_aes_xctr_crypt,
> >  	},
> >  #endif
> > -#if IS_ENABLED(CONFIG_CRYPTO_XTS)
> > +	/*
> > +	 * Don't register library-based "xts(aes)" on architectures
> > where it
> > +	 * might block a "better" implementation from being
> > instantiated via the
> > +	 * "xts" template.  This exclusion is temporary and will go
> > away when
> > +	 * the library AES-XTS is optimized for SPARC.
> > +	 */
> > +#if IS_ENABLED(CONFIG_CRYPTO_XTS) && !IS_ENABLED(CONFIG_SPARC)
> >  	{
> >  		.base.cra_name = "xts(aes)",
> >  		.base.cra_driver_name = "xts-aes-lib",
> > @@ -980,7 +997,20 @@ static __maybe_unused int
> > crypto_aes_ccm_decrypt(struct aead_request *req)
> >  }
> >  
> >  static struct aead_alg aead_algs[] = {
> > -#if IS_ENABLED(CONFIG_CRYPTO_GCM)
> > +	/*
> > +	 * Don't register library-based "gcm(aes)" and
> > "rfc4106(gcm(aes))" on
> > +	 * architectures where they might block a "better"
> > implementation from
> > +	 * being instantiated via the "gcm" and "rfc4106"
> > templates.  These
> > +	 * exclusions are temporary and will go away as the arch-
> > optimized AES
> > +	 * code is migrated into the library.
> > +	 */
> > +#if IS_ENABLED(CONFIG_CRYPTO_GCM) && \
> > +	!(IS_ENABLED(CONFIG_ARM) || \
> > +	  IS_ENABLED(CONFIG_ARM64) || \
> > +	  IS_ENABLED(CONFIG_PPC) || \
> > +	  IS_ENABLED(CONFIG_RISCV) || \
> > +	  IS_ENABLED(CONFIG_S390) || \
> > +	  IS_ENABLED(CONFIG_SPARC))
> >  	{
> >  		.base.cra_name = "gcm(aes)",
> >  		.base.cra_driver_name = "gcm-aes-lib",
> > @@ -1012,7 +1042,20 @@ static struct aead_alg aead_algs[] = {
> >  		.chunksize = AES_BLOCK_SIZE,
> >  	},
> >  #endif /* CONFIG_CRYPTO_GCM */
> > -#if IS_ENABLED(CONFIG_CRYPTO_CCM)
> > +	/*
> > +	 * Don't register library-based "ccm(aes)" on architectures
> > where it
> > +	 * might block a "better" implementation from being
> > instantiated via the
> > +	 * "ccm" template.  These exclusions are temporary and will
> > go away as
> > +	 * the arch-optimized AES code is migrated into the library.
> > +	 */
> > +#if IS_ENABLED(CONFIG_CRYPTO_CCM) && \
> > +	!(IS_ENABLED(CONFIG_ARM) || \
> > +	  IS_ENABLED(CONFIG_ARM64) || \
> > +	  IS_ENABLED(CONFIG_PPC) || \
> > +	  IS_ENABLED(CONFIG_RISCV) || \
> > +	  IS_ENABLED(CONFIG_S390) || \
> > +	  IS_ENABLED(CONFIG_SPARC) || \
> > +	  IS_ENABLED(CONFIG_X86))
> >  	{
> >  		.base.cra_name = "ccm(aes)",
> >  		.base.cra_driver_name = "ccm-aes-lib",
> > 
> > base-commit: 93f51579e7df248780214094418f205253383cc5

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Stian Halseth]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Hi Adrian,

On Wed, 2026-09-30 at 09:41 +0200, John Paul Adrian Glaubitz wrote:
> 
> 
> 
> Very nice! Do you know which SPARC CPUs support these instructions?
> 
> Adrian
> 

SPARC T4 or later.

The T2 and T3 has a separate crypto unit, but not supported here. 
Support was removed from the kernel in 6.14. Haven't tested it, as I
don't have the hardware.

Also worth noting, it's only used when the firmware lists the machine
description's hwcap-list and the CFR has its bit set. 

I have no idea about Fujitsu's SPARC64 X family.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[John Paul Adrian Glaubitz]

Hi Stian,

On Wed, 2026-09-30 at 11:15 +0200, Stian Halseth wrote:
> On Wed, 2026-09-30 at 09:41 +0200, John Paul Adrian Glaubitz wrote:
> > 
> > 
> > 
> > Very nice! Do you know which SPARC CPUs support these instructions?
> > 
> > Adrian
> > 
> 
> SPARC T4 or later.

OK, thanks.

> The T2 and T3 has a separate crypto unit, but not supported here. 
> Support was removed from the kernel in 6.14. Haven't tested it, as I
> don't have the hardware.

Why was it removed? I'm not happy about such removals as long as the
hardware is supported.

> Also worth noting, it's only used when the firmware lists the machine
> description's hwcap-list and the CFR has its bit set. 

Is that not the case by default?

> I have no idea about Fujitsu's SPARC64 X family.

I think SPARC64 X is not supported by the Linux kernel at all, is it?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Stian Halseth]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

Hi Adrian,

On Wed, 2026-09-30 at 11:27 +0200, John Paul Adrian Glaubitz wrote:
> 
> 
> > The T2 and T3 has a separate crypto unit, but not supported here. 
> > Support was removed from the kernel in 6.14. Haven't tested it, as
> > I
> > don't have the hardware.
> 
> Why was it removed? I'm not happy about such removals as long as the
> hardware is supported.

Looks like there were issues that prompted the removal:
https://github.com/torvalds/linux/commit/9cda46babdfe


> 
> > Also worth noting, it's only used when the firmware lists the
> > machine
> > description's hwcap-list and the CFR has its bit set. 
> 
> Is that not the case by default?
Yes, on real hardware. Just mentioned to clarify that it doesn't cause
problems on hardware that doesn't support it.

> > I have no idea about Fujitsu's SPARC64 X family.
> 
> I think SPARC64 X is not supported by the Linux kernel at all, is it?
> 
There some chip detection for it, but I've never tested, or heard about
anyone actually using it. 

sparc64: correctly recognize SPARC64-X chips
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29

cpu hw caps support for sparc64x:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Magnus Lindholm]

Hi,

On Wed, Sep 30, 2026 at 4:52 PM Stian Halseth <stian@itx.no> wrote:
>
> Hi Adrian,
>
> On Wed, 2026-09-30 at 11:27 +0200, John Paul Adrian Glaubitz wrote:
> >
> >
> > > The T2 and T3 has a separate crypto unit, but not supported here.
> > > Support was removed from the kernel in 6.14. Haven't tested it, as
> > > I
> > > don't have the hardware.
> >
> > Why was it removed? I'm not happy about such removals as long as the
> > hardware is supported.
>
> Looks like there were issues that prompted the removal:
> https://github.com/torvalds/linux/commit/9cda46babdfe
>
>
> >
> > > Also worth noting, it's only used when the firmware lists the
> > > machine
> > > description's hwcap-list and the CFR has its bit set.
> >
> > Is that not the case by default?
> Yes, on real hardware. Just mentioned to clarify that it doesn't cause
> problems on hardware that doesn't support it.
>
> > > I have no idea about Fujitsu's SPARC64 X family.
> >
> > -relocatable-kernelI think SPARC64 X is not supported by the Linux kernel at all, is it?
> >
> There some chip detection for it, but I've never tested, or heard about
> anyone actually using it.
>
> sparc64: correctly recognize SPARC64-X chips
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29
>
> cpu hw caps support for sparc64x:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f
>

I while back I got a hold of a Sun/Orcle M3000 box, there wasn't that much
missing in the linux kernel, and some hardware manuals available online
gave me the missing pieces. I have an experimental kernel running now
with gentoo user-land installed. The box has been running stable for a while
now during normal load (building stuff with emerge). I'm doing some final
cleanup work with the patches now before I send them out.

Some details below:

m3000 ~ # cat /proc/cpuinfo
cpu : Fujitsu SPARC64 VII / VII+
fpu : Fujitsu SPARC64 VII integrated FPU
pmu : (null)
prom : OBP 4.33.5.d 2012/07/18 06:55
type : sun4u
ncpus probed : 8
ncpus active : 8
D$ parity tl1 : 0
I$ parity tl1 : 0
cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus
Cpu0ClkTck : 0000000000000000
Cpu1ClkTck : 0000000000000000
Cpu2ClkTck : 0000000000000000
Cpu3ClkTck : 0000000000000000
Cpu4ClkTck : 0000000000000000
Cpu5ClkTck : 0000000000000000
Cpu6ClkTck : 0000000000000000
Cpu7ClkTck : 0000000000000000
MMU Type : Fujitsu SPARC64 VII (experimental)
MMU PGSZs : 8K,64K,512K,4MB
State:
CPU0: online
CPU1: online
CPU2: online
CPU3: online
CPU4: online
CPU5: online
CPU6: online
CPU7: online
m3000 ~ # uname -a
Linux m3000 7.3.0-rc1-m3000-rfc5 #2 SMP Sun Sep 20 18:04:02 CEST 2026
sparc64 sun4u Fujitsu SPARC64 VII / VII+ GNU/Linux
m3000 ~ # cat /proc/meminfo
MemTotal:       16595712 kB
MemFree:        16337304 kB
MemAvailable:   16440248 kB

Regards

Magnus

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Eric Biggers]

On Tue, Sep 29, 2026 at 03:27:52PM -0700, Eric Biggers wrote:
> The new library APIs for AES encryption modes were wired up to the
> traditional crypto API via crypto/aes.c.  However, for now the kernel is
> still in a transitional state where various architectures still have
> architecture-optimized implementations of AES modes in arch/*/crypto/,
> wired up to the traditional crypto API only.  Because of that, the
> crypto/aes.c algorithms were given a cra_priority of only 110 to prevent
> them from overriding arch/*/crypto/ in the traditional crypto API.
> 
> However, because of how the traditional crypto API works, the
> cra_priority trick doesn't work in cases where the relevant algorithm
> isn't directly implemented by arch/*/crypto/ but rather is provided by a
> template instance using other code in arch/*/crypto/.
> 
> For example, x86 doesn't have its own "ccm(aes)" but rather relies on
> the "ccm" template constructing it from the x86-optimized "ctr(aes)".
> The existence of the library-based "ccm(aes)" prevents that, even though
> its priority is lower than what the template would produce.
> 
> Thus, "ccm(aes)" ends up using the slower single-block AES code.
> 
> Therefore, skip wiring up the relevant library-based code to the
> traditional crypto API on architectures where this problem can occur, as
> determined by what exists in arch/*/crypto/ for each architecture.
> 
> This is ugly, but it's also temporary: these conditions will go away as
> architecture-optimized implementations of AES modes are migrated into
> the library.  But until then, we need to prevent performance regressions
> by ensuring that the optimized code continues to be used.
> 
> Fixes: 20df21a482aa ("crypto: aes - Add CBC and CBC-CTS support using library")
> Fixes: 8ca62072faa1 ("crypto: aes - Add GCM support using library")
> Fixes: f70ad727d1d6 ("crypto: aes - Add CCM support using library")
> Fixes: 94efa0c9fb36 ("crypto: aes - Add XTS support using library")
> Closes: https://github.com/sparclinux/issues/issues/106
> Signed-off-by: Eric Biggers <ebiggers@kernel.org>
> ---
> 
> This patch is intended to taken through libcrypto-fixes
> 
> v3: Also suppress xts(aes) on SPARC, and improved comments
> v2: Fixed PowerPC config option, and resent as standalone patch
> 
>  crypto/aes.c | 51 +++++++++++++++++++++++++++++++++++++++++++++++----
>  1 file changed, 47 insertions(+), 4 deletions(-)

Applied to https://git.kernel.org/pub/scm/linux/kernel/git/ebiggers/linux.git/log/?h=libcrypto-fixes

- Eric

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Stian Halseth]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]

Hi Magnus,

On Wed, 2026-09-30 at 18:03 +0200, Magnus Lindholm wrote:
> I while back I got a hold of a Sun/Orcle M3000 box, there wasn't that
> much
> missing in the linux kernel, and some hardware manuals available
> online
> gave me the missing pieces. I have an experimental kernel running now
> with gentoo user-land installed. The box has been running stable for
> a while
> now during normal load (building stuff with emerge). I'm doing some
> final
> cleanup work with the patches now before I send them out.

Very nice, sounds promising!

/Stian


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[John Paul Adrian Glaubitz]

Hi Stian,

On Wed, 2026-09-30 at 16:07 +0200, Stian Halseth wrote:
> > I think SPARC64 X is not supported by the Linux kernel at all, is it?
> > 
> There some chip detection for it, but I've never tested, or heard about
> anyone actually using it. 
> 
> sparc64: correctly recognize SPARC64-X chips
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29
> 
> cpu hw caps support for sparc64x:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f

There is one guy on the debian-sparc mailing list who got one.

Not sure if he's still active these days. I'll try to reach out.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[John Paul Adrian Glaubitz]

On Wed, 2026-09-30 at 18:03 +0200, Magnus Lindholm wrote:
> Hi,
> 
> On Wed, Sep 30, 2026 at 4:52 PM Stian Halseth <stian@itx.no> wrote:
> > 
> > Hi Adrian,
> > 
> > On Wed, 2026-09-30 at 11:27 +0200, John Paul Adrian Glaubitz wrote:
> > > 
> > > 
> > > > The T2 and T3 has a separate crypto unit, but not supported here.
> > > > Support was removed from the kernel in 6.14. Haven't tested it, as
> > > > I
> > > > don't have the hardware.
> > > 
> > > Why was it removed? I'm not happy about such removals as long as the
> > > hardware is supported.
> > 
> > Looks like there were issues that prompted the removal:
> > https://github.com/torvalds/linux/commit/9cda46babdfe
> > 
> > 
> > > 
> > > > Also worth noting, it's only used when the firmware lists the
> > > > machine
> > > > description's hwcap-list and the CFR has its bit set.
> > > 
> > > Is that not the case by default?
> > Yes, on real hardware. Just mentioned to clarify that it doesn't cause
> > problems on hardware that doesn't support it.
> > 
> > > > I have no idea about Fujitsu's SPARC64 X family.
> > > 
> > > -relocatable-kernelI think SPARC64 X is not supported by the Linux kernel at all, is it?
> > > 
> > There some chip detection for it, but I've never tested, or heard about
> > anyone actually using it.
> > 
> > sparc64: correctly recognize SPARC64-X chips
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29
> > 
> > cpu hw caps support for sparc64x:
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f
> > 
> 
> I while back I got a hold of a Sun/Orcle M3000 box, there wasn't that much
> missing in the linux kernel, and some hardware manuals available online
> gave me the missing pieces. I have an experimental kernel running now
> with gentoo user-land installed. The box has been running stable for a while
> now during normal load (building stuff with emerge). I'm doing some final
> cleanup work with the patches now before I send them out.
> 
> Some details below:
> 
> m3000 ~ # cat /proc/cpuinfo
> cpu : Fujitsu SPARC64 VII / VII+
> fpu : Fujitsu SPARC64 VII integrated FPU
> pmu : (null)
> prom : OBP 4.33.5.d 2012/07/18 06:55
> type : sun4u
> ncpus probed : 8
> ncpus active : 8
> D$ parity tl1 : 0
> I$ parity tl1 : 0
> cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus
> Cpu0ClkTck : 0000000000000000
> Cpu1ClkTck : 0000000000000000
> Cpu2ClkTck : 0000000000000000
> Cpu3ClkTck : 0000000000000000
> Cpu4ClkTck : 0000000000000000
> Cpu5ClkTck : 0000000000000000
> Cpu6ClkTck : 0000000000000000
> Cpu7ClkTck : 0000000000000000
> MMU Type : Fujitsu SPARC64 VII (experimental)
> MMU PGSZs : 8K,64K,512K,4MB
> State:
> CPU0: online
> CPU1: online
> CPU2: online
> CPU3: online
> CPU4: online
> CPU5: online
> CPU6: online
> CPU7: online
> m3000 ~ # uname -a
> Linux m3000 7.3.0-rc1-m3000-rfc5 #2 SMP Sun Sep 20 18:04:02 CEST 2026
> sparc64 sun4u Fujitsu SPARC64 VII / VII+ GNU/Linux
> m3000 ~ # cat /proc/meminfo
> MemTotal:       16595712 kB
> MemFree:        16337304 kB
> MemAvailable:   16440248 kB

Dennis Clarke (CC'ed) might be very interested to hear about this. He
wanted to install Debian on his M3000 back in 2022 [1]. Maybe Dennis
can help testing patches.

Adrian

> [1] https://lists.debian.org/debian-sparc/2022/05/msg00003.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Magnus Lindholm]

Hi Adrian,

On Wed, Sep 30, 2026 at 10:23 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> On Wed, 2026-09-30 at 18:03 +0200, Magnus Lindholm wrote:
> > Hi,
> >
> > On Wed, Sep 30, 2026 at 4:52 PM Stian Halseth <stian@itx.no> wrote:
> > >
> > > Hi Adrian,
> > >
> > > On Wed, 2026-09-30 at 11:27 +0200, John Paul Adrian Glaubitz wrote:
> > > >
> > > >
> > > > > The T2 and T3 has a separate crypto unit, but not supported here.
> > > > > Support was removed from the kernel in 6.14. Haven't tested it, as
> > > > > I
> > > > > don't have the hardware.
> > > >
> > > > Why was it removed? I'm not happy about such removals as long as the
> > > > hardware is supported.
> > >
> > > Looks like there were issues that prompted the removal:
> > > https://github.com/torvalds/linux/commit/9cda46babdfe
> > >
> > >
> > > >
> > > > > Also worth noting, it's only used when the firmware lists the
> > > > > machine
> > > > > description's hwcap-list and the CFR has its bit set.
> > > >
> > > > Is that not the case by default?
> > > Yes, on real hardware. Just mentioned to clarify that it doesn't cause
> > > problems on hardware that doesn't support it.
> > >
> > > > > I have no idea about Fujitsu's SPARC64 X family.
> > > >
> > > > -relocatable-kernelI think SPARC64 X is not supported by the Linux kernel at all, is it?
> > > >
> > > There some chip detection for it, but I've never tested, or heard about
> > > anyone actually using it.
> > >
> > > sparc64: correctly recognize SPARC64-X chips
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=76950e6e54ccfc98a25b501dbb1bc879cce1aa29
> > >
> > > cpu hw caps support for sparc64x:
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4e96377983d2e060dd89703f1846ad920af9e17f
> > >
> >
> > I while back I got a hold of a Sun/Orcle M3000 box, there wasn't that much
> > missing in the linux kernel, and some hardware manuals available online
> > gave me the missing pieces. I have an experimental kernel running now
> > with gentoo user-land installed. The box has been running stable for a while
> > now during normal load (building stuff with emerge). I'm doing some final
> > cleanup work with the patches now before I send them out.
> >
> > Some details below:
> >
> > m3000 ~ # cat /proc/cpuinfo
> > cpu : Fujitsu SPARC64 VII / VII+
> > fpu : Fujitsu SPARC64 VII integrated FPU
> > pmu : (null)
> > prom : OBP 4.33.5.d 2012/07/18 06:55
> > type : sun4u
> > ncpus probed : 8
> > ncpus active : 8
> > D$ parity tl1 : 0
> > I$ parity tl1 : 0
> > cpucaps : flush,stbar,swap,muldiv,v9,mul32,div32,v8plus
> > Cpu0ClkTck : 0000000000000000
> > Cpu1ClkTck : 0000000000000000
> > Cpu2ClkTck : 0000000000000000
> > Cpu3ClkTck : 0000000000000000
> > Cpu4ClkTck : 0000000000000000
> > Cpu5ClkTck : 0000000000000000
> > Cpu6ClkTck : 0000000000000000
> > Cpu7ClkTck : 0000000000000000
> > MMU Type : Fujitsu SPARC64 VII (experimental)
> > MMU PGSZs : 8K,64K,512K,4MB
> > State:
> > CPU0: online
> > CPU1: online
> > CPU2: online
> > CPU3: online
> > CPU4: online
> > CPU5: online
> > CPU6: online
> > CPU7: online
> > m3000 ~ # uname -a
> > Linux m3000 7.3.0-rc1-m3000-rfc5 #2 SMP Sun Sep 20 18:04:02 CEST 2026
> > sparc64 sun4u Fujitsu SPARC64 VII / VII+ GNU/Linux
> > m3000 ~ # cat /proc/meminfo
> > MemTotal:       16595712 kB
> > MemFree:        16337304 kB
> > MemAvailable:   16440248 kB
>
> Dennis Clarke (CC'ed) might be very interested to hear about this. He
> wanted to install Debian on his M3000 back in 2022 [1]. Maybe Dennis
> can help testing patches.
>
> Adrian
>
> > [1] https://lists.debian.org/debian-sparc/2022/05/msg00003.html
>

Thanks for picking this up, I would very much appreciate some help with testing.
Getting in touch with people who have access to M3000 hardware
and are willing to help out in testing would be great.

I'm gonna go over the patches and do some cleaning up, I hope I'll
have something
to send out by the weekend.

Magnus

Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Dennis Clarke]

On 9/30/26 17:41, Magnus Lindholm wrote:
> Hi Adrian,
> 
> On Wed, Sep 30, 2026 at 10:23 PM John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
>>
>> On Wed, 2026-09-30 at 18:03 +0200, Magnus Lindholm wrote:
>>> Hi,

.
.
. <snip>
.
.

> Thanks for picking this up, I would very much appreciate some help with testing.
> Getting in touch with people who have access to M3000 hardware
> and are willing to help out in testing would be great.
> 
> I'm gonna go over the patches and do some cleaning up, I hope I'll
> have something
> to send out by the weekend.
> 
> Magnus
> 


Sadly I tossed that machine into the trash a few months ago. Full of
memory and SAS disks and gone out the door to the recycle centre.

I still have a SPARC S7-2 server and a few Netra units.

-- 
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken

Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Magnus Lindholm]

Hi Dennis,

On Thu, Oct 1, 2026 at 7:37 PM Dennis Clarke <dclarke@blastwave.org> wrote:
>
>
> Sadly I tossed that machine into the trash a few months ago. Full of
> memory and SAS disks and gone out the door to the recycle centre.
>
Oooh no! Missed that by only a few months then?  But I understand,
My M3000 came close to meeting the same faith a few times, but for
some reason I've kept it in the hopes of resurrecting it again some
day.

>
> I still have a SPARC S7-2 server and a few Netra units.
>
The S7-2 is a really nice machine.

Magnus

Re: Linux on Fujitsu M3000 - was: Re: [PATCH v3] crypto: aes - Fix undesired override of some optimized AES modes

[Dennis Clarke]

On 10/2/26 03:09, Magnus Lindholm wrote:
> Hi Dennis,
> 
> On Thu, Oct 1, 2026 at 7:37 PM Dennis Clarke <dclarke@blastwave.org> wrote:
>>
>>
>> Sadly I tossed that machine into the trash a few months ago. Full of
>> memory and SAS disks and gone out the door to the recycle centre.
>>
> Oooh no! Missed that by only a few months then?  But I understand,
> My M3000 came close to meeting the same faith a few times, but for
> some reason I've kept it in the hopes of resurrecting it again some
> day.
> 

Trust me, you would not even want to pay for the shipping. However it
was a fine unit that could *only* run Solaris 10. I do regret that I
do not have a decent Fujitsu SPARC64 handy. That can be easily fixed
if I also install a proper 220 volt battery backup unit for an M4000.

>>
>> I still have a SPARC S7-2 server and a few Netra units.
>>
> The S7-2 is a really nice machine.
> 

It is very loud. Really a screamer. Fantastic cooling.

Has anyone given a try with these snapshots? :

     https://cdimage.debian.org/cdimage/ports/snapshots/2026-06-12/

I can spin up a logical hardware domain ( LDOM ) with reasonable stuff
and a dedicated 10G network port. See what works or does not. I have not
had good success on the S7 with Linux.


-- 
--
Dennis Clarke
RISC-V/SPARC/PPC/ARM/CISC
UNIX and Linux spoken