On 18/10/2023 23:54, Jason Gunthorpe wrote: > On Wed, Oct 18, 2023 at 09:27:06PM +0100, Joao Martins wrote: >> VFIO has an operation where it unmaps an IOVA while returning a bitmap with >> the dirty data. In reality the operation doesn't quite query the IO >> pagetables that the PTE was dirty or not. Instead it marks as dirty on >> anything that was mapped, and doing so in one syscall. >> >> In IOMMUFD the equivalent is done in two operations by querying with >> GET_DIRTY_IOVA followed by UNMAP_IOVA. However, this would incur two TLB >> flushes given that after clearing dirty bits IOMMU implementations require >> invalidating their IOTLB, plus another invalidation needed for the UNMAP. >> To allow dirty bits to be queried faster, add a flag >> (IOMMU_GET_DIRTY_IOVA_NO_CLEAR) that requests to not clear the dirty bits >> from the PTE (but just reading them), under the expectation that the next >> operation is the unmap. An alternative is to unmap and just perpectually >> mark as dirty as that's the same behaviour as today. So here equivalent >> functionally can be provided with unmap alone, and if real dirty info is >> required it will amortize the cost while querying. > > It seems fine, but I wonder is it really worthwhile? > Did you measure > this? I suppose it is during the critical outage window > Design-wise we avoid an extra IOTLB invalidation in emulated-vIOMMU with many potentially mappings being done ... which is where this usually is more relevant to be used. It bothers a little, if it falling under over-optimization when unmap itself is already expensive. But I didn't explicitly measure the cost of the IOTLB that we are saving. > Reviewed-by: Jason Gunthorpe <jgg@xxxxxxxxxx> > > Jason
