[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-pci
Subject:    Re: Explicit IOVA management from a PCIe endpoint driver
From:       Stephen Warren <swarren () wwwdotorg ! org>
Date:       2018-09-28 20:39:36
Message-ID: 4dc0ffa8-7b16-9063-2aba-b8249a09885f () wwwdotorg ! org
[Download RAW message or body]

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.
[prev in list] [next in list] [prev in thread] [next in thread]