| 2020-04-21 12:09:53 |
bugproxy |
bug |
|
|
added bug |
| 2020-04-21 12:09:55 |
bugproxy |
tags |
|
architecture-s39064 bugnameltc-184172 severity-high targetmilestone-inin2004 |
|
| 2020-04-21 12:09:57 |
bugproxy |
ubuntu: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2020-04-21 12:10:00 |
bugproxy |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2020-04-21 12:22:54 |
Heinz-Werner Seeck |
summary |
s390x/pci: enumerate pci functions per physical adapter |
[UBUNTU 20.04] s390x/pci: enumerate pci functions per physical adapter |
|
| 2020-04-21 14:45:16 |
Frank Heimes |
description |
Description will follow |
Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter.
Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>
On s390x, each function is presented as individual root complex today, e.g.:
PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0
On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>. We need to use the same enumeration scheme to achieve this functionality on s390x.
In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.
Required result (example with 4 VFs per PF):
PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9
PCHID 0200 PF 0 0001:00:00.0 |
|
| 2020-04-21 14:45:31 |
Frank Heimes |
bug task added |
|
ubuntu-z-systems |
|
| 2020-04-22 14:35:03 |
Frank Heimes |
ubuntu-z-systems: status |
New |
Incomplete |
|
| 2020-04-22 14:37:39 |
Frank Heimes |
ubuntu-z-systems: importance |
Undecided |
Medium |
|
| 2020-05-13 16:50:53 |
Frank Heimes |
ubuntu-z-systems: assignee |
|
Skipper Bug Screeners (skipper-screen-team) |
|
| 2020-05-13 16:51:05 |
Frank Heimes |
linux (Ubuntu): assignee |
Skipper Bug Screeners (skipper-screen-team) |
Canonical Kernel Team (canonical-kernel-team) |
|
| 2020-05-13 16:51:21 |
Frank Heimes |
bug |
|
|
added subscriber Canonical Kernel Team |
| 2020-05-13 16:51:25 |
Frank Heimes |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2020-05-13 16:51:33 |
Frank Heimes |
bug |
|
|
added subscriber Terry Rudd |
| 2020-05-14 08:40:15 |
bugproxy |
attachment added |
|
s390/pci: Improve handling of unset UID https://bugs.launchpad.net/bugs/1874056/+attachment/5371388/+files/0001-s390-pci-Improve-handling-of-unset-UID.patch |
|
| 2020-05-14 08:40:17 |
bugproxy |
attachment added |
|
s390/pci: embedding hotplug_slot in zdev https://bugs.launchpad.net/bugs/1874056/+attachment/5371389/+files/0002-s390-pci-embedding-hotplug_slot-in-zdev.patch |
|
| 2020-05-14 08:40:20 |
bugproxy |
attachment added |
|
390/pci: Expose new port attribute for PCIe functions https://bugs.launchpad.net/bugs/1874056/+attachment/5371390/+files/0003-s390-pci-Expose-new-port-attribute-for-PCIe-function.patch |
|
| 2020-05-14 08:40:22 |
bugproxy |
attachment added |
|
s390/pci: adaptation of iommu to multifunction https://bugs.launchpad.net/bugs/1874056/+attachment/5371391/+files/0004-s390-pci-adaptation-of-iommu-to-multifunction.patch |
|
| 2020-05-14 08:50:26 |
bugproxy |
attachment added |
|
s390/pci: define kernel parameters for PCI multifunction https://bugs.launchpad.net/bugs/1874056/+attachment/5371393/+files/0005-s390-pci-define-kernel-parameters-for-PCI-multifunct.patch |
|
| 2020-05-14 08:50:28 |
bugproxy |
attachment added |
|
s390/pci: define RID and RID available https://bugs.launchpad.net/bugs/1874056/+attachment/5371394/+files/0006-s390-pci-define-RID-and-RID-available.patch |
|
| 2020-05-14 08:50:30 |
bugproxy |
attachment added |
|
s390/pci: create zPCI bus https://bugs.launchpad.net/bugs/1874056/+attachment/5371395/+files/0007-s390-pci-create-zPCI-bus.patch |
|
| 2020-05-14 08:50:32 |
bugproxy |
attachment added |
|
s390/pci: adapt events for zbus https://bugs.launchpad.net/bugs/1874056/+attachment/5371396/+files/0008-s390-pci-adapt-events-for-zbus.patch |
|
| 2020-05-14 08:50:34 |
bugproxy |
attachment added |
|
s390/pci: Handling multifunctions https://bugs.launchpad.net/bugs/1874056/+attachment/5371397/+files/0009-s390-pci-Handling-multifunctions.patch |
|
| 2020-05-14 08:50:36 |
bugproxy |
attachment added |
|
s390/pci: Do not disable PF when VFs exist https://bugs.launchpad.net/bugs/1874056/+attachment/5371398/+files/0010-s390-pci-Do-not-disable-PF-when-VFs-exist.patch |
|
| 2020-05-14 08:50:38 |
bugproxy |
attachment added |
|
s390/pci: Documentation for zPCI https://bugs.launchpad.net/bugs/1874056/+attachment/5371399/+files/0011-s390-pci-Documentation-for-zPCI.patch |
|
| 2020-05-14 08:50:40 |
bugproxy |
attachment added |
|
s390/pci: removes wrong PCI multifunction assignment https://bugs.launchpad.net/bugs/1874056/+attachment/5371400/+files/0012-s390-pci-removes-wrong-PCI-multifunction-assignment.patch |
|
| 2020-05-14 14:37:05 |
Dan Streetman |
bug |
|
|
added subscriber Dan Streetman |
| 2020-05-18 18:39:38 |
Frank Heimes |
description |
Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter.
Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>
On s390x, each function is presented as individual root complex today, e.g.:
PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0
On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>. We need to use the same enumeration scheme to achieve this functionality on s390x.
In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.
Required result (example with 4 VFs per PF):
PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9
PCHID 0200 PF 0 0001:00:00.0 |
SRU Justification:
==================
[Impact]
* On s390x the enumeration of PCI functions does not reflect which functions belongs to which physical adapter.
* Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>
* On s390x, each function is presented as individual root complex today, e.g.:
PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0
* On other platforms, the addresses correctly reflect the actual HW configuration.
* Some device drivers (like mlx5, for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>.
* We need to use the same enumeration scheme to achieve this functionality on s390x.
* In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1,
and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.
* Required result (example with 4 VFs per PF):
PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9
PCHID 0200 PF 0 0001:00:00.0
[Fix]
* Backport 1: https://launchpadlibrarian.net/479699471/0001-s390-pci-Improve-handling-of-unset-UID.patch
* Backport 2: https://launchpadlibrarian.net/479699482/0002-s390-pci-embedding-hotplug_slot-in-zdev.patch
* Backport 3: https://launchpadlibrarian.net/479699492/0003-s390-pci-Expose-new-port-attribute-for-PCIe-function.patch
* Backport 4: https://launchpadlibrarian.net/479699497/0004-s390-pci-adaptation-of-iommu-to-multifunction.patch
* Backport 5: https://launchpadlibrarian.net/479700706/0005-s390-pci-define-kernel-parameters-for-PCI-multifunct.patch
* Backport 6: https://launchpadlibrarian.net/479700712/0006-s390-pci-define-RID-and-RID-available.patch
* Backport 7: https://launchpadlibrarian.net/479700739/0007-s390-pci-create-zPCI-bus.patch
* Backport 8: https://launchpadlibrarian.net/479700769/0008-s390-pci-adapt-events-for-zbus.patch
* Backport 9: https://launchpadlibrarian.net/479700786/0009-s390-pci-Handling-multifunctions.patch
* Backport 10: https://launchpadlibrarian.net/479700794/0010-s390-pci-Do-not-disable-PF-when-VFs-exist.patch
* Backport 11: https://launchpadlibrarian.net/479700798/0011-s390-pci-Documentation-for-zPCI.patch
* Backport 12: https://launchpadlibrarian.net/479700799/0012-s390-pci-removes-wrong-PCI-multifunction-assignment.patch
[Test Case]
* Prepare an IBM z13 or LinuxONE III (or newer) system with two or more RoCE Express PCI 2(.1) adapters.
* Assign the adapters (and it's virtual functions) to an LPAR.
* Verify whether the physical and virtual functions are grouped in arbitrary order or in consecutive order - physical first (for example with lspci -t ...)
[Regression Potential]
* The regression potential can be considered as moderate, since:
* It is purely s390x specific code (arch/s390/* drivers/iommu/s390-iommu.c and drivers/pci/hotplug/s390_pci_hpc.c - and some doc adjustments, too).
* It largely affects zPCI, the s390x specific PCI code layer.
* PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread.
* The situation described above affects the RoCE adapters only (Mellanox based).
* The patches are also upstream accepted and available via linux-next, but to apply them to focal kernel 5.4 the above backports are needed.
* However, the code is modified by several patches (12), hence there is a chance to break zPCI with them.
* For upfront testing a PPA got created with a focal (master-next) kernel that incl. all the above patches.
__________
Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter.
Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>
On s390x, each function is presented as individual root complex today, e.g.:
PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0
On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>. We need to use the same enumeration scheme to achieve this functionality on s390x.
In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.
Required result (example with 4 VFs per PF):
PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9
PCHID 0200 PF 0 0001:00:00.0 |
|
| 2020-05-18 18:39:43 |
Frank Heimes |
linux (Ubuntu): status |
Incomplete |
In Progress |
|
| 2020-05-18 18:39:49 |
Frank Heimes |
ubuntu-z-systems: status |
Incomplete |
In Progress |
|
| 2020-05-19 09:49:40 |
Frank Heimes |
description |
SRU Justification:
==================
[Impact]
* On s390x the enumeration of PCI functions does not reflect which functions belongs to which physical adapter.
* Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>
* On s390x, each function is presented as individual root complex today, e.g.:
PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0
* On other platforms, the addresses correctly reflect the actual HW configuration.
* Some device drivers (like mlx5, for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>.
* We need to use the same enumeration scheme to achieve this functionality on s390x.
* In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1,
and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.
* Required result (example with 4 VFs per PF):
PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9
PCHID 0200 PF 0 0001:00:00.0
[Fix]
* Backport 1: https://launchpadlibrarian.net/479699471/0001-s390-pci-Improve-handling-of-unset-UID.patch
* Backport 2: https://launchpadlibrarian.net/479699482/0002-s390-pci-embedding-hotplug_slot-in-zdev.patch
* Backport 3: https://launchpadlibrarian.net/479699492/0003-s390-pci-Expose-new-port-attribute-for-PCIe-function.patch
* Backport 4: https://launchpadlibrarian.net/479699497/0004-s390-pci-adaptation-of-iommu-to-multifunction.patch
* Backport 5: https://launchpadlibrarian.net/479700706/0005-s390-pci-define-kernel-parameters-for-PCI-multifunct.patch
* Backport 6: https://launchpadlibrarian.net/479700712/0006-s390-pci-define-RID-and-RID-available.patch
* Backport 7: https://launchpadlibrarian.net/479700739/0007-s390-pci-create-zPCI-bus.patch
* Backport 8: https://launchpadlibrarian.net/479700769/0008-s390-pci-adapt-events-for-zbus.patch
* Backport 9: https://launchpadlibrarian.net/479700786/0009-s390-pci-Handling-multifunctions.patch
* Backport 10: https://launchpadlibrarian.net/479700794/0010-s390-pci-Do-not-disable-PF-when-VFs-exist.patch
* Backport 11: https://launchpadlibrarian.net/479700798/0011-s390-pci-Documentation-for-zPCI.patch
* Backport 12: https://launchpadlibrarian.net/479700799/0012-s390-pci-removes-wrong-PCI-multifunction-assignment.patch
[Test Case]
* Prepare an IBM z13 or LinuxONE III (or newer) system with two or more RoCE Express PCI 2(.1) adapters.
* Assign the adapters (and it's virtual functions) to an LPAR.
* Verify whether the physical and virtual functions are grouped in arbitrary order or in consecutive order - physical first (for example with lspci -t ...)
[Regression Potential]
* The regression potential can be considered as moderate, since:
* It is purely s390x specific code (arch/s390/* drivers/iommu/s390-iommu.c and drivers/pci/hotplug/s390_pci_hpc.c - and some doc adjustments, too).
* It largely affects zPCI, the s390x specific PCI code layer.
* PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread.
* The situation described above affects the RoCE adapters only (Mellanox based).
* The patches are also upstream accepted and available via linux-next, but to apply them to focal kernel 5.4 the above backports are needed.
* However, the code is modified by several patches (12), hence there is a chance to break zPCI with them.
* For upfront testing a PPA got created with a focal (master-next) kernel that incl. all the above patches.
__________
Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter.
Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>
On s390x, each function is presented as individual root complex today, e.g.:
PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0
On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>. We need to use the same enumeration scheme to achieve this functionality on s390x.
In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.
Required result (example with 4 VFs per PF):
PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9
PCHID 0200 PF 0 0001:00:00.0 |
SRU Justification:
==================
[Impact]
* Mellanox CX5 port multi-pathing is broken on s390x due to non-standard topology of PCI IDs (phys. and virtual)
* The Mellanox Connect-X 5 PCI driver (mlx5) implements multi-path that can be used to combine multiple networking ports to improve performance and reliability.
* For that purpose, the mlx5 driver combines PCI functions based on topology information (the function number) as determined by their PCI ID.
* Currently the Linux on Z PCI bus does not reflect PCI topology information in the PCI ID. As a result, the mlx5 multi-path function is broken and cannot be activated.
[Fix]
* Backport 1: https://launchpadlibrarian.net/479699471/0001-s390-pci-Improve-handling-of-unset-UID.patch
* Backport 2: https://launchpadlibrarian.net/479699482/0002-s390-pci-embedding-hotplug_slot-in-zdev.patch
* Backport 3: https://launchpadlibrarian.net/479699492/0003-s390-pci-Expose-new-port-attribute-for-PCIe-function.patch
* Backport 4: https://launchpadlibrarian.net/479699497/0004-s390-pci-adaptation-of-iommu-to-multifunction.patch
* Backport 5: https://launchpadlibrarian.net/479700706/0005-s390-pci-define-kernel-parameters-for-PCI-multifunct.patch
* Backport 6: https://launchpadlibrarian.net/479700712/0006-s390-pci-define-RID-and-RID-available.patch
* Backport 7: https://launchpadlibrarian.net/479700739/0007-s390-pci-create-zPCI-bus.patch
* Backport 8: https://launchpadlibrarian.net/479700769/0008-s390-pci-adapt-events-for-zbus.patch
* Backport 9: https://launchpadlibrarian.net/479700786/0009-s390-pci-Handling-multifunctions.patch
* Backport 10: https://launchpadlibrarian.net/479700794/0010-s390-pci-Do-not-disable-PF-when-VFs-exist.patch
* Backport 11: https://launchpadlibrarian.net/479700798/0011-s390-pci-Documentation-for-zPCI.patch
* Backport 12: https://launchpadlibrarian.net/479700799/0012-s390-pci-removes-wrong-PCI-multifunction-assignment.patch
[Test Case]
* Prepare an IBM z13 or LinuxONE III (or newer) system with two or more RoCE Express PCI 2(.1) adapters.
* Assign the adapters (and it's virtual functions) to an LPAR.
* Verify whether the physical and virtual functions are grouped in arbitrary order or in consecutive order - physical first (for example with lspci -t ...)
[Regression Potential]
* The regression potential can be considered as moderate, since:
* It is purely s390x specific code (arch/s390/* drivers/iommu/s390-iommu.c and drivers/pci/hotplug/s390_pci_hpc.c - and some doc adjustments, too).
* It largely affects zPCI, the s390x specific PCI code layer.
* PCI cards available for s390x are optional cards (RoCE and zEDC) and not very wide-spread.
* The situation described above affects the RoCE adapters only (Mellanox based).
* The patches are also upstream accepted and available via linux-next, but to apply them to focal kernel 5.4 the above backports are needed.
* However, the code is modified by several patches (12), hence there is a chance to break zPCI with them.
* For upfront testing a PPA got created with a focal (master-next) kernel that incl. all the above patches.
__________
Today, the enumeration of PCI functions on s390x does not reflect which functions belongs to which physical adapter.
Layout of a PCI function address on Linux:
0000:00:00.0
<root complex>:<bus>:<device>.<function>
On s390x, each function is presented as individual root complex today, e.g.:
PCHID 0100 VF1 0000:00:00.0
PCHID 0100 VF23 0001:00:00.0
PCHID 0200 VF1 0002:00:00.0
OCHID 0100 VF17 0003:00:00.0
On other platforms, the addresses correctly reflect the actual HW configuration. Some device drivers (mlx5 for Mellanox adapters) group functions of one physical adapter by checking which PCI functions have identical values for <root complex>:<bus>:<device>. We need to use the same enumeration scheme to achieve this functionality on s390x.
In this case, the two physical functions of a Mellanox adapter need to get function number 0 and 1, and all virtual functions need to use the same <root complex>:<bus> numbers with function/device numbers counting up.
Required result (example with 4 VFs per PF):
PCHID 0100 PF 0 0000:00:00.0
PCHID 0100 PF 1 0000:00:00.1
PCHID 0100 PF 0 VF 0 0000:00:00.2
PCHID 0100 PF 0 VF 1 0000:00:00.3
PCHID 0100 PF 0 VF 2 0000:00:00.4
PCHID 0100 PF 0 VF 3 0000:00:00.5
PCHID 0100 PF 1 VF 0 0000:00:00.6
PCHID 0100 PF 1 VF 1 0000:00:00.7
PCHID 0100 PF 1 VF 2 0000:00:00.8
PCHID 0100 PF 1 VF 3 0000:00:00.9
PCHID 0200 PF 0 0001:00:00.0 |
|
| 2020-05-25 13:18:34 |
Stefan Bader |
nominated for series |
|
Ubuntu Focal |
|
| 2020-05-25 13:18:34 |
Stefan Bader |
bug task added |
|
linux (Ubuntu Focal) |
|
| 2020-05-25 13:18:51 |
Stefan Bader |
linux (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2020-05-25 13:18:51 |
Stefan Bader |
linux (Ubuntu Focal): status |
New |
In Progress |
|
| 2020-06-04 06:40:49 |
Khaled El Mously |
linux (Ubuntu Focal): status |
In Progress |
Fix Committed |
|
| 2020-06-04 07:12:47 |
Frank Heimes |
ubuntu-z-systems: status |
In Progress |
Fix Committed |
|
| 2020-06-10 17:42:05 |
Ubuntu Kernel Bot |
tags |
architecture-s39064 bugnameltc-184172 severity-high targetmilestone-inin2004 |
architecture-s39064 bugnameltc-184172 severity-high targetmilestone-inin2004 verification-needed-focal |
|
| 2020-06-12 08:05:11 |
Andrew Cloke |
tags |
architecture-s39064 bugnameltc-184172 severity-high targetmilestone-inin2004 verification-needed-focal |
architecture-s39064 bugnameltc-184172 severity-high targetmilestone-inin2004 verification-done-focal |
|
| 2020-07-01 10:25:25 |
Launchpad Janitor |
linux (Ubuntu Focal): status |
Fix Committed |
Fix Released |
|
| 2020-07-01 10:25:25 |
Launchpad Janitor |
cve linked |
|
2020-0543 |
|
| 2020-07-01 10:25:25 |
Launchpad Janitor |
cve linked |
|
2020-13143 |
|
| 2020-07-01 15:43:52 |
Frank Heimes |
nominated for series |
|
Ubuntu Groovy |
|
| 2020-07-01 15:43:52 |
Frank Heimes |
bug task added |
|
linux (Ubuntu Groovy) |
|
| 2020-07-28 00:57:39 |
Launchpad Janitor |
linux (Ubuntu Groovy): status |
In Progress |
Fix Released |
|
| 2020-07-28 00:57:39 |
Launchpad Janitor |
cve linked |
|
2019-16089 |
|
| 2020-07-28 00:57:39 |
Launchpad Janitor |
cve linked |
|
2019-19642 |
|
| 2020-07-28 00:57:39 |
Launchpad Janitor |
cve linked |
|
2020-11935 |
|
| 2020-07-28 05:54:46 |
Frank Heimes |
ubuntu-z-systems: status |
Fix Committed |
Fix Released |
|
