Many thx Niklas for the quick PPA testing!
** Description changed:
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.
+ 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 build in a LP PPA and already 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!
+ 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.
** Description changed:
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 build in a LP PPA and already successfully tested
+ * 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.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879704
Title:
[UBUNTU 20.04] s390x/pci: fix linking between PF and VF for
multifunction devices
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1879704/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
