[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Changed in: ubuntu-z-systems Status: Fix Committed => Fix Released -- 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 Released Status in linux package in Ubuntu: Fix Released Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Fix Released 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//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//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/20200506154
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
This bug was fixed in the package linux - 5.4.0-42.46 --- linux (5.4.0-42.46) focal; urgency=medium * focal/linux: 5.4.0-42.46 -proposed tracker (LP: #1887069) * linux 4.15.0-109-generic network DoS regression vs -108 (LP: #1886668) - SAUCE: Revert "netprio_cgroup: Fix unlimited memory leak of v2 cgroups" linux (5.4.0-41.45) focal; urgency=medium * focal/linux: 5.4.0-41.45 -proposed tracker (LP: #1885855) * Packaging resync (LP: #1786013) - update dkms package versions * CVE-2019-19642 - kernel/relay.c: handle alloc_percpu returning NULL in relay_open * CVE-2019-16089 - SAUCE: nbd_genl_status: null check for nla_nest_start * CVE-2020-11935 - aufs: do not call i_readcount_inc() * ip_defrag.sh in net from ubuntu_kernel_selftests failed with 5.0 / 5.3 / 5.4 kernel (LP: #1826848) - selftests: net: ip_defrag: ignore EPERM * Update lockdown patches (LP: #1884159) - SAUCE: acpi: disallow loading configfs acpi tables when locked down * seccomp_bpf fails on powerpc (LP: #1885757) - SAUCE: selftests/seccomp: fix ptrace tests on powerpc * Introduce the new NVIDIA 418-server and 440-server series, and update the current NVIDIA drivers (LP: #1881137) - [packaging] add signed modules for the 418-server and the 440-server flavours -- Khalid Elmously Thu, 09 Jul 2020 19:50:26 -0400 ** Changed in: linux (Ubuntu Groovy) Status: In Progress => Fix Released ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-16089 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2019-19642 ** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2020-11935 -- 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: Fix Released Status in linux source package in Focal: Fix Released Status in linux source package in Groovy: Fix Released 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//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 need
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
This bug was fixed in the package linux - 5.4.0-40.44 --- linux (5.4.0-40.44) focal; urgency=medium * linux-oem-5.6-tools-common and -tools-host should be dropped (LP: #1881120) - [Packaging] Add Conflicts/Replaces to remove linux-oem-5.6-tools-common and -tools-host * Packaging resync (LP: #1786013) - [Packaging] update helper scripts * Slow send speed with Intel I219-V on Ubuntu 18.04.1 (LP: #1802691) - e1000e: Disable TSO for buffer overrun workaround * CVE-2020-0543 - UBUNTU/SAUCE: x86/speculation/srbds: do not try to turn mitigation off when not supported * Realtek 8723DE [10ec:d723] subsystem [10ec:d738] disconnects unsolicitedly when Bluetooth is paired: Reason: 23=IEEE8021X_FAILED (LP: #1878147) - SAUCE: Revert "UBUNTU: SAUCE: rtw88: Move driver IQK to set channel before association for 11N chip" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: fix rate for a while after being connected" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: No retry and report for auth and assoc" - SAUCE: Revert "UBUNTU: SAUCE: rtw88: 8723d: Add coex support" - rtw88: add a debugfs entry to dump coex's info - rtw88: add a debugfs entry to enable/disable coex mechanism - rtw88: 8723d: Add coex support - SAUCE: rtw88: coex: 8723d: set antanna control owner - SAUCE: rtw88: coex: 8723d: handle BT inquiry cases - SAUCE: rtw88: fix EAPOL 4-way failure by finish IQK earlier * CPU stress test fails with focal kernel (LP: #1867900) - [Config] Disable hisi_sec2 temporarily * Enforce all config annotations (LP: #1879327) - [Config]: do not enforce CONFIG_VERSION_SIGNATURE - [Config]: prepare to enforce all - [Config]: enforce all config options * Focal update: v5.4.44 upstream stable release (LP: #1881927) - ax25: fix setsockopt(SO_BINDTODEVICE) - dpaa_eth: fix usage as DSA master, try 3 - net: don't return invalid table id error when we fall back to PF_UNSPEC - net: dsa: mt7530: fix roaming from DSA user ports - net: ethernet: ti: cpsw: fix ASSERT_RTNL() warning during suspend - __netif_receive_skb_core: pass skb by reference - net: inet_csk: Fix so_reuseport bind-address cache in tb->fast* - net: ipip: fix wrong address family in init error path - net/mlx5: Add command entry handling completion - net: mvpp2: fix RX hashing for non-10G ports - net: nlmsg_cancel() if put fails for nhmsg - net: qrtr: Fix passing invalid reference to qrtr_local_enqueue() - net: revert "net: get rid of an signed integer overflow in ip_idents_reserve()" - net sched: fix reporting the first-time use timestamp - net/tls: fix race condition causing kernel panic - nexthop: Fix attribute checking for groups - r8152: support additional Microsoft Surface Ethernet Adapter variant - sctp: Don't add the shutdown timer if its already been added - sctp: Start shutdown on association restart if in SHUTDOWN-SENT state and socket is closed - tipc: block BH before using dst_cache - net/mlx5e: kTLS, Destroy key object after destroying the TIS - net/mlx5e: Fix inner tirs handling - net/mlx5: Fix memory leak in mlx5_events_init - net/mlx5e: Update netdev txq on completions during closure - net/mlx5: Fix error flow in case of function_setup failure - net/mlx5: Annotate mutex destroy for root ns - net/tls: fix encryption error checking - net/tls: free record only on encryption error - net: sun: fix missing release regions in cas_init_one(). - net/mlx4_core: fix a memory leak bug. - mlxsw: spectrum: Fix use-after-free of split/unsplit/type_set in case reload fails - ARM: dts: rockchip: fix phy nodename for rk3228-evb - ARM: dts: rockchip: fix phy nodename for rk3229-xms6 - arm64: dts: rockchip: fix status for &gmac2phy in rk3328-evb.dts - arm64: dts: rockchip: swap interrupts interrupt-names rk3399 gpu node - ARM: dts: rockchip: swap clock-names of gpu nodes - ARM: dts: rockchip: fix pinctrl sub nodename for spi in rk322x.dtsi - gpio: tegra: mask GPIO IRQs during IRQ shutdown - ALSA: usb-audio: add mapping for ASRock TRX40 Creator - net: microchip: encx24j600: add missed kthread_stop - gfs2: move privileged user check to gfs2_quota_lock_check - gfs2: Grab glock reference sooner in gfs2_add_revoke - drm/amdgpu: drop unnecessary cancel_delayed_work_sync on PG ungate - drm/amd/powerplay: perform PG ungate prior to CG ungate - drm/amdgpu: Use GEM obj reference for KFD BOs - cachefiles: Fix race between read_waiter and read_copier involving op->to_do - usb: dwc3: pci: Enable extcon driver for Intel Merrifield - usb: phy: twl6030-usb: Fix a resource leak in an error handling path in 'twl6030_usb_probe()' - usb: gadget: legacy: fix redundant initialization warnings - net: freescale: select CONFIG_FIXED_PHY where needed - IB/i40iw: Remo
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
Many thanks for verifying. Adjusting tags. ** Tags removed: verification-needed-focal ** Tags added: verification-done-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//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//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)
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
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//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
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Changed in: ubuntu-z-systems Status: In Progress => Fix Committed -- 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//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//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/202005061541
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Changed in: linux (Ubuntu Focal) Status: In Progress => Fix Committed -- 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//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//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/20200506
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Also affects: linux (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Groovy) Importance: High Assignee: Canonical Kernel Team (canonical-kernel-team) Status: In Progress ** Changed in: linux (Ubuntu Focal) Status: New => In Progress -- 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: In Progress Status in linux package in Ubuntu: In Progress Status in linux source package in Focal: In Progress 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//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//sriov_numvfs Previously this could leave the card in an unresponsive error
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
For further assessment of potential regression, here is a reference to the upstream discussion with upstream maintainer Bjorn: https://lkml.org/lkml/2020/5/6/837 and especially his statement (https://lkml.org/lkml/2020/5/6/1252): >>This whole thing is not "introducing" any new functionality; it's >>"refactoring" to move existing functionality around and make it callable >>separately.<< -- 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: In Progress Status in linux package in Ubuntu: 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//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//sriov_numvfs Previously this could leave the card in an unresponsive error state. The patch
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
Kernel SRU request submitted: https://lists.ubuntu.com/archives/kernel-team/2020-June/thread.html#110753 Updating status to 'In Progress'. ** Changed in: linux (Ubuntu) Importance: Undecided => High ** Changed in: ubuntu-z-systems Importance: Undecided => High ** Changed in: linux (Ubuntu) Status: Triaged => In Progress ** Changed in: ubuntu-z-systems Status: Triaged => In Progress -- 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: In Progress Status in linux package in Ubuntu: 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//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//sriov_numvfs Previously this could leave the card in an unresponsive error st
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
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//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//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.90
[Kernel-packages] [Bug 1879704] Re: [UBUNTU 20.04] s390x/pci: fix linking between PF and VF for multifunction devices
** Summary changed: - [UBUNTU 20.04] s390x/pci: implement linking between PF and VF for multifunction devices + [UBUNTU 20.04] s390x/pci: fix 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 + architectures, 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. + * 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//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. + * 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. Everything else is s390x specific. + 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. [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 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! + * 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: