On Tue, May 26 2026, Harald Freudenberger <[email protected]> wrote:
> This patch series extends the s390 qemu CPACF support to be able to > run a subset of the CPACF instruction cross platform. There have been > requests on the kernel crypto mailing list about a way to test > s390 specific crypto implementations. For example a way to test > s390 CPACF exploitation code like the s390_aes.ko kernel module. > > So here now is a set of patches verified on x86 and s390 which > over (slow but working) support for a subset of the subfunctions of > some of the CPACF instructions. > > Test: As this series is more or less complete, a full blown linux > can be run and the 'usual' in-kernel crpyto modules will be > automatically loaded which run a bunch of test cases. So there > is now support for these kernel modules: > * sha256_s390x (autoloaded, sha256) > * sha512_s390x (autoloaded, sha512) > * aes_s390x (autoloaded, clear key aes ecb, cbc, ctr, xts) > * pkey_pckmo (autoloaded, derive AES protected key from clear key) > * paes_s390x (not autoloaded, protected key aes ecb, cbc, ctr, xts) > All these modules run selftests if configured by the kernel (which is > enabled by default). Failures are reported via syslog. Additionally > the aes testcases from libica can be run either inside such an qemu > environment or with a static build executed with the qemu tcg > application qemu-s390x --cpu max <static-build-libica-test>. So the test setup here would be to leverage the kernel tests, but not any QEMU tests? (I'm wondering if there's a way to integrate this into normal CI workflows; can we use the libica testcases for that? I'm not really familiar with how this is used.) Also, is there any public documentation for these instructions? If not, it would be helpful if someone with access to the documentation could give an R-b here. Otherwise, nothing bad jumped out at me.
