Re: [PATCH v2 08/12] iommu: Prepare for separating SVA and IOPF

From: Baolu Lu
Date: Sun Aug 13 2023 - 07:20:03 EST


On 2023/8/11 21:27, Jason Gunthorpe wrote:
On Fri, Aug 11, 2023 at 09:53:41AM +0800, Baolu Lu wrote:
On 2023/8/11 0:47, Jason Gunthorpe wrote:
On Thu, Aug 10, 2023 at 02:35:40AM +0000, Tian, Kevin wrote:
From: Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx>
Sent: Wednesday, August 9, 2023 6:41 PM

On 2023/8/9 8:02, Tian, Kevin wrote:
From: Jason Gunthorpe<jgg@xxxxxxxx>
Sent: Wednesday, August 9, 2023 2:43 AM

On Thu, Aug 03, 2023 at 08:16:47AM +0000, Tian, Kevin wrote:

Is there plan to introduce further error in the future? otherwise this
should
be void.

btw the work queue is only for sva. If there is no other caller this can be
just kept in iommu-sva.c. No need to create a helper.
I think more than just SVA will need a work queue context to process
their faults.

then this series needs more work. Currently the abstraction doesn't
include workqueue in the common fault reporting layer.
Do you mind elaborate a bit here? workqueue is a basic infrastructure in
the fault handling framework, but it lets the consumers choose to use
it, or not to.

My understanding of Jason's comment was to make the workqueue the
default path instead of being opted by the consumer.. that is my 1st
impression but might be wrong...
Yeah, that is one path. Do we have anyone that uses this that doesn't
want the WQ? (actually who even uses this besides SVA?)
I am still confused. When we forward iopf's to user space through the
iommufd, we don't need to schedule a WQ, right? Or I misunderstood
here?
Yes, that could be true, iommufd could just queue it from the
interrupt context and trigger a wakeup.

But other iommufd modes would want to invoke hmm_range_fault() which
would need the work queue.

Yes. That's the reason why I added below helper

int iopf_queue_work(struct iopf_group *group, work_func_t func)

in the patch 09/12.

Best regards,
baolu