Messages in this thread | | | Subject | Re: [PATCH v3 02/10] swiotlb: Factor out slot allocation and free | From | Lu Baolu <> | Date | Thu, 2 May 2019 09:47:53 +0800 |
| |
Hi Robin,
On 4/30/19 5:53 PM, Robin Murphy wrote: > 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.
Yes, agreed.
Best regards, Lu Baolu
| |