Hi Ashok, On 17 November 2017 at 00:52, Raj, Ashok <[email protected]> wrote: > On Thu, Nov 16, 2017 at 12:20:47PM +0200, nick klingsman wrote: >> * Note: Please 'CC'/Reply my email as I'm not subscribed to the list yet. >> >> Hi, >> >> During __iommu_flush_iotlb() we set the WD (WriteDrain) bit if the >> iommu supports cap_write_drain(). This part of the logic exists from >> day one of the code and later even added to QI logic. >> >> Back than, when we dma_unmap_xxx() we 'synchronically' did the >> iommu_flush() and within it the the Write-Drain logic. >> >> However, today, we do a batch-flush which means that all/most calls >> to dma_unmap() don't perform the Write-Drain. >> >> Questions: >> >> 1. If WD is a must, how come the batch-flush doesn't cause any memory >> corruption ? For example: >> a. dma_map_page(100, from_device) >> b. Device writes data to device >> c. dma_unmap_page() -> batched and not sync-flushed >> d. Possible BUG ? Data read before the write is drained can be stale ? > > __iommu_flush_iotlb() will do DMA_TLB_WRITE_DRAIN.. so that's actually > done even in the batched more.
That's the point.. this is not 'batched' mode. Its "deferred" mode. the flush occurs *async* to the dma_unmap() call by the driver. In my example, after the dma_unmap() @ 'c', the flush didn't yet occured and so is the Write Drain request. > >> >> 2. If WD is not needed, why do we do it ? Why do we effect IOMMU work >> with unneeded actions (in the most critical fast path of map/unmap) ? >> >> >> Thanks, >> Nick >> _______________________________________________ >> iommu mailing list >> [email protected] >> https://lists.linuxfoundation.org/mailman/listinfo/iommu _______________________________________________ iommu mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/iommu
