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

[Kleber Souza]

On 2020-06-02 11:45, frank.heimes at canonical.com wrote:
> 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(-)
> 

With the fixed provenance:

Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>