Comment 2 for bug 2007599

------- Comment From <email address hidden> 2023-02-21 07:31 EDT-------
@Simon:
thanks for uploading this to Lunar.
Regarding our request for a backport / SRU in Jammy, this is the more detailed information you probably need. Just let us know if something is still missing.

SRU Justification:
==================
[Business Case]
The Eclipse OpenJ9 project is developing an "InstantOn" technology that leverages Linux's Checkpoint/Restore In Userspace (CRIU) feature. By restoring the JVM process from an existing CRIU snapshot, application can start-up up to 18x faster, without any compromises to throughput or JVM capabilities. This technology is ideal for serverless computing and scaling micro services in containerized deployments.
IBM WebSphere Liberty is one of the first exploiters of OpenJ9 InstantOn technology and have measured 10x faster start-up. In a 2021 survey with Java customers on IBM Z, 80% of users ranked initial start-up / ramp-up performance as an important metric. Other Java-based middleware and libraries can also take advantage of this technology for the significant start-up improvements. This GLIBC patch addresses a functional portability issue that is encountered when users create a container image with a CRIU snapshot on a newer hardware level and deploy this image against older hardware. GLIBC caches hardware facilities, which may not be available on the older deployment target, resulting in potential illegal instructions. With GLIBC_TUNABLES fixed to influence hwcaps and stfle bits on s390x, it allows the snapshot environment to mimic older hardware levels for the snapshot.

[Impact]
* This in a hardware enablement SRU, and mainly adds support for CryptoExpress 8S adapters to the s390-tools package.
* With that the new options 'show_serialnumbers', '--accelonly', '--ccaonly' and '--ep11only' are introduced to the lszcrypt tool.
* In addition lszcrypt now supports the checkstop state of a crypto card, that is provided by the 'chkstop' attribute in the sysfs of newer kernels.
* And lszcrypt now shows the AP bus msg size limit capability, which is needed for new adapter cards.
* New codes for zcryptstats are needed as well.

[Test Plan]
* Prepare an IBM z16 LPAR with Ubuntu 22.04 (incl. this patch) that has an CryptoExpress 8S adapter attached to it and at least one crypto domain online and available.
* Call 'lszcrypt -V' and check the 2nd column called 'type' and the last column called 'driver'.
* If both have entries that start with "cex8..." then the new CryptoExpress 8S driver is active and the new card is detected and can be used (and the new features exploited).
* If the driver listed there is older than 'cex8', than the new card is probably detected as an older type and it runs in toleration mode only.
* Try and test the new options.
* Run zcryptstats and with that make use of the new codes (which actually means add CEX8S support for zcryptstats).
* And finally extending lszcrypt's capabilities and make it aware of CEX8S.

[Where problems could occur]
* The new declarations, initializations or the scan for the serial numbers of the devices could fail, which would lead to a non-working or even erroneous new '-s' option.
* The new filter mechanism could be broken and now incorrect resources, but this would be limited to the new options '--cardonly' and '--queueonly'.
* The same applies to the new options '--accelonly', '--ccaonly' and '--ep11only'.
* The handling of the new chkstop state can be confusing or might be broken, which may lead to wrong state representations.
* The new AP bus msg size limit might be incorrectly calculated, which leads to a wrong size and with that certain feature not to work.
* The new zcryptstats might come with wrong or mixed codes, which would lead to wrong and misleading statistics, or even break zcryptstats.
* Regarding the lszcrypt capability extension there is no danger since an existing case statement is extended and the case content reused unchanged.
* All this is s390x specific, and only affects the handling for CryptoExpress 8S adapters. It won't have an impact on CPACF.