Re: [RFC PATCH 0/3] iommu: Add range flush operation

From: Joerg Roedel
Date: Tue Sep 29 2015 - 08:20:18 EST

Hi Tomasz,

On Tue, Sep 29, 2015 at 02:25:23PM +0900, Tomasz Figa wrote:
> This series tries to mitigate the two issues above, while acknowledging
> the fact that the .map_sg() callback might be still necessary for some
> specific platforms, which could have the need to iterate over SG elements
> inside driver code. Proposed solution introduces a new .flush() callback,
> which expects IOVA range as its argument and is expected to flush all
> respective caches (be it CPU, IOMMU TLB or whatever) to make the given
> IOVA area mapping change visible to IOMMU clients. Then all the 3 basic
> map/unmap operations are modified to call the .flush() callback at the end
> of the operation.
> Advantages of proposed approach include:
> 1) ability to use default_iommu_map_sg() helper if all the driver needs
> for performance optimization is batching the flush,
> 2) completely no effect on existing code - the .flush() callback is made
> optional and if it isn't implemented drivers are expected to do
> necessary flushes on a page by page basis in respective (un)mapping
> callbakcs,
> 3) possibility of exporting the iommu_flush() operation and providing
> unsynchronized map/unmap operations for subsystems with even higher
> requirements for performance (e.g. drivers/gpu/drm).

Thanks for the patches, I really like the idea. The VT-d driver probably
also benefits a lot from this.

In the past I also proposed something like this, it was called a new
iommu_commit() API function for making changes from map/unmap visible to
the hardware. But this requires updating all callers first, so your
approach of doing an implicit flush at the end of map/unmap is better.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at