Add a parameter to iommu_sva_unbind_device() that tells the IOMMU driver whether the PRI queue needs flushing. When looking at the PCIe spec again I noticed that most of the time the SMMUv3 driver doesn't actually need to flush the PRI queue. Does this make sense for Intel VT-d as well or did I overlook something? Before calling iommu_sva_unbind_device(), device drivers must stop the device from using the PASID. For PCIe devices, that consists of completing any pending DMA, and completing any pending page request unless the device uses Stop Markers. So unless the device uses Stop Markers, we don't need to flush the PRI queue. For SMMUv3, stopping DMA means completing all stall events, so we never need to flush the event queue. First patch adds flags to unbind(), and the second one lets device drivers tell whether the PRI queue needs to be flushed. Other remarks: * The PCIe spec (see quote on patch 2), says that the device signals whether it has sent a Stop Marker or not during Stop PASID. In reality it's unlikely that a given device will sometimes use one stop method and sometimes the other, so it could be a device-wide flag rather than passing it at each unbind(). I don't want to speculate too much about future implementation so I prefer having the flag in unbind(). * In patch 1, uacce passes 0 to unbind(). To pass the right flag I'm thinking that uacce->ops->stop_queue(), which tells the device driver to stop DMA, should return whether faults are pending. This can be added later once uacce has an actual PCIe user, but we need to remember to do it. Jean-Philippe Brucker (2): iommu: Add flags to sva_unbind() iommu: Add IOMMU_UNBIND_FAULT_PENDING flag include/linux/intel-iommu.h | 2 +- include/linux/iommu.h | 38 ++++++++++++++++++++++++++++++++++--- drivers/iommu/intel/svm.c | 10 ++++++---- drivers/iommu/iommu.c | 10 +++++++--- drivers/misc/uacce/uacce.c | 4 ++-- 5 files changed, 51 insertions(+), 13 deletions(-) -- 2.28.0
