[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20260120133357.GT13201@unreal>
Date: Tue, 20 Jan 2026 15:33:57 +0200
From: Leon Romanovsky <leon@...nel.org>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: Sumit Semwal <sumit.semwal@...aro.org>,
Christian König <christian.koenig@....com>,
Alex Deucher <alexander.deucher@....com>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Gerd Hoffmann <kraxel@...hat.com>,
Dmitry Osipenko <dmitry.osipenko@...labora.com>,
Gurchetan Singh <gurchetansingh@...omium.org>,
Chia-I Wu <olvaffe@...il.com>,
Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Maxime Ripard <mripard@...nel.org>,
Thomas Zimmermann <tzimmermann@...e.de>,
Lucas De Marchi <lucas.demarchi@...el.com>,
Thomas Hellström <thomas.hellstrom@...ux.intel.com>,
Rodrigo Vivi <rodrigo.vivi@...el.com>,
Kevin Tian <kevin.tian@...el.com>, Joerg Roedel <joro@...tes.org>,
Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
Alex Williamson <alex@...zbot.org>, linux-media@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linaro-mm-sig@...ts.linaro.org,
linux-kernel@...r.kernel.org, amd-gfx@...ts.freedesktop.org,
virtualization@...ts.linux.dev, intel-xe@...ts.freedesktop.org,
linux-rdma@...r.kernel.org, iommu@...ts.linux.dev,
kvm@...r.kernel.org
Subject: Re: [PATCH v2 3/4] iommufd: Require DMABUF revoke semantics
On Tue, Jan 20, 2026 at 09:15:30AM -0400, Jason Gunthorpe wrote:
> On Tue, Jan 20, 2026 at 03:10:46PM +0200, Leon Romanovsky wrote:
> > On Mon, Jan 19, 2026 at 03:54:44PM -0400, Jason Gunthorpe wrote:
> > > On Mon, Jan 19, 2026 at 08:23:00PM +0200, Leon Romanovsky wrote:
> > > > On Mon, Jan 19, 2026 at 12:59:51PM -0400, Jason Gunthorpe wrote:
> > > > > On Sun, Jan 18, 2026 at 02:08:47PM +0200, Leon Romanovsky wrote:
> > > > > > From: Leon Romanovsky <leonro@...dia.com>
> > > > > >
> > > > > > IOMMUFD does not support page fault handling, and after a call to
> > > > > > .invalidate_mappings() all mappings become invalid. Ensure that
> > > > > > the IOMMUFD DMABUF importer is bound to a revoke‑aware DMABUF exporter
> > > > > > (for example, VFIO).
> > > > > >
> > > > > > Signed-off-by: Leon Romanovsky <leonro@...dia.com>
> > > > > > ---
> > > > > > drivers/iommu/iommufd/pages.c | 9 ++++++++-
> > > > > > 1 file changed, 8 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/iommu/iommufd/pages.c b/drivers/iommu/iommufd/pages.c
> > > > > > index 76f900fa1687..a5eb2bc4ef48 100644
> > > > > > --- a/drivers/iommu/iommufd/pages.c
> > > > > > +++ b/drivers/iommu/iommufd/pages.c
> > > > > > @@ -1501,16 +1501,22 @@ static int iopt_map_dmabuf(struct iommufd_ctx *ictx, struct iopt_pages *pages,
> > > > > > mutex_unlock(&pages->mutex);
> > > > > > }
> > > > > >
> > > > > > - rc = sym_vfio_pci_dma_buf_iommufd_map(attach, &pages->dmabuf.phys);
> > > > > > + rc = dma_buf_pin(attach);
> > > > > > if (rc)
> > > > > > goto err_detach;
> > > > > >
> > > > > > + rc = sym_vfio_pci_dma_buf_iommufd_map(attach, &pages->dmabuf.phys);
> > > > > > + if (rc)
> > > > > > + goto err_unpin;
> > > > > > +
> > > > > > dma_resv_unlock(dmabuf->resv);
> > > > > >
> > > > > > /* On success iopt_release_pages() will detach and put the dmabuf. */
> > > > > > pages->dmabuf.attach = attach;
> > > > > > return 0;
> > > > >
> > > > > Don't we need an explicit unpin after unmapping?
> > > >
> > > > Yes, but this patch is going to be dropped in v3 because of this
> > > > suggestion.
> > > > https://lore.kernel.org/all/a397ff1e-615f-4873-98a9-940f9c16f85c@amd.com
> > >
> > > That's not right, that suggestion is about changing VFIO. iommufd must
> > > still act as a pinning importer!
> >
> > There is no change in iommufd, as it invokes dma_buf_dynamic_attach()
> > with a valid &iopt_dmabuf_attach_revoke_ops. The check determining whether
> > iommufd can perform a revoke is handled there.
>
> iommufd is a pining importer. I did not add a call to pin because it
> only worked with VFIO that would not support it. Now that this series
> fixes it the pin must be added. Don't drop this patch.
No problem, let's keep it.
Thanks
Powered by blists - more mailing lists