When s390_pci_update_iotlb() does a mapping update for an IOVA that has an already-existing TLB entry with different permissions or translated address, it unmaps then remaps it. However, at the end of the map path, it unconditionally decrements the available DMA slot counter without a corresponding increment in the intermediate unmap branch.
This causes the DMA slot count to be decremented on every remapping of an active IOVA, leading to a permanent DMA slot leak. This remapping without a prior invalidation and sync is not seen today in well-behaved guests but is allowed by the architecture. Fix it by only decrementing available DMA slots when inserting a brand new mapping. Cc: [email protected] Fixes: 37fa32de70 ("s390x/pci: Honor DMA limits set by vfio") Signed-off-by: Omar Elghoul <[email protected]> --- hw/s390x/s390-pci-inst.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/hw/s390x/s390-pci-inst.c b/hw/s390x/s390-pci-inst.c index b7de23c7d2..5840675aba 100644 --- a/hw/s390x/s390-pci-inst.c +++ b/hw/s390x/s390-pci-inst.c @@ -665,6 +665,9 @@ static uint32_t s390_pci_update_iotlb(S390PCIIOMMU *iommu, memory_region_notify_iommu(&iommu->iommu_mr, 0, event); event.type = IOMMU_NOTIFIER_MAP; event.entry.perm = entry->perm; + } else { + /* only new mappings consume DMA slots */ + dec_dma_avail(iommu); } cache = g_new(S390IOTLBEntry, 1); @@ -673,7 +676,6 @@ static uint32_t s390_pci_update_iotlb(S390PCIIOMMU *iommu, cache->len = TARGET_PAGE_SIZE; cache->perm = entry->perm; g_hash_table_replace(iommu->iotlb, &cache->iova, cache); - dec_dma_avail(iommu); } /* -- 2.55.0
