KVM: Enable Secure Execution Crypto Passthrough - qemu part

SRU Justification:

[ Impact ]

 * As of today IBM Z crypto hardware (AP, Adjunct Processor, an IBM Z cryptographic facility, that provides cryptographic virtual functions to Linux on Z system) cannot be passed-through to Secure Execution guests (pv-guests) by KVM and QEMU. (All this in context of confidential computing aka secure execution.)

 * But it's highly desired to make use of APs from within Secure Execution guests, since they make significant use of cryptography in general, hence this should be ideally off-loadable and supported by hardware cryptographic (APs).

 * Enabling KVM and QEMU for AP passthrough to Secure Execution guests includes setup, configuration and tear-down of AP related resources and affects Kernel, qemu (and s390-tools).

 * QEMU has to turn on the corresponding bits in the KVM CPU-model if the CPU firmware supports it.

 * However, it only makes sense to turn on AP-PT if the QEMU user enabled (general) AP for that guest.

 * The kernel adjustments (which is the bigger set of changes with 20+ commits) made it in time for mantic into the Ubuntu kernel 6.5 (backports from 6.6), but not the qemu changes.

 * This SRU seeks an exception, to add the needed qemu changes post-GA to bring this overall functionality to work, since it's desired to exploit this as part of a product.

[ Fixes ]

 * 297ec01f0b s390x/ap: fix missing subsystem reset registration

 * ef1535901a s390x: do a subsystem reset before the unprotect on reboot

 * da3c22c74a linux-headers: Update to Linux v6.6-rc1

 * 354383c122 target/s390x/kvm: Refactor AP functionalities

 * 5ac951519c target/s390x: AP-passthrough for PV guests

[ Test Plan ]

 * Have an Ubuntu 23.10 LPAR with at least one (better several) APs assigned. Check with:
   $ lszcrypt -V
   CARD.DOM TYPE MODE STATUS REQUESTS PENDING HWTYPE QDEPTH FUNCTIONS DRIVER
   --------------------------------------------------------------------------------------------
   00 CEX7C CCA-Coproc online 1 0 11 08 S--D--N--- cex7card
   00.000a CEX/C CCA-Coproc online 1 0 11 08 S--D--N--- cex7queue

 * Setup a secure execution environment according to
   'Introducing IBM Secure Execution for Linux' (SC34-7721-03)
   See PDF page #15 ff, that use Ubuntu as an example.

 * Pass selected AP resources from the KVM host through to the Secure Execution (SE) guest.

 * Enable the SE guest to make use of hardware cryptographic facilities by installing the needed packages:
   $ sudo apt-get install libica-utils libica? openssl-ibmca
   and configure openssl:
   $ sudo cp /usr/share/doc/openssl-ibmca/examples/openssl.cnf.sample /etc/ssl/openssl.cnf
   This allows to make use of the ibmca openssl engine:
   $ openssl engine -c
   (dynamic) Dynamic engine loading support
   (ibmca) Ibmca hardware engine support
    [RSA, DSA, DH, RAND, DES-ECB, DES-CBC, DES-OFB, DES-CFB, DES-EDE3, DES-EDE3-CBC, DES-EDE3-OFB,
    DES-EDE3-CFB, AES-128-ECB, AES-192-ECB, AES-256-ECB, AES-128-CBC, AES-192-CBC, AES-256-CBC,
    AES-128-OFB, AES-192-OFB, AES-256-OFB, AES-128-CFB, AES-192-CFB, AES-256-CFB, SHA1, SHA256, SHA512]

 * Reset the icastats crypto counters with (just in case they are not zero):
   $ icastats -r

 * Consume cryptographic resources in the secure guest that are known to be executed
   by the underlying and passed through hardware cryptography.
   For example:
   $ openssl speed -evp aes-256-cbc 2>/dev/null | tail -n 3
   will provide this output:
   The 'numbers' are in 1000s of bytes per second processed.
   type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes 16384 bytes
   AES-256-CBC 160454.13k 510929.25k 1272902.21k 1590194.94k 1708914.64k 1702523.78k
   and will especially lead to icastats counter entries (indicating hardware use) for DRBG-SHA-512:
   $ icastats | grep DRBG-SHA-512
   DRBG-SHA-512 | 175 | 0
   [
   Alternatively use ssh to consume hardware crypto, like with (do an 'icastats -r' before):
   $ ssh -c <email address hidden> ubuntu@localhost
   that will lead to these counter entries:
   $ icastats | grep 'DRBG-SHA-512\|RSA-ME'
   DRBG-SHA-512 | 171 | 0
         RSA-ME | 1 | 0
   ]

 * The verification needs to be done by IBM.

[ Where problems could occur ]

 * Commits 297ec01f0b and ef1535901a are very small fixes (each one line),
   that are pretty traceable.

 * Commit da3c22c74a introduces the needed kernel 6.6 header changes.
   These fit to the 23.10 kernel (since they were already cherry picked: LP#2003674)
   They touch common code files and can potentially affect other architectures.
   However, the majority of modification are additional definitions.

 * Commits 354383c122 touches the s390x target only,
   refactors AP, and changes check, test and set functions.
   Hence if done errornously this can lead to a wrong states.
   Or if the refactoring wasn't done complete functions might be missed,
   but this of course is checked by a test build.
   Overall this does not look too invasive.

 * Commit 5ac951519c, again touching s390x code only,
   is the actual AP-passthrough for PV guests.
   It adds this feature similar to other the existing ones, and expands the CPU model.
   No code is removed, but only added to existing functions and a new set of
   functions got introduced: uv_feat_supported, query_uv_feat_guest, configure_uv_feat_guest
   In case of issues with these, query or config of features can be harmed
   which might lead to wrong states or even break the code.

[ Other Info ]

 * It's for our partner IBM an important new feature (as confidential computing is in general),
   which unfortunately landed late in qemu.

 * It's with 5 patches (with two of them one line fixes) not very invasive.

 * The modification can be and will be thoroughly tested.
__________

Feature Description:

Enable KVM and QEMU for AP passthrough to Secure Execution guests. This includes setup, configuration and teardown of AP related resources.