NAK[G]: [SRU][F][G][PATCH 0/3] zPCI attach/detach issues with PF/VF linking support (LP: 1892849)

[Frank Heimes]

Hi Seth, ok thx.
I saw that the commits recently landed in groovy.
Thought it was due to this request - didn't dig deeper into this, so wasn't
aware that they came from upstream.

So I'm fine - the most important thing is that they are in - either way.

Thx, Frank

On Mon, Sep 21, 2020 at 9:55 PM Seth Forshee <seth.forshee at canonical.com>
wrote:

> On Wed, Aug 26, 2020 at 02:22:27PM +0200, frank.heimes at canonical.com
> wrote:
> > Buglink: https://bugs.launchpad.net/bugs/1892849
> >
> > SRU Justification:
> >
> > [Impact]
> >
> > * There is a zPCI attach/detach issue in combination with PF/VF linking
> support.
> >
> > * On IBM Z with zPCI, VFs can be enabled/disabled individually with
> /sys/bus/pci/slots/<vf_fid>/power.
> >
> > * 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
> > when turned back to the VF, it would not be properly linked back to the
> PF.
> >
> > * The PF link is removed together with the whole VF directory.
> >
> > * Hence for example qemu cannot be used since it relies on such links.
> >
> > * 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.
> >
> > [Fix]
> >
> > * 3cddb79afc60bcdb5fd9dd7a1c64a8d03bdd460f 3cddb79afc60 "s390/pci: fix
> zpci_bus_link_virtfn()"
> >
> > * 2f0230b2f2d5fd287a85583eefb5aed35b6fe510 2f0230b2f2d5 "390/pci:
> re-introduce zpci_remove_device()"
> >
> > * b97bf44f99155e57088e16974afb1f2d7b5287aa b97bf44f9915 "s390/pci: fix
> PF/VF linking on hot plug"
> >
> > [Test Case]
> >
> > * 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).
> >
> > * Enable/disable a VF with /sys/bus/pci/slots/<vf_fid>/power
> >
> > * Try to pass it through to qemu.
> >
> > * The test needs to be done at IBM due to the special hardware
> requirements.
> >
> > [Regression Potential]
> >
> > * 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.
> >
> > * 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/.
> >
> > * The modifications are mainly in the IOV and hotplug area of zPCI.
> >
> > * So SR-IOV, like RoCE adapters, may be harmed by bugs or issues with
> hot-plugging PCI hardware on s390x.
> >
> > * But on the other hand side that is the area where these patches fix
> existing problems.
> >
> > * In worst case PCI events can be impacted as well, that may harm
> control and communication
> >
> > * or changes in base pci_bus/pci code may even break zPCI entirely.
> >
> > * 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.
> >
> > * 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.
> >
> > * 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).
> >
> > [Other]
> >
> > * 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!
> >
> > * The patches of the depending SRU and the ones here were successfully
> tested based on a patched Ubuntu test kernel (LP 1892849, comment #3).
> >
> > * Since the above three patches got upstream accepted with 5.9-rc2, this
> SRU request is for Focal and Groovy.
>
> I didn't see any note about this, so thought I would close the loop. We
> got these patches for groovy already from upstream stable updates, so
> they are not needed there.
>
> Thanks,
> Seth
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20200922/e84a3180/attachment.html>