RE: [PATCH v4 09/10] iommu: Make iommu_queue_iopf() more generic

From: Tian, Kevin
Date: Thu Aug 31 2023 - 22:49:36 EST


> From: Baolu Lu <baolu.lu@xxxxxxxxxxxxxxx>
> Sent: Thursday, August 31, 2023 5:28 PM
>
> On 2023/8/30 15:43, Tian, Kevin wrote:
> >> 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.
> >
> > btw just flushing requests is probably insufficient in iommufd case since
> > the responses are received asynchronously. It requires an interface to
> > drain both requests and responses (presumably with timeouts in case
> > of a malicious guest which never responds) in the detach path.
>
> You are right. Good catch.
>
> To put it simply, iopf_queue_flush_dev() is insufficient to support the
> case of forwarding iopf's over iommufd. Do I understand it right?

yes

>
> Perhaps we should drain the partial list and the response pending list?
> With these two lists drained, no more iopf's for the specific pasid will
> be forwarded up, and page response from upper layer will be dropped.
>

correct.