On 2023/8/30 16:50, Tian, Kevin wrote:
From: Tian, Kevin
Sent: Wednesday, August 30, 2023 3:44 PM
From: Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx>
Sent: Saturday, August 26, 2023 4:01 PM
On 8/25/23 4:17 PM, Tian, Kevin wrote:
+
/**
* iopf_queue_flush_dev - Ensure that all queued faults have been
processed
* @dev: the endpoint whose faults need to be flushed.
Presumably we also need a flush callback per domain given now
the use of workqueue is optional then flush_workqueue() might
not be sufficient.
The iopf_queue_flush_dev() function flushes all pending faults from the
IOMMU queue for a specific device. It has no means to flush fault queues
out of iommu core.
The iopf_queue_flush_dev() function is typically called when a domain is
detaching from a PASID. Hence it's necessary to flush the pending faults
from top to bottom. For example, iommufd should flush pending faults in
its fault queues after detaching the domain from the pasid.
Is there an ordering problem? The last step of intel_svm_drain_prq()
in the detaching path issues a set of descriptors to drain page requests
and responses in hardware. It cannot complete if not all software queues
are drained and it's counter-intuitive to drain a software queue after
the hardware draining has already been completed.
to be clear it's correct to drain request queues from bottom to top as the
lower level queue is the input to the higher level queue. But for response
the lowest draining needs to wait for response from higher levels. It's
interesting that intel-iommu driver combines draining hw page requests
and responses in one step in intel_svm_drain_prq(). this also needs some
consideration regarding to iommufd...
I agree with you. For the responses, we can iterate over the list of
page requests pending to respond. If any fault matches the pasid and the
device, we can drain it by responding IOMMU_PAGE_RESP_INVALID to the
device.
After that the responses for the drained faults will be dropped by the
iommu_page_response() interface.
Best regards,
baolu
