public inbox for intel-xe@lists.freedesktop.org
 help / color / mirror / Atom feed
From: "Christian König" <christian.koenig@amd.com>
To: Jason Gunthorpe <jgg@ziepe.ca>
Cc: "Leon Romanovsky" <leon@kernel.org>,
	"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>,
	"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 16:28:17 +0100	[thread overview]
Message-ID: <b88b500c-bacc-483d-9d1a-725d4158302a@amd.com> (raw)
In-Reply-To: <20260121133146.GY961572@ziepe.ca>

On 1/21/26 14:31, Jason Gunthorpe wrote:
> On Wed, Jan 21, 2026 at 10:20:51AM +0100, Christian König wrote:
>> On 1/20/26 15:07, 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>
>>
>> Reviewed-by: Christian König <christian.koenig@amd.com>
>>
>> Please also keep in mind that the while this wait for all fences for
>> correctness you also need to keep the mapping valid until
>> dma_buf_unmap_attachment() was called.
> 
> Can you elaborate on this more?
> 
> I think what we want for dma_buf_attach_revocable() is the strong
> guarentee that the importer stops doing all access to the memory once
> this sequence is completed and the exporter can rely on it. I don't
> think this works any other way.
> 
> This is already true for dynamic move capable importers, right?

Not quite, no.

> For the non-revocable importers I can see the invalidate sequence is
> more of an advisory thing and you can't know the access is gone until
> the map is undone.
> 
>> In other words you can only redirect the DMA-addresses previously
>> given out into nirvana (or a dummy memory or similar), but you still
>> need to avoid re-using them for something else.
> 
> Does any driver do this? If you unload/reload a GPU driver it is
> going to re-use the addresses handed out?

I never fully read through all the source code, but if I'm not completely mistaken that is enforced for all GPU drivers through the DMA-buf and DRM layer lifetime handling and I think even in other in kernel frameworks like V4L, alsa etc...

What roughly happens is that each DMA-buf mapping through a couple of hoops keeps a reference on the device, so even after a hotplug event the device can only fully go away after all housekeeping structures are destroyed and buffers freed.

Background is that a lot of device still make reads even after you have invalidated a mapping, but then discard the result.

So when you don't have same grace period you end up with PCI AER, warnings from IOMMU, random accesses to PCI BARs which just happen to be in the old location of something etc...

I would rather like to keep that semantics even for forcefully shootdowns since it proved to be rather reliable.

Regards,
Christian.

> 
> Jason


  parent reply	other threads:[~2026-01-21 15:28 UTC|newest]

Thread overview: 32+ 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
     [not found]         ` <20260121131852.GX961572@ziepe.ca>
2026-01-21 13:52           ` Christian König
     [not found]             ` <20260121135948.GB961572@ziepe.ca>
2026-01-21 14:15               ` Christian König
2026-01-21 14:31                 ` Leon Romanovsky
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
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
     [not found]     ` <20260121133146.GY961572@ziepe.ca>
2026-01-21 15:28       ` Christian König [this message]
     [not found]         ` <20260121160140.GF961572@ziepe.ca>
2026-01-21 19:45           ` Leon Romanovsky
2026-01-22 11:32           ` Christian König
     [not found]             ` <20260122234404.GB1589888@ziepe.ca>
     [not found]               ` <20260123141140.GC1589888@ziepe.ca>
2026-01-23 16:23                 ` Christian König
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=b88b500c-bacc-483d-9d1a-725d4158302a@amd.com \
    --to=christian.koenig@amd.com \
    --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=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=leon@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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox