[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for multifunction devices
Test package(s) for s390x available at this PPA:
https://launchpad.net/~fheimes/+archive/ubuntu/lp1879704 |
ppa:fheimes/lp1879704
--
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: implement linking between PF and VF for
multifunction devices
Status in Ubuntu on IBM z Systems:
Triaged
Status in linux package in Ubuntu:
Triaged
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 but shouldn't, since this is needed for proper
management.
* On top the creation of not only the sysfs, but also the in-kernel
link (struct pci_dev->physfn) 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//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.
* Especially because this (one of the two patches) touches common
code.
* The changes in pci.h are very minimal, and the iov.c changes are
traceable, too. Everything else is 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.
[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
request is 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//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
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for multifunction devices
** 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 but shouldn't, since this is needed for proper
management.
* On top the creation of not only the sysfs, but also the in-kernel link
(struct pci_dev->physfn) 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//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.
* Especially because this (one of the two patches) touches common code.
* The changes in pci.h are very minimal, and the iov.c changes are
traceable, too. Everything else is 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.
[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 request
is for focal and groovy.
+ * But because groovy is not there yet (5.8 is not yet out), this SRU
+ request is 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//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
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for multifunction devices
** 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 but shouldn't, since this is needed for proper
+ management.
+
+ * On top the creation of not only the sysfs, but also the in-kernel link
+ (struct pci_dev->physfn) 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//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.
+
+ * Especially because this (one of the two patches) touches common code.
+
+ * The changes in pci.h are very minimal, and the iov.c changes are
+ traceable, too. Everything else is 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.
+
+ [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 request
is for focal and groovy.
+ __
+
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//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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1879704
Title:
[UBUNTU 20.04] s390x/pci: implement linking
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for multifunction devices
Thx for the update - yepp, found them in linux-next.
So should be possible to address them with the upcoming kernel SRU ...
** Changed in: linux (Ubuntu)
Status: Incomplete => Triaged
** Changed in: ubuntu-z-systems
Status: Incomplete => Triaged
--
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: implement linking between PF and VF for
multifunction devices
Status in Ubuntu on IBM z Systems:
Triaged
Status in linux package in Ubuntu:
Triaged
Bug description:
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//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
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for multifunction devices
The content of comment #2 was copied over as bug description.
The patch set in preparation is:
[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/
As already mentioned, target to upstream acceptance is kernel 5.8.
** Description changed:
- Description will follow
+ 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//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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1879704
Title:
[UBUNTU 20.04] s390x/pci: implement linking between PF and VF for
multifunction devices
Status in Ubuntu on IBM z Systems:
Incomplete
Status in linux package in Ubuntu:
Incomplete
Bug description:
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//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
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for multifunction devices
This is a spin off of LP 1874056 - see comment #32 there. More details will follow here soon. ** Also affects: ubuntu-z-systems Importance: Undecided Status: New ** Changed in: linux (Ubuntu) Status: New => Incomplete ** Changed in: ubuntu-z-systems Status: New => Incomplete ** Changed in: linux (Ubuntu) Assignee: Skipper Bug Screeners (skipper-screen-team) => Canonical Kernel Team (canonical-kernel-team) ** Changed in: ubuntu-z-systems Assignee: (unassigned) => Skipper Bug Screeners (skipper-screen-team) -- 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: implement linking between PF and VF for multifunction devices Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Incomplete Bug description: Description will follow 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
