On 09/18/2018 12:16 PM, Stephen Warren wrote:
On 09/18/2018 04:59 AM, Robin Murphy wrote:
Hi Stephen,
On 17/09/18 22:36, Stephen Warren wrote:
Joerg, Christoph, Marek, Robin,
I believe that the driver for our PCIe endpoint controller hardware
will need to explicitly manage its IOVA space more than current APIs
allow. I'd like to discuss how to make that possible.
...
Does this API proposal sound reasonable?
Indeed, as I say apart from using streaming DMA for coherency
management (which I think could be added in pretty much orthogonally
later), this sounds like something you could plumb into the endpoint
framework right now with no dependent changes elsewhere.
Great. I'll take a look at Oza's code and see about getting this
implemented.
I took a longer look at the various APIs in iommu.h and dma-iommh.h. As
you said, I think most of it is already there. I think we just need to
add functions iommu_dma_alloc/free_iova() [1] that drivers can call to
acquire an IOVA range that is guaranteed not be used by any other device
that shares the same IOVA domain (i.e. IOMMU ASID). After the driver
calls that, it can just use iommu_map() and iommu_map_sg() on the IOVA
range that was reserved. Does that sound reasonable?
[1] there's already a static function of that name for internal use in
dma-iommu.c. I guess I'd rename that to __iommu_dma_alloc_iova() and
have the new function be a thin wrapper on top of it.
