Re: Intel-iommu: Possible memory corruption due to deferred iommu flush

["Raj, Ashok" <ashok.raj-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

Hi Nick

On Fri, Nov 17, 2017 at 01:57:19AM +0200, nick klingsman wrote:
> 
> Oh - now I understand the confusion. Although the subject said 'deferred'
> I used the word 'Batched' in the email body. I meant 'deferred'. Not batching.
> If it was only batching, than it would make sens as 'Ashok' pointed out.
> 
> >
> >>
> >>>
> >>> 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) ?

The purpose of WRITE_DRAIN is something like this.. 

If you had a buffer that DMA writes are still happening but the entity using
the buffer has been terminated. You are just looking to ensure that before you
reallocate the buffer to another entity that the old writes aren't still
happening.

When we do the dma_unmap() that would get rid of the mappings and an iotlb 
flush would ensure any future access the DMA would fail. WRITE_DRAIN ensures
any address already translated and DMA is in progress completes. 

In the batched mode when we delay performing the iotlb invalidations + 
write_drain, the I/O is completed and driver was notified earlier. As
part of tracking the I/O completion the driver would have read some mmio
on the device that would have caused all the outstanding writes from the
device written to memory. So the buffer in this case is all globally 
observable by the consumer.. so there is no stale state for that DMA that 
has properly completed. In these cases the WD is probaly not required, but 
we have the same path for all invalidations so its simple to do it for 
consistency.



Hope this helps.

Cheers,
Ashok