Re: [PATCH v3 0/2] iommu/virtio: Enable IOMMU_CAP_DERRED_FLUSH

Hi Niklas, On Mon, Nov 20, 2023 at 03:51:55PM +0100, Niklas Schnelle wrote: > Hi All, > > Previously I used virtio-iommu as a non-s390x test vehicle[0] for the > single queue flushing scheme introduced by my s390x DMA API conversion > series[1]. For this I modified virtio-iommu to a) use .iotlb_s

[PATCH v3 2/2] iommu/virtio: Add ops->flush_iotlb_all and enable deferred flush

Add ops->flush_iotlb_all operation to enable virtio-iommu for the dma-iommu deferred flush scheme. This results in a significant increase in performance in exchange for a window in which devices can still access previously IOMMU mapped memory when running with CONFIG_IOMMU_DEFAULT_DMA_LAZY. The pre

[PATCH v3 0/2] iommu/virtio: Enable IOMMU_CAP_DERRED_FLUSH

Hi All, Previously I used virtio-iommu as a non-s390x test vehicle[0] for the single queue flushing scheme introduced by my s390x DMA API conversion series[1]. For this I modified virtio-iommu to a) use .iotlb_sync_map and b) enable IOMMU_CAP_DEFERRED_FLUSH. It turned out that deferred flush and e

[PATCH v3 1/2] iommu/virtio: Make use of ops->iotlb_sync_map

Pull out the sync operation from viommu_map_pages() by implementing ops->iotlb_sync_map. This allows the common IOMMU code to map multiple elements of an sg with a single sync (see iommu_map_sg()). Link: https://lore.kernel.org/lkml/20230726111433.1105665-1-schne...@linux.ibm.com/ Signed-off-by: