[SRU][F][G][PATCH 0/2] s390x/pci: fix linking between PF and VF for multifunction devices (LP: 1879704)

[frank.heimes at canonical.com]

Buglink: https://bugs.launchpad.net/bugs/1879704

SRU Justification:

[Impact]

* It's currently not possible on s390x to verify the relationships between PFs and VFs of network interfaces (neither natively nor in libvirt).

* So s390x currently behaves differently here compared to other architectures, but shouldn't, since this is needed for proper management.

* The creation of not only the sysfs, but also the in-kernel link (struct pci_dev->physfn), solves this and on top allows the use of a common code path for disabling/shutdown of PFs.

* This code path is right now fenced off by the struct pci_dev->no_vf_scan flag of which s390x is currently the only user.

* This allows to gracefully and orderly shutdown VFs associated with a PF as triggered by '/sys/bus/pci/devices/<some_pf>/sriov_numvfs'

* Previously this could leave the card in an unresponsive error state.

[Fix]

* a1ceea67f2e5b73cebd456e7fb463b3052bc6344 a1ceea67f2e5 "PCI/IOV: Introduce pci_iov_sysfs_link() function"

* e5794cf1a270d813a5b9373a6876487d4d154195 e5794cf1a270 "s390/pci: create links between PFs and VFs"

[Test Case]

* Setup an s390x LPAR with at least one SR-IOV card and assign PF and VFs to that system.

* Determine if a device is a virtual function: for other architectures this is currently available in the file 'physfn' which is a link to the parent PF's device.

* Determine virtual functions of a physical function: for other architectures this is currently available as 'virtfn{index}' links under the PF device's directory.

* Determine the physical function of a virtual function: on x86 this is currently available in the file 'physfn' which is a link to the parent PF.

* This verification needs to be done by IBM on a system with SR-IOV (PCI-based) hardware.

[Regression Potential]

* There is a certain regression risk with having code changes in the PCI/IOV space,
  even is they are limited, especially is the patches touche common code.

* The changes in pci.h are very minimal, and the iov.c changes are traceable, too. All other modifications are s390x specific.

* Nevertheless, it could be that PCI hardware get harmed, here especially (SR-)IOV hardware.

* The patches got cross-company verified (IBM and Google).

* They were brought upstream and are currently tagged with 20200521, and are planned to be included in 5.8.

* A patched kernel was created based on a LP PPA and successfully tested by IBM.

[Other]

* Since the fix/patch is planned to be included in kernel v5.8, it will later automatically land in groovy.

* But because groovy is not there yet (5.8 is not yet out), this SRU got requested for focal and groovy.

* This SRU depends on the SRU from LP 1874056, and this has already two ACKs.
  So LP 1874056 needs to be applied before this one!

Niklas Schnelle (2):
  From: Niklas Schnelle <schnelle at linux.ibm.com>
  From: Niklas Schnelle <schnelle at linux.ibm.com>

 arch/s390/include/asm/pci.h     |  3 +-
 arch/s390/include/asm/pci_clp.h |  3 +-
 arch/s390/pci/pci_bus.c         | 72 ++++++++++++++++++++++++++++++++-
 arch/s390/pci/pci_clp.c         |  1 +
 drivers/pci/iov.c               | 39 +++++++++++-------
 include/linux/pci.h             |  8 ++++
 6 files changed, 108 insertions(+), 18 deletions(-)

-- 
2.25.1