Re: [PATCH 15/36] lib/crypto: s390/aes: Migrate optimized code into library

[Eric Biggers <ebiggers@kernel.org>]

On Wed, Jan 07, 2026 at 08:41:02AM +0100, Holger Dengler wrote:
> Hi Eric,
> 
> first of all: happy New Year! ANd thanks for the series.
> 
> On 05/01/2026 06:12, Eric Biggers wrote:
> > Implement aes_preparekey_arch(), aes_encrypt_arch(), and 
> > aes_decrypt_arch() using the CPACF AES instructions.
> 
> I'm not sure, it it makes sense to implement this on s390 at all. The CPACF
> instructions cover full modes of operations and are  to process more
> than one cipher-block-size (*). For single-block operations, the performance
> might be worth than using the generic functions. I will look into it and do
> some performance tests. If there is a possibility to plug-in to the level
> where the modes of operation are implemented, it would make much more sense
> for s390.
> 
> (*) Yes, it's a bit uncommon, but the CPACF instructions on s390 can process
> multiple block with a single instruction call! They are so called long running
> instructions.

I'm happy to drop the CPACF single-block AES code if it's not
worthwhile.  I included it only because arch/s390/crypto/ already has
such code.  Since I'm making it so that the crypto_cipher API simply
wraps the library API, if this code is not brought into the library it
will effectively be dropped.  You had pushed back the last time I
proposed dropping one of the s390 optimizations, even a fairly minor one
(https://lore.kernel.org/linux-crypto/51fc91b6-3a6e-44f7-ae93-aef0bcb48964@linux.ibm.com/).

But I have no way to test or benchmark the s390 code myself.  If the
CPACF single-block AES en/decryption code isn't worthwhile, there's no
reason to keep it, so I'll remove it.

As for AES modes, later patchsets are going to introduce
architecture-optimized AES modes into the library, and the traditional
crypto API for those modes will similarly be reimplemented on top of it.
This patchset just focuses on the existing library API for key expansion
and single block en/decryption as a first step.  (As with the
traditional API, single block en/decryption is needed as a fallback to
handle any modes that don't have a standalone implementation.)

- Eric