<div dir="ltr">Please reject this upload, since a version 2 was sent:<div><a href="https://lists.ubuntu.com/archives/kernel-team/2023-November/thread.html#147088">https://lists.ubuntu.com/archives/kernel-team/2023-November/thread.html#147088</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 21, 2023 at 12:36 PM Frank Heimes <<a href="mailto:frank.heimes@canonical.com">frank.heimes@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div dir="ltr" class="gmail_signature"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>Okay, I see and agree. Thx for the feedback.<br><br>Will provide a v2 soon ...</div></div></div></div></div></div></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 21, 2023 at 9:38 AM Stefan Bader <<a href="mailto:stefan.bader@canonical.com" target="_blank">stefan.bader@canonical.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 17.11.23 16:28, <a href="mailto:frank.heimes@canonical.com" target="_blank">frank.heimes@canonical.com</a> wrote:<br>
> BugLink: <a href="https://bugs.launchpad.net/bugs/2042853" rel="noreferrer" target="_blank">https://bugs.launchpad.net/bugs/2042853</a><br>
> <br>
> SRU Justification:<br>
> <br>
> [Impact]<br>
> <br>
> * Today no s390x-specific vfio-pci devices (zPCI) can be passed<br>
> from a KVM host to a KVM guest (incl. secure execution guests<br>
> in the context of confidential computing).<br>
> <br>
> * s390x PCI passthrough needs various changes in the s390x kernel zPCI<br>
> code (incl. the new s390x-specific Kernel config option<br>
> 'CONFIG_VFIO_PCI_ZDEV_KVM') that were introduced with kernel 6.0<br>
> and got backported to 22.04/jammy as part of LP: #1853306.<br>
> <br>
> * Lunar an newer Ubuntu releases have the code already included from<br>
> upstream (incl. the Kernel option 'CONFIG_VFIO_PCI_ZDEV_KVM'), but the<br>
> config option is not set, hence zPCI pass-through is still not possible.<br>
> <br>
> [Fix]<br>
> <br>
> * To be able to make use of VFIO zPCI pass-through on s390x running newer<br>
> Ubuntu releases (especially needed in the context of secure execution)<br>
> the (s390x-specific) Kernel config option 'CONFIG_VFIO_PCI_ZDEV_KVM' needs<br>
> to be enabled and set to 'y'.<br>
> <br>
> [Test Case]<br>
> <br>
> * Hardware used: z14 or greater LPAR, PCI-attached devices<br>
> (RoCE VFs, ISM devices, NVMe drive)<br>
> <br>
> * Setup: Both the kernel and QEMU features are needed for the feature<br>
> to function (an upstream QEMU can be used to verify the kernel early),<br>
> and the facility is only available on z14 or newer.<br>
> When any of those pieces is missing,<br>
> the interpretation facility will not be used.<br>
> When both the kernel and QEMU features are included in their respective<br>
> packages, and running in an LPAR on a z14 or newer machine,<br>
> this feature will be enabled automatically.<br>
> Existing supported devices should behave as before with no changes<br>
> required by an end-user (e.g. no changes to libvirt domain definitions)<br>
> -- but will now make use of the interpretation facility.<br>
> Additionally, ISM devices will now be eligible for vfio-pci passthrough<br>
> (where before QEMU would exit on error if attempting to provide an ISM<br>
> device for vfio-pci passthrough, preventing the guest from starting)<br>
> <br>
> * Testing will include the following scenarios, repeated each for RoCE,<br>
> ISM and NVMe:<br>
> <br>
> 1) Testing of basic device passthrough (create a VM with a vfio-pci<br>
> device as part of the libvirt domain definition, passing through<br>
> a RoCE VF, an ISM device, or an NVMe drive. Verify that the device<br>
> is available in the guest and functioning)<br>
> 2) Testing of device hotplug/unplug (create a VM with a vfio-pci device,<br>
> virsh detach-device to remove the device from the running guest,<br>
> verify the device is removed from the guest, then virsh attach-device<br>
> to hotplug the device to the guest again, verify the device functions<br>
> in the guest)<br>
> 3) Host power off testing: Power off the device from the host, verify<br>
> that the device is unplugged from the guest as part of the poweroff<br>
> 4) Guest power off testing: Power off the device from within the guest,<br>
> verify that the device is unusable in the guest,<br>
> power the device back on within the guest and verify that the device<br>
> is once again usable.<br>
> 5) Guest reboot testing: (create a VM with a vfio-pci device,<br>
> verify the device is in working condition, reboot the guest,<br>
> verify that the device is still usable after reboot)<br>
> <br>
> [Regression Potential]<br>
> <br>
> * The regression potential is moderate, since the code is upstream<br>
> for quite a while and already enabled in jammy.<br>
> <br>
> * The general way on using passthrough has not changed, with this<br>
> change (config option) it's now just possible to passthrough<br>
> zPCI on top.<br>
> <br>
> * CCW devices are not affected.<br>
> <br>
> * And this is s390x-specific anyway, so no other architectures are affected.<br>
> <br>
> [Other]<br>
> <br>
> * The enabling of the kernel config option is exactly the same for L, M<br>
> and U/N, but I submitted separate patches due to slightly different context<br>
> and offsets.<br>
> <br>
> Frank Heimes (1):<br>
> UBUNTU: [Config] enable VFIO zPCI pass-through for s390x<br>
> <br>
> debian.master/config/annotations | 3 +++<br>
> 1 file changed, 3 insertions(+)<br>
> <br>
I probably would rather reject for the following reasons:<br>
* The config option already exists at least in the M/L annotations<br>
* Those should be modified instead of adding duplicate entries<br>
* I would expect that if this patch is applied and updateconfigs is run then<br>
lines will get moved around.<br>
I would rather avoid this when starting to prep a kernel. So please <br>
double check and in case this happens submit a new set.<br>
<br>
Thanks,<br>
-Stefan<br>
-- <br>
- Stefan<br>
<br>
</blockquote></div>
</blockquote></div>