Comment 29 for bug 1853306

------- Comment From <email address hidden> 2023-07-18 09:54 EDT-------
Hi Frank -- Thanks alot. Here's some information about the testing I intend to do (I will duplicate it to the QEMU feature), let me know if you have any questions or if you need more details. I don't see a QEMU package available for testing yet so if need be I can use upstream QEMU to verify the kernel.

Testing will consist of the following (all on s390):

Hardware used: z14 or greater LPAR, PCI-attached devices (RoCE VFs, ISM devices, NVMe drive)

Setup: Both the kernel and QEMU features are needed for the feature to function (an upstream QEMU can be used to verify the kernel early), and the facility is only avaialble on z14 or newer. When any of those pieces is missing, the interpretation facility will not be used.
When both the kernel and QEMU features are included in their respective packages, and running in an LPAR on a z14 or newer machine, this feature will be enabled automatically. Existing supported devices should behave as before with no changes required by an end-user (e.g. no changes to libvirt domain definitions) -- but will now make use of the interpretation facility.
Additionally, ISM devices will now be eligible for vfio-pci passthrough (where before QEMU would exit on error if attempting to provide an ISM device for vfio-pci passthrough, preventing the guest from starting)

Testing will include the following scenarios, repeated each for RoCE, ISM and NVMe:

1) Testing of basic device passthrough (create a VM with a vfio-pci device as part of the libvirt domain definition, passing through a RoCE VF, an ISM device, or an NVMe drive. Verify that the device is available in the guest and functioning)
2) Testing of device hotplug/unplug (create a VM with a vfio-pci device, virsh detach-device to remove the device from the running guest, verify the device is removed from the guest, then virsh attach-device to hotplug the device to the guest again, verify the device functions in the guest)
3) Host power off testing: Power off the device from the host, verify that the device is unplugged from the guest as part of the poweroff
4) Guest power off testing: Power off the device from within the guest, verify that the device is unusuable in the guest, power the device back on within the guest and verify that the device is once again usable.
5) Guest reboot testing: (create a VM with a vfio-pci device, verify the device is in working condition, reboot the guest, verify that the device is still usable after reboot)

Testing will include the following scenarios specifically for ISM devices:

1) Testing of SMC-D v1 fallback: Using 2 ISM devices on the same VCHID that share a PNETID, create 2 guests and pass one ISM device via vfio-pci device to each guest. Establish TCP connectivity between the 2 guests using the libvirt default network, and then use smc_run (https://manpages.ubuntu.com/manpages/jammy/man8/smc_run.8.html) to run an iperf workload between the 2 guests (will include both short workloads and longer-running workloads). Verify that SMC-D transfer was used between the guests instead of TCP via 'smcd stats' (https://manpages.ubuntu.com/manpages/jammy/man8/smcd.8.html)

2) Testing of SMC-D v2: Same as above, but using 2 ISM devices on the same VCHID that have no PNETID specified

Testing will include the following scenarios specifically for RoCE devices:

1) Ping testing: Using 2 RoCE VFs that share a common network, create 2 guests and pass one RoCE device to each guest. Assign IP addresses within each guest to the associated TCP interface, perform a ping between the guests to verify connectivity.

2) Iperf testing: Similar to the above, but instead establish an iperf connection between the 2 guests and verify that the workload is successful / no errors. Will include both short workloads and longer-running workloads.

Testing will include the following scenario specifically for NVMe devices:

1) Fio testing: Using a NVMe drive passed to the guest via vfio-pci, run a series of fio tests against the device from within the guest, verifying that the workload is successful / no errors. Will include both short workloads and longer-running workloads.