Re: [PATCH] lib/crypto: sparc/aes-xts: Add optimization using the AES opcodes

[Eric Biggers <ebiggers@kernel.org>]

On Tue, Sep 29, 2026 at 11:33:58PM +0200, Stian Halseth wrote:
> Hi Eric,
> 
> On Tue, 2026-09-29 at 21:24 +0000, Eric Biggers wrote:
> > 
> > It's a little late to be adding new optimized code in 7.3.  But yes,
> > full AES-XTS performance requires that it be implemented directly, so
> > we
> > should add this optimized AES-XTS code in 7.4 (assuming people still
> > care about SPARC, which I guess you do).  For 7.3 let's just suppress
> > "xts-aes-lib" on sparc.  I left it out of the patch
> > https://lore.kernel.org/linux-crypto/20260925202353.10763-1-ebiggers@kernel.org/
> > , but I guess it should be included after all.
> > 
> Completely understandable. I was considering sending two patches at
> first, one to suppress "xts-aes-lib" on sparc, and one with the
> optimized code.
>  
> You're adding the suppression? 
>
> If yes, I can test the suppression on a T7-1 and a T4-1 when you have
> it. 

It's in v3 now:
https://lore.kernel.org/linux-crypto/20260929222752.36427-1-ebiggers@kernel.org

> For 7.4 I could send a v2 on top of it that takes sparc out of the
> suppression again, without the Fixes: tag.

I suppose.  QEMU support is normally required for new crypto library
code, so that it is actually testable.  That would rule out adding any
"new" code using the SPARC crypto opcodes until support for them is
added to QEMU (https://github.com/sparclinux/issues/issues/77).

I might be willing to make an exception for AES-XTS, since otherwise for
parity with the "xts" template the library would need to gain an
implementation of AES-XTS on top of AES-ECB.  That would be annoying
since it's inefficient, and SPARC is the *only* architecture that would
need it, as on every other architecture AES-XTS was optimized properly.

Anyway, I'll be migrating the SPARC optimized AES-{ECB,CBC,CTR} into the
library too.  I'll need your help to test it, since it's completely
untestable for anyone without SPARC hardware.  (And it will soon the
only arch with that property now that even s390 is being fixed...)

- Eric