On 30/04/2019 03:02, Lu Baolu wrote:
Hi Robin,
On 4/29/19 7:06 PM, Robin Murphy wrote:
On 29/04/2019 06:10, Lu Baolu wrote:
Hi Christoph,
On 4/26/19 11:04 PM, Christoph Hellwig wrote:
On Thu, Apr 25, 2019 at 10:07:19AM +0800, Lu Baolu wrote:
This is not VT-d specific. It's just how generic IOMMU works.
Normally, IOMMU works in paging mode. So if a driver issues DMA with
IOVA 0xAAAA0123, IOMMU can remap it with a physical address
0xBBBB0123.
But we should never expect IOMMU to remap 0xAAAA0123 with physical
address of 0xBBBB0000. That's the reason why I said that IOMMU will
not
work there.
Well, with the iommu it doesn't happen. With swiotlb it obviosuly
can happen, so drivers are fine with it. Why would that suddenly
become an issue when swiotlb is called from the iommu code?
I would say IOMMU is DMA remapping, not DMA engine. :-)
I'm not sure I really follow the issue here - if we're copying the
buffer to the bounce page(s) there's no conceptual difference from
copying it to SWIOTLB slot(s), so there should be no need to worry
about the original in-page offset.
From the reply up-thread I guess you're trying to include an
optimisation to only copy the head and tail of the buffer if it spans
multiple pages, and directly map the ones in the middle, but AFAICS
that's going to tie you to also using strict mode for TLB maintenance,
which may not be a win overall depending on the balance between
invalidation bandwidth vs. memcpy bandwidth. At least if we use
standard SWIOTLB logic to always copy the whole thing, we should be
able to release the bounce pages via the flush queue to allow 'safe'
lazy unmaps.
With respect, even we use the standard SWIOTLB logic, we need to use
the strict mode for TLB maintenance.
Say, some swiotbl slots are used by untrusted device for bounce page
purpose. When the device driver unmaps the IOVA, the slots are freed but
the mapping is still cached in IOTLB, hence the untrusted device is
still able to access the slots. Then the slots are allocated to other
devices. This makes it possible for the untrusted device to access
the data buffer of other devices.
Sure, that's indeed how it would work right now - however since the
bounce pages will be freed and reused by the DMA API layer itself (at
the same level as the IOVAs) I see no technical reason why we couldn't
investigate deferred freeing as a future optimisation.
Robin.
_______________________________________________
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
