This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'.
If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-focal -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. 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-schne...@linux.ibm.com/ [RFC 1/2] PCI/IOV: Introduce pci_iov_sysfs_link() function https://lore.kernel.org/linux-pci/20200506154139.90609-2-schne...@linux.ibm.com/ [RFC 2/2] s390/pci: create links between PFs and VFs https://lore.kernel.org/linux-pci/20200506154139.90609-2-schne...@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 -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
