On 10/7/26 11:04 AM, Omar Elghoul wrote:
> s390_pci_iommu_disable() destroys the I/O TLB and unpins the host's
> mappings, but it doesn't reset the available DMA slot counter back to
> the VFIO-advertised limit. 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 slot exhaustion errors,
> manifesting as unexplained ENOMEMs in the guest.
>
> Fix it by refactoring s390_pci_update_dma_avail() to take a pointer to
> S390PCIBusDevice instead of the plain file descriptor. Call it in
> s390_pci_iommu_disable() after the host mappings have been unpinned.
>
> Further print a warning if the VFIO-advertised counter doesn't match the
> in-use shadow counter, to reduce the likelihood of introducing new
> similar DMA accounting bugs in the future.
>
Thanks for digging into this. Unfortunately it looks like this won't
apply after recent merges into master, can you please rebase for v2?
Also, one issue...
[...]
> -bool s390_pci_update_dma_avail(int fd, unsigned int *avail)
> +bool s390_pci_update_dma_avail(S390PCIBusDevice *pbdev, unsigned int *avail)
> {
> + VFIOPCIDevice *vpdev;
> uint32_t argsz = sizeof(struct vfio_iommu_type1_info);
> g_autofree struct vfio_iommu_type1_info *info = g_malloc0(argsz);
> + int fd;
>
> + assert(pbdev);
> assert(avail);
>
> + vpdev = VFIO_PCI_DEVICE(pbdev->pdev);
We can reach this for devices that are not associated with a vfio-pci
device (e.g. virtio-pci) and results in
/usr/src/qemu/hw/vfio/pci.h:123:VFIO_PCI_DEVICE: Object 0x2aa2d8a1410 is
not an instance of type vfio-pci-device
2026-10-15 16:44:18.851+0000: shutting down, reason=crashed
Thanks,
Matt
