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

On 07/01/2026 21:34, Eric Biggers wrote:

On Wed, Jan 07, 2026 at 08:41:02AM +0100, Holger Dengler wrote:

quoted

Hi Eric,

first of all: happy New Year! ANd thanks for the series.

On 05/01/2026 06:12, Eric Biggers wrote:

quoted

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/ (local)).

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.

My assumtion, that the aes single-block-operation operation is slower in CPACF
than in software, seems to be wrong. I did some measurements on different
machines and it turns out, that it is up to ~2x faster doing it in CPACF.

So, sorry for the noise. Please leave your s390 implementation as it is.

PS: I have a simple kunit test for aes (KAT and benchmark for each direction
and key-size). I'll send it in a separate reply. Feel free to pick 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.)

Ok. So we'll wait for upcoming patchsets.

-- 
Mit freundlichen Grüßen / Kind regards
Holger Dengler
--
IBM Systems, Linux on IBM Z Development
dengler@linux.ibm.com