<div dir="ltr">Hi Seth, ok thx.<br>I saw that the commits recently landed in groovy.<div>Thought it was due to this request - didn't dig deeper into this, so wasn't aware that they came from upstream.</div><div><br></div><div>So I'm fine - the most important thing is that they are in - either way.</div><div><br></div><div>Thx, Frank</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Sep 21, 2020 at 9:55 PM Seth Forshee <<a href="mailto:seth.forshee@canonical.com">seth.forshee@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 Wed, Aug 26, 2020 at 02:22:27PM +0200, <a href="mailto:frank.heimes@canonical.com" target="_blank">frank.heimes@canonical.com</a> wrote:<br>
> Buglink: <a href="https://bugs.launchpad.net/bugs/1892849" rel="noreferrer" target="_blank">https://bugs.launchpad.net/bugs/1892849</a><br>
> <br>
> SRU Justification:<br>
> <br>
> [Impact]<br>
> <br>
> * There is a zPCI attach/detach issue in combination with PF/VF linking support.<br>
> <br>
> * On IBM Z with zPCI, VFs can be enabled/disabled individually with /sys/bus/pci/slots/<vf_fid>/power.<br>
> <br>
> * If this was done with a VF that is linked to a parent PF, the PF symlink would become stale while the VF is disabled and<br>
> when turned back to the VF, it would not be properly linked back to the PF.<br>
> <br>
> * The PF link is removed together with the whole VF directory.<br>
> <br>
> * Hence for example qemu cannot be used since it relies on such links.<br>
> <br>
> * Additionally there is a missing pci_dev_put() when searching for the parent PF. This potentially results in a reference count of the parent PFs that is becoming too high.<br>
> <br>
> [Fix]<br>
> <br>
> * 3cddb79afc60bcdb5fd9dd7a1c64a8d03bdd460f 3cddb79afc60 "s390/pci: fix zpci_bus_link_virtfn()"<br>
> <br>
> * 2f0230b2f2d5fd287a85583eefb5aed35b6fe510 2f0230b2f2d5 "390/pci: re-introduce zpci_remove_device()"<br>
> <br>
> * b97bf44f99155e57088e16974afb1f2d7b5287aa b97bf44f9915 "s390/pci: fix PF/VF linking on hot plug"<br>
> <br>
> [Test Case]<br>
> <br>
> * Assign a zPCI device, that is capable of handling PFs/VFs (like a RoCE adapter / Connect-X5) to a z15 or LinuxONE III LPAR (usually using the HMC).<br>
> <br>
> * Enable/disable a VF with /sys/bus/pci/slots/<vf_fid>/power<br>
> <br>
> * Try to pass it through to qemu.<br>
> <br>
> * The test needs to be done at IBM due to the special hardware requirements.<br>
> <br>
> [Regression Potential]<br>
> <br>
> * A larger subset of the zPCI files in arch/s390/pci is touched (pci_bus.{h,c}, pci_bus.c, pci.c, s390_pci_hpc.c and pci_event.c), hence there is a certain risk for regressions.<br>
> <br>
> * zPCI is the s390x-specific PCI implementation and (aot) less wide spread compared to the traditional CCW hardware on s390x - no code is touched outside of arch/s390/.<br>
> <br>
> * The modifications are mainly in the IOV and hotplug area of zPCI.<br>
> <br>
> * So SR-IOV, like RoCE adapters, may be harmed by bugs or issues with hot-plugging PCI hardware on s390x.<br>
> <br>
> * But on the other hand side that is the area where these patches fix existing problems.<br>
> <br>
> * In worst case PCI events can be impacted as well, that may harm control and communication<br>
> <br>
> * or changes in base pci_bus/pci code may even break zPCI entirely.<br>
> <br>
> * Right now regular RoCE adapters (like Connect-X5) are currently not handled as real SR-IOV VFs in zPCI, but are treated as normal PCI devices.<br>
> <br>
> * Hence these zPCI SR-IOV setup changes currently apply to PFs with SR-IOV capability only, and those are currently not yet available to customers outside IBM.<br>
> <br>
> * The modifications were tested at IBM in house and a patched Ubuntu kernel was created and shared for further testing and got successfully verified (LP 1892849, comment #3).<br>
> <br>
> [Other]<br>
> <br>
> * This SRU depends on the SRU submitted for LP 1891437, which got already ACKed. So LP 1891437 is a prerequisite and needs to be applied before this one!<br>
> <br>
> * The patches of the depending SRU and the ones here were successfully tested based on a patched Ubuntu test kernel (LP 1892849, comment #3).<br>
> <br>
> * Since the above three patches got upstream accepted with 5.9-rc2, this SRU request is for Focal and Groovy.<br>
<br>
I didn't see any note about this, so thought I would close the loop. We<br>
got these patches for groovy already from upstream stable updates, so<br>
they are not needed there.<br>
<br>
Thanks,<br>
Seth<br>
</blockquote></div>