From: Leon Romanovsky <leon@kernel.org>
To: "Christian König" <christian.koenig@amd.com>
Cc: "Matthew Brost" <matthew.brost@intel.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Alex Deucher" <alexander.deucher@amd.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Dmitry Osipenko" <dmitry.osipenko@collabora.com>,
"Gurchetan Singh" <gurchetansingh@chromium.org>,
"Chia-I Wu" <olvaffe@gmail.com>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Lucas De Marchi" <lucas.demarchi@intel.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"Kevin Tian" <kevin.tian@intel.com>,
"Joerg Roedel" <joro@8bytes.org>, "Will Deacon" <will@kernel.org>,
"Robin Murphy" <robin.murphy@arm.com>,
"Felix Kuehling" <Felix.Kuehling@amd.com>,
"Alex Williamson" <alex@shazbot.org>,
"Ankit Agrawal" <ankita@nvidia.com>,
"Vivek Kasireddy" <vivek.kasireddy@intel.com>,
linux-media@vger.kernel.org, dri-devel@lists.freedesktop.org,
linaro-mm-sig@lists.linaro.org, linux-kernel@vger.kernel.org,
amd-gfx@lists.freedesktop.org, virtualization@lists.linux.dev,
intel-xe@lists.freedesktop.org, linux-rdma@vger.kernel.org,
iommu@lists.linux.dev, kvm@vger.kernel.org
Subject: Re: [PATCH v3 6/7] vfio: Wait for dma-buf invalidation to complete
Date: Wed, 21 Jan 2026 12:44:51 +0200 [thread overview]
Message-ID: <20260121104451.GB13201@unreal> (raw)
In-Reply-To: <015b25e6-cfe1-4110-963f-5f8dc4720d1b@amd.com>
On Wed, Jan 21, 2026 at 11:41:48AM +0100, Christian König wrote:
> On 1/20/26 21:44, Matthew Brost wrote:
> > On Tue, Jan 20, 2026 at 04:07:06PM +0200, Leon Romanovsky wrote:
> >> From: Leon Romanovsky <leonro@nvidia.com>
> >>
> >> dma-buf invalidation is performed asynchronously by hardware, so VFIO must
> >> wait until all affected objects have been fully invalidated.
> >>
> >> Fixes: 5d74781ebc86 ("vfio/pci: Add dma-buf export support for MMIO regions")
> >> Signed-off-by: Leon Romanovsky <leonro@nvidia.com>
> >> ---
> >> drivers/vfio/pci/vfio_pci_dmabuf.c | 5 +++++
> >> 1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/vfio/pci/vfio_pci_dmabuf.c b/drivers/vfio/pci/vfio_pci_dmabuf.c
> >> index d4d0f7d08c53..33bc6a1909dd 100644
> >> --- a/drivers/vfio/pci/vfio_pci_dmabuf.c
> >> +++ b/drivers/vfio/pci/vfio_pci_dmabuf.c
> >> @@ -321,6 +321,9 @@ void vfio_pci_dma_buf_move(struct vfio_pci_core_device *vdev, bool revoked)
> >> dma_resv_lock(priv->dmabuf->resv, NULL);
> >> priv->revoked = revoked;
> >> dma_buf_move_notify(priv->dmabuf);
> >> + dma_resv_wait_timeout(priv->dmabuf->resv,
> >> + DMA_RESV_USAGE_KERNEL, false,
> >> + MAX_SCHEDULE_TIMEOUT);
> >
> > Should we explicitly call out in the dma_buf_move_notify() /
> > invalidate_mappings kernel-doc that KERNEL slots are the mechanism
> > for communicating asynchronous dma_buf_move_notify /
> > invalidate_mappings events via fences?
>
> Oh, I missed that! And no that is not correct.
>
> This should be DMA_RESV_USAGE_BOOKKEEP so that we wait for everything.
Will change.
>
> Regards,
> Christian.
>
> >
> > Yes, this is probably implied, but it wouldn’t hurt to state this
> > explicitly as part of the cross-driver contract.
> >
> > Here is what we have now:
> >
> > * - Dynamic importers should set fences for any access that they can't
> > * disable immediately from their &dma_buf_attach_ops.invalidate_mappings
> > * callback.
> >
> > Matt
> >
> >> dma_resv_unlock(priv->dmabuf->resv);
> >> }
> >> fput(priv->dmabuf->file);
> >> @@ -342,6 +345,8 @@ void vfio_pci_dma_buf_cleanup(struct vfio_pci_core_device *vdev)
> >> priv->vdev = NULL;
> >> priv->revoked = true;
> >> dma_buf_move_notify(priv->dmabuf);
> >> + dma_resv_wait_timeout(priv->dmabuf->resv, DMA_RESV_USAGE_KERNEL,
> >> + false, MAX_SCHEDULE_TIMEOUT);
> >> dma_resv_unlock(priv->dmabuf->resv);
> >> vfio_device_put_registration(&vdev->vdev);
> >> fput(priv->dmabuf->file);
> >>
> >> --
> >> 2.52.0
> >>
>
>
next prev parent reply other threads:[~2026-01-21 10:44 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 14:07 [PATCH v3 0/7] dma-buf: Use revoke mechanism to invalidate shared buffers Leon Romanovsky
2026-01-20 14:07 ` [PATCH v3 1/7] dma-buf: Rename .move_notify() callback to a clearer identifier Leon Romanovsky
2026-01-21 8:33 ` Christian König
2026-01-21 8:41 ` Leon Romanovsky
2026-01-20 14:07 ` [PATCH v3 2/7] dma-buf: Always build with DMABUF_MOVE_NOTIFY Leon Romanovsky
2026-01-21 8:55 ` Christian König
2026-01-21 10:14 ` Leon Romanovsky
2026-01-21 10:57 ` Christian König
2026-01-20 14:07 ` [PATCH v3 3/7] dma-buf: Document RDMA non-ODP invalidate_mapping() special case Leon Romanovsky
2026-01-21 8:59 ` Christian König
2026-01-21 9:14 ` Leon Romanovsky
2026-01-21 9:17 ` Christian König
2026-01-21 13:18 ` Jason Gunthorpe
2026-01-21 13:52 ` Christian König
2026-01-21 13:59 ` Jason Gunthorpe
2026-01-21 14:15 ` Christian König
2026-01-21 14:31 ` Leon Romanovsky
2026-01-21 15:39 ` Jason Gunthorpe
2026-01-20 14:07 ` [PATCH v3 4/7] dma-buf: Add check function for revoke semantics Leon Romanovsky
2026-01-20 14:07 ` [PATCH v3 5/7] iommufd: Pin dma-buf importer " Leon Romanovsky
2026-01-21 9:01 ` Christian König
2026-01-20 14:07 ` [PATCH v3 6/7] vfio: Wait for dma-buf invalidation to complete Leon Romanovsky
2026-01-20 20:44 ` Matthew Brost
2026-01-21 7:59 ` Leon Romanovsky
2026-01-21 10:41 ` Christian König
2026-01-21 10:44 ` Leon Romanovsky [this message]
2026-01-21 17:18 ` Matthew Brost
2026-01-21 9:20 ` Christian König
2026-01-21 9:36 ` Thomas Hellström
2026-01-21 10:55 ` Christian König
2026-01-21 13:31 ` Jason Gunthorpe
2026-01-21 15:28 ` Christian König
2026-01-21 16:01 ` Jason Gunthorpe
2026-01-21 19:45 ` Leon Romanovsky
2026-01-22 11:32 ` Christian König
2026-01-22 23:44 ` Jason Gunthorpe
2026-01-23 14:11 ` Jason Gunthorpe
2026-01-23 16:23 ` Christian König
2026-01-23 16:31 ` Jason Gunthorpe
2026-01-20 14:07 ` [PATCH v3 7/7] vfio: Validate dma-buf revocation semantics Leon Romanovsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260121104451.GB13201@unreal \
--to=leon@kernel.org \
--cc=Felix.Kuehling@amd.com \
--cc=airlied@gmail.com \
--cc=alex@shazbot.org \
--cc=alexander.deucher@amd.com \
--cc=amd-gfx@lists.freedesktop.org \
--cc=ankita@nvidia.com \
--cc=christian.koenig@amd.com \
--cc=dmitry.osipenko@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gurchetansingh@chromium.org \
--cc=intel-xe@lists.freedesktop.org \
--cc=iommu@lists.linux.dev \
--cc=jgg@ziepe.ca \
--cc=joro@8bytes.org \
--cc=kevin.tian@intel.com \
--cc=kraxel@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=lucas.demarchi@intel.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=matthew.brost@intel.com \
--cc=mripard@kernel.org \
--cc=olvaffe@gmail.com \
--cc=robin.murphy@arm.com \
--cc=rodrigo.vivi@intel.com \
--cc=simona@ffwll.ch \
--cc=sumit.semwal@linaro.org \
--cc=thomas.hellstrom@linux.intel.com \
--cc=tzimmermann@suse.de \
--cc=virtualization@lists.linux.dev \
--cc=vivek.kasireddy@intel.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.