[RFC V2 PATCH] dma-iommu: allow devices to set IOVA range dynamically

Christoph Hellwig hch at infradead.org
Tue Aug 11 01:49:12 EDT 2020


On Mon, Aug 10, 2020 at 11:28:12PM +0530, Ajay Kumar wrote:
> Currently, there is no other option to change the lower limit of
> IOVA for any device than calling iova_init_domain(), but the
> said function will re-init whole domain and also doesn't track
> the previously allocated IOVA before re-initing the domain.
> 
> There are cases where the device might not support continuous
> range of addresses, and can also have dependency among buffers
> allocated for firmware, image manipulation, etc and all of the
> address requests pass through IOMMU. In such cases, we can allocate
> buffers stage by stage by setting address limit, and also keep
> track the of same.
> 
> Bit of background can be found here:
> IOVA allocation dependency between firmware buffer and remaining buffers
> https://www.spinics.net/lists/iommu/msg43586.html
> 
> This patch allows devices to limit the IOVA space they want
> during allocation at any given point of time. We shall allow
> the same only if the device owns the corresponding iommu_domain,
> that is the device is the only master attached to the domain.
> 
> The lower limit of IOVA space is marked by start_pfn, and the upper
> limit is marked by dma_mask and this patch honors the same.
> Since changing dma_mask can extend the addressable region beyond
> current cached node, we do a reset of current cached nodes as well.
> 
> User drivers can make call sequence like below:
> ============================================================
> When they want to limit IOVA for allocated buffers in range
> 0x0 to 0x1000000:
> iommu_set_iova_range(dev, 0x0, 0x1000000 - 1);
> 
> When they want to limit IOVA for allocated buffers in range
> 0x1000000 to 0xC0000000:
> iommu_set_iova_range(dev, 0x1000000, 0xC0000000 - 0x1000000);
> =============================================================

This still seems to be missing an actual user of the functionality.



More information about the linux-arm-kernel mailing list