Re: [PATCH v2 10/12] iommu: Make iommu_queue_iopf() more generic

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Aug 11, 2023 at 10:21:20AM +0800, Baolu Lu wrote:

> > This also has lifetime problems on the mm.
> > 
> > The domain should flow into the iommu_sva_handle_iopf() instead of the
> > void *data.
> 
> Okay, but I still want to keep void *data as a private pointer of the
> iopf consumer. For SVA, it's probably NULL.

I'd rather give the iommu_domain some 'private' void * than pass
around weird pointers all over the place... That might be broadly
useful, eg iommufd could store the hwpt in there.

> > We need to document/figure out some how to ensure that the faults are
> > all done processing before a fault enabled domain can be freed.
> 
> This has been documented in drivers/iommu/io-pgfault.c:
> 
> [...]
>  * Any valid page fault will be eventually routed to an iommu domain and the
>  * page fault handler installed there will get called. The users of this
>  * handling framework should guarantee that the iommu domain could only be
>  * freed after the device has stopped generating page faults (or the iommu
>  * hardware has been set to block the page faults) and the pending page
> faults
>  * have been flushed.
>  *
>  * Return: 0 on success and <0 on error.
>  */
> int iommu_queue_iopf(struct iommu_fault *fault, void *cookie)
> [...]
> 
> > This patch would be better ordered before the prior patch.
> 
> Let me try this in the next version.

Okay.. but can we have some debugging to enforce this maybe? Also add
a comment when we obtain the domain on this path to see the above
about the lifetime

Jason



[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux