On Fri, Aug 11, 2023 at 09:53:41AM +0800, Baolu Lu wrote:
On 2023/8/11 0:47, Jason Gunthorpe wrote:Yes, that could be true, iommufd could just queue it from the
On Thu, Aug 10, 2023 at 02:35:40AM +0000, Tian, Kevin wrote:I am still confused. When we forward iopf's to user space through the
Yeah, that is one path. Do we have anyone that uses this that doesn'tFrom: Baolu Lu<baolu.lu@xxxxxxxxxxxxxxx>My understanding of Jason's comment was to make the workqueue the
Sent: Wednesday, August 9, 2023 6:41 PM
On 2023/8/9 8:02, Tian, Kevin wrote:
shouldFrom: 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
Do you mind elaborate a bit here? workqueue is a basic infrastructure inthen this series needs more work. Currently the abstraction doesn'tbe void.I think more than just SVA will need a work queue context to process
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.
their faults.
include workqueue in the common fault reporting layer.
the fault handling framework, but it lets the consumers choose to use
it, or not to.
default path instead of being opted by the consumer.. that is my 1st
impression but might be wrong...
want the WQ? (actually who even uses this besides SVA?)
iommufd, we don't need to schedule a WQ, right? Or I misunderstood
here?
interrupt context and trigger a wakeup.
But other iommufd modes would want to invoke hmm_range_fault() which
would need the work queue.