[UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu on IBM z Systems |
Fix Released
|
High
|
Skipper Bug Screeners | ||
linux (Ubuntu) |
Fix Released
|
High
|
Canonical Kernel Team | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Groovy |
Fix Released
|
High
|
Canonical Kernel Team |
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/
* Previously this could leave the card in an unresponsive error state.
[Fix]
* a1ceea67f2e5b73
* e5794cf1a270d81
[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:/
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/
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://<email address hidden>/
[RFC 1/2] PCI/IOV: Introduce pci_iov_
https://<email address hidden>/
[RFC 2/2] s390/pci: create links between PFs and VFs
https://<email address hidden>/
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/
CVE References
tags: | added: architecture-s39064 bugnameltc-185929 severity-high targetmilestone-inin2004 |
Changed in ubuntu: | |
assignee: | nobody → Skipper Bug Screeners (skipper-screen-team) |
affects: | ubuntu → linux (Ubuntu) |
description: | updated |
description: | updated |
summary: |
- [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for + [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices |
description: | updated |
description: | updated |
Changed in linux (Ubuntu Focal): | |
status: | New → In Progress |
Changed in linux (Ubuntu Focal): | |
status: | In Progress → Fix Committed |
Changed in ubuntu-z-systems: | |
status: | In Progress → Fix Committed |
Changed in ubuntu-z-systems: | |
status: | Fix Committed → Fix Released |
This is a spin off of LP 1874056 - see comment #32 there.
More details will follow here soon.