Hi Joerg,
On 8/14/19 4:38 PM, Joerg Roedel wrote:
Hi Lu Baolu,
On Tue, Jul 30, 2019 at 12:52:26PM +0800, Lu Baolu wrote:
* iommu_bounce_map(dev, addr, paddr, size, dir, attrs)
- Map a buffer start at DMA address @addr in bounce page
manner. For buffer parts that doesn't cross a whole
minimal IOMMU page, the bounce page policy is applied.
A bounce page mapped by swiotlb will be used as the DMA
target in the IOMMU page table. Otherwise, the physical
address @paddr is mapped instead.
* iommu_bounce_unmap(dev, addr, size, dir, attrs)
- Unmap the buffer mapped with iommu_bounce_map(). The bounce
page will be torn down after the bounced data get synced.
* iommu_bounce_sync(dev, addr, size, dir, target)
- Synce the bounced data in case the bounce mapped buffer is
reused.
I don't really get why this API extension is needed for your use-case.
Can't this just be done using iommu_map/unmap operations? Can you please
elaborate a bit why these functions are needed?
iommu_map/unmap() APIs haven't parameters for dma direction and
attributions. These parameters are elementary for DMA APIs. Say,
after map, if the dma direction is TO_DEVICE and a bounce buffer is
used, we must sync the data from the original dma buffer to the bounce
buffer; In the opposite direction, if dma is FROM_DEVICE, before unmap,
we need to sync the data from the bounce buffer onto the original
buffer.
The code in these functions are common to all iommu drivers which want
to use bounce pages for untrusted devices. So I put them in the iommu.c.
Or, maybe drivers/iommu/dma-iommu.c is more suitable?
Best regards,
Lu Baolu
_______________________________________________
iommu mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/iommu
