[Bug 1879704] Autopkgtest regression report (linux-oracle-5.4/5.4.0-1019.19~18.04.1)

All autopkgtests for the newly accepted linux-oracle-5.4 (5.4.0-1019.19~18.04.1) for bionic have finished running.
The following regressions have been reported in tests triggered by the package:

zfs-linux/unknown (armhf)


Please visit the excuses page listed below and investigate the failures, proceeding afterwards as per the StableReleaseUpdates policy regarding autopkgtest regressions [1].

https://people.canonical.com/~ubuntu-archive/proposed-
migration/bionic/update_excuses.html#linux-oracle-5.4

[1] https://wiki.ubuntu.com/StableReleaseUpdates#Autopkgtest_Regressions

Thank you!

--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/1879704

Title:
[UBUNTU 20.04] s390x/pci: fix linking between PF and VF for
multifunction devices

Status in Ubuntu on IBM z Systems:
Fix Committed
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Focal:
Fix Committed
Status in linux source package in Groovy:
In Progress

Bug description:
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!
__________

As with other architectures, we must be able on s390x to verify the
following relationships between PFs and VFs for proper management
(including by libvirt) of network interfaces:

1. 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.
2. Determine virtual functions of a physical function: for other architectures this is currently available as `virtfn{index}` links under the PF device's directory.
3. 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

More details for the already existing parameters mentioned above can
be found here: https://www.kernel.org/doc/Documentation/ABI/testing
/sysfs-bus-pci

Moreover creating not just the sysfs but also the in-kernel link
(struct pci_dev->physfn) also allows us to use the common code path
for disabling/shutdown of PFs.
This code path is currently fenced off by the
struct pci_dev->no_vf_scan flag of which s390 is currently the only user.

This in turn allows for a graceful and orderly shutdown of VFs
associated with a VF as triggered by:

echo 0 > /sys/bus/pci/devices/<some_pf>/sriov_numvfs

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

The patches for this have been discussed and Acked-by the
responsible upstream maintainer here:

[RFC 0/2] Enable PF-VF linking with pdev->no_vf_scan (s390)
https://lore.kernel.org/linux-pci/20200506154139.90609-1-schnelle@linux.ibm.com/

[RFC 1/2] PCI/IOV: Introduce pci_iov_sysfs_link() function
https://lore.kernel.org/linux-pci/20200506154139.90609-2-schnelle@linux.ibm.com/

[RFC 2/2] s390/pci: create links between PFs and VFs
https://lore.kernel.org/linux-pci/20200506154139.90609-2-schnelle@linux.ibm.com/

They are currently queued to be posted to the public s390 Kernel
repository and linux-next / 5.8.
These depend on the previous multi-function/enumeration rework.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions