Messages in this thread | | | Date | Wed, 23 Aug 2017 14:09:07 +0200 | From | Joerg Roedel <> | Subject | Re: [PATCH 00/13] Introduce IOMMU-API TLB Flushing Interface |
| |
On Thu, Aug 17, 2017 at 05:22:20PM +0200, Joerg Roedel wrote: > What I absolutly don't want is that the whole explicit TLB flushing > of the IOMMU-API (as introduced in this patch-set) is considered some > optional part of the API, as it would be when I just introduce _async > versions of map/unmap/map_sg.
Okay, forget that :)
The discussions I had around this interface made me change it a little bit in the version 2 of the patch-set which I will post soon.
I thought a bit more about the iommu_map() code-path. It really doesn't make any sense to remove the tlb-sync requirement from it, because in almost all cases the hardware doesn't require any flushes after a map operation anyway. And in the rare cases where it does - because the hardware is emulated and slow - the iommu-driver can handle that by doing a flush in its iommu_ops->map() call-back.
So I removed the iommu_map_sync() and iommu_map_sg_sync() functions from this series. With those changes it also doesn't make sense anymore to have different tlb-sync semantics between iommu_map() and iommu_unmap(). So I ended up introducing a new iommu_unmap_fast() function which can unmap ranges and return with dirty io-tlbs.
This makes the extension of couse look somewhat optional, which I tried to avoid, but I hope the '_fast' part of the name is enough motivation for iommu-api users to look into ways to use it in their code.
Regards,
Joerg
| |