Message-ID: <f7f1856a-44fa-44af-b496-eb1267a05d11@amd.com>
Date: Mon, 12 Jan 2026 15:56:32 +0100
From: Christian König <christian.koenig@....com>
To: Jason Gunthorpe <jgg@...pe.ca>, Simona Vetter <simona.vetter@...ll.ch>
Cc: Leon Romanovsky <leon@...nel.org>, Sumit Semwal
 <sumit.semwal@...aro.org>, Alex Williamson <alex@...zbot.org>,
 Kevin Tian <kevin.tian@...el.com>, Joerg Roedel <joro@...tes.org>,
 Will Deacon <will@...nel.org>, Robin Murphy <robin.murphy@....com>,
 linux-rdma@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-media@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linaro-mm-sig@...ts.linaro.org, kvm@...r.kernel.org, iommu@...ts.linux.dev
Subject: Re: [PATCH 0/4] dma-buf: add revoke mechanism to invalidate shared
 buffers

On 1/12/26 15:14, Jason Gunthorpe wrote:
> On Mon, Jan 12, 2026 at 01:57:25PM +0100, Christian König wrote:
>> Clear NAK to that plan. This is not something DMA-buf should need to
>> deal with and as far as I can see is incompatible with the UAPI.
> 
> We had this discussion with Simona and you a while back and there was
> a pretty clear direction we needed to add a revoke to sit inbetween
> pin and move. I think Leon has no quite got the "dmabuf lingo" down
> right to explain this.

I was already wondering why this was clearly not what we have discussed before.

>  https://lore.kernel.org/dri-devel/Z4Z4NKqVG2Vbv98Q@phenom.ffwll.local/
> 
>    Since you mention pin here, I think that's another aspect of the revocable
>    vs dynamic question. Dynamic buffers are expected to sometimes just move
>    around for no reason, and importers must be able to cope.
> 
>    For recovable exporters/importers I'd expect that movement is not
>    happening, meaning it's pinned until the single terminal revocation. And
>    maybe I read the kvm stuff wrong, but it reads more like the latter to me
>    when crawling through the pfn code.
> 
> The issue is that DMABUF only offers two attachment options today, pin
> and move. iommufd/kvm can implement pin, but not move because they
> don't support faulting.
> 
> vfio and others don't need move with faulting but they do need pin
> with a terminal, emergency, revocation.

Yeah, I know that this is confusing. But that use case is already supported and we just need to properly document things.

The move_notify callback can be called even after pin() in the case of PCIe hotplug for example.

We could potentially rename the callback to something like invalidate_mappings.

And yes, I know that we had a few issues with that because we didn't properly documented things...
> The purpose of revoke is to add a new negotiated attachment mode
> between exporter and importer that behaves the same as pin up until
> the user does something catastrophic (like ubind a driver) then a
> revoke invalidation is used to clean everything up safely.

With or with pin() you need to guarantee to the importer that the DMA address you gave out stay valid until the importer had a chance to free up it's mappings.

It is intentionally done this way to properly support PCIe hot plug because even when a device is gone the address space can't be re-used until all importers stated that they stopped their DMA.

> You are right that the existing move_notify already meets this
> semantic, and today VFIO exporter, RDMA ODP importer even implement
> this. Upon VFIO revoke move_notify() will invalidate and map() will
> fail. RDMA ODP then HW fails all faults.
> 
> The problem revoke is designed to solve is that many importers have
> hardware that can either be DMA'ing or failing. There is no fault
> mechanims that can be used to implement the full "move around for no
> reason" semantics that are implied by move_notify.

In this case just call dma_buf_pin(). We already support that approach for RDMA devices which can't do ODP.

Regards,
Christian.

> Thus they can't implement move_notify!
> 
> Revoke allows this less capable HW to still be usable with exporters,
> so long as exporters promise only to issue an invalidation for a
> "single terminal revocation". Which does nicely match the needs of
> exporters which are primarily pin based.
> 
> IOW this is an enhancement to pin modes to add a terminal error case
> invalidation to pinned attachments.
> 
> It is not intended to be UAPI changing, and Leon is not trying to say
> that importers have to drop their attachment. The attachment just
> becomes permanently non-present.
> 
> Jason

Powered by blists - more mailing lists