Hi Jacob,
On Mon, Apr 25, 2022 at 08:34:44AM -0700, Jacob Pan wrote:
Hi Jean-Philippe,Yes we do have that state, though I'm not sure we need to make it explicit
On Mon, 25 Apr 2022 15:26:40 +0100, Jean-Philippe Brucker
<jean-philippe@xxxxxxxxxx> wrote:
On Mon, Apr 25, 2022 at 07:18:36AM -0700, Dave Hansen wrote:For VT-d, it is essentially the same flow except managed by the individual
On 4/25/22 06:53, Jean-Philippe Brucker wrote:In the case of uacce, it's tied to the fd lifetime: opening an accelerator
On Sat, Apr 23, 2022 at 07:13:39PM +0800, zhangfei.gao@xxxxxxxxxxxYeah, this is a bit gnarly for -rc4. Let's just make sure there's
wrote:
Yes indirectly I think: when the process mmaps the queue,Looks it is caused by the fix patch, via mmget, which may addOn 5.17Right that's weird
fops_release is called automatically, as well as
iommu_sva_unbind_device. On 5.18-rc1.
fops_release is not called, have to manually call close(fd)
refcount of fd.
mmap_region() takes a reference to the uacce fd. That reference is
released either by explicit close() or munmap(), or by exit_mmap()
(which is triggered by mmput()). Since there is an mm->fd dependency,
we cannot add a fd->mm dependency, so no mmget()/mmput() in
bind()/unbind().
I guess we should go back to refcounted PASIDs instead, to avoid
freeing them until unbind().
nothing else simple we can do.
How does the IOMMU hardware know that all activity to a given PASID is
finished? That activity should, today, be independent of an mm or a
fd's lifetime.
queue calls iommu_sva_bind_device(), which sets up the PASID context in
the IOMMU. Closing the queue calls iommu_sva_unbind_device() which
destroys the PASID context (after the device driver stopped all DMA for
this PASID).
drivers such as DSA.
If free() happens before unbind(), we deactivate the PASIDs and suppress
faults from the device. When the unbind finally comes, we finalize the
PASID teardown. It seems we have a need for an intermediate state where
PASID is "pending free"?
in the ioasid allocator.
Could we move mm_pasid_drop() to __mmdrop() instead of __mmput()? For Arm
we do need to hold the mm_count until unbind(), and mmgrab()/mmdrop() is
also part of Lu's rework [1].
Thanks,
Jean
[1] https://lore.kernel.org/linux-iommu/20220421052121.3464100-9-baolu.lu@xxxxxxxxxxxxxxx/