On 10/21/26 1:50 PM, Omar Elghoul wrote:
s390_pci_iommu_disable() destroys the I/O TLB and unpins the host's
mappings, but it doesn't account for reclaiming the freed DMA slots.
This is problematic when an IOMMU is disabled and re-enabled while
reusing the container (e.g. during a guest reboot), which may cause the
RPCIT path to fail with DMA slots exhaustion errors, manifesting as
unexplained ENOMEMs in the guest.
Fix it by reclaiming all the entries in the I/O TLB's hash table before
removing all its entries. The actual DMA slots consumed by the IOMMU are
already relinquished to vfio when the memory subregion is deleted in the
same function.
Cc: [email protected]
Fixes: 37fa32de7073 ("s390x/pci: Honor DMA limits set by vfio")
Signed-off-by: Omar Elghoul <[email protected]>
For context, this patch addresses the same issue as the patch linked
below [1], but after some internal discussion, it was decided that this
approach is safer than overwriting the container's max DMA limit and
current DMA usage every time an IOMMU gets disabled.
The reasoning is that multiple devices can, in theory at least, share
the same vfio container and IOMMU. This isn't true for zpci devices in
practice today, but the code is already built to handle that case.
[1]
https://lore.kernel.org/all/[email protected]/
