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

[Eric Biggers <ebiggers@kernel.org>]

On Sun, Oct 04, 2026 at 09:28:12PM +0200, Stian Halseth wrote:
> Implement aes_xts_encrypt_arch() and aes_xts_decrypt_arch() with the AES
> opcodes, for AES-128 and AES-256, two blocks per iteration. AES-192,
> which IEEE 1619 does not specify, and data that is not 8-byte aligned
> are left to the generic code.
> 
> The tweak is kept as little-endian words, so that multiplying it by x is
> a 128-bit shift done with addcc and the VIS3 addxc. A little-endian
> store and an ordinary load through a stack slot give it in the byte
> order of the data, and the slot is cleared on return. The routines open
> a register window, as %g4-%g6 belong to the kernel.
> 
> With that, xts-aes-lib no longer has to be kept off SPARC. Register it
> there again, with the priority x86 and RISC-V use, so that it also
> outranks an xts(ecb-aes-sparc64) instance (priority 300).
> 
> On a T7-1 (M7), MiB/s unless noted:
> 
>                                xts(ecb-aes-sparc64)  xts-aes-lib
>   AF_ALG, 64 KiB, AES-128                     415         1092
>   AF_ALG, 64 KiB, AES-256                     390          936
>   dm-crypt on brd, AES-256:
>     sequential read                          1399         2559
>     sequential write                         1472         3480
>     4 KiB write latency, QD1 (us)            40.6         32.7
> 
> dm-crypt now matches aes-cbc-essiv on the same ramdisk.
> 
> On a T4-1, AF_ALG AES-256 goes from 238 to 544 MiB/s, and AES-128
> from 252 to 616.
> 
> Tested with CONFIG_CRYPTO_SELFTESTS_FULL, and against OpenSSL over
> random keys, tweaks and lengths, on both machines.
> 
> Link: https://github.com/sparclinux/issues/issues/106
> Signed-off-by: Stian Halseth <stian@itx.no>

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

- Eric