------- Comment From [email protected] 2021-01-20 10:02 EDT------- re: backporting of the qemu patches... I was planning to open a separate bug for this once we determined whether the kernel fix would actually get integrated into focal/groovy.
The primary difference from 5.2 and focal/groovy would be the state of the qemu build system as it went through some recent changes, so there may be some accomodation required to backport. The list you provided is mostly accurate. We can definitely skip: 84567ea763 update-linux-headers: Add vfio_zdev.h as this is for a different feature that integrated in the same pull request, not part of this bugfix And we might also be able to skip: 408b55db8b s390x/pci: Move header files to include/hw/s390x but this would require a minor header change to an include statment. Testing for the kernel alone is tricky (you need to create a vfio-pci device and then issue the VFIO_IOMMU_GET_INFO ioctl and validate that the DMA limit is included in the response -- I've used a custom QEMU build to do that). Creating a test when both kernel and QEMU changes are available is much easier (but does still require special PCI hardware like a mellanox adapter to pass through to the guest). -- 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/1907421 Title: [UBUNTU 21.04] vfio: pass DMA availability information to userspace Status in Ubuntu on IBM z Systems: Confirmed Status in linux package in Ubuntu: Fix Committed Status in linux source package in Focal: Confirmed Status in linux source package in Groovy: Incomplete Status in linux source package in Hirsute: Fix Committed Bug description: Description: vfio: pass DMA availability information to userspace Symptom: vfio-pci device on s390 enters error state Problem: Commit 492855939bdb added a limit to the number of concurrent DMA requests for a vfio container. However, lazy unmapping in s390 can in fact cause quite a large number of outstanding DMA requests to build up prior to being purged, potentially the entire guest DMA space. This results in unexpected errors seen in qemu such as 'VFIO_MAP_DMA failed: No space left on device' Solution: The solution requires a change to both kernel and qemu - For the kernel, add the ability to provide the number of allowable DMA requests via the VFIO_IOMMU_GET_INFO ioctl. Reproduction: Put a vfio-pci device on s390 under I/O load Upstream-ID: a717072007e8aedd3f951726d8cf55454860b30d 7d6e1329652ed971d1b6e0e7bea66fba5044e271 Need also to be integrated into 20.10 and 20.04. OK, just to clarify we don't need to fix bionic for this one, but rather focal (20.04) and groovy (20.10). Furthermore, for 20.04, 20.10 and 21.04 ONLY commit 7d6e1329652ed971d1b6e0e7bea66fba5044e271 is needed, the other was a pre-req that is already present. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1907421/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
