Re: [PATCH v6 9/9] vfio/pci: Permanently revoke a DMABUF on request

["Christian König" <christian.koenig@amd.com>]

On 9/21/26 15:22, Jason Gunthorpe wrote:
> On Mon, Sep 21, 2026 at 02:08:47PM +0100, Matt Evans wrote:
> 
>> Not quite; the priv->revoked flag tracks temporary periods of
>> inaccessibility.  An example is VFIO resetting a function; the BAR
>> mappings as seen by the CPU and DMABUFs made from the BARs are all made
>> inaccessible before the reset, and made accessible again after the
>> reset.
> 
> From the importer perspective this is a permanent revoke.

Yes, exactly that.

> The right way to view this flow is VFIO permanently revokes the DMABUF
> FD. Then instead of forcing a new FD to be obtained it replaces the
> existing FD with a working one.

Well that is a little bit problematic. It could result in a race when you have multiple importers.

> From an importer perspective it sees the revoke happen and then that's
> it, the dmabuf never does anything further. The importer has to unmap
> and start from scratch, get a FD and map it.

It could also be possible to wait for the reset to finish before giving out a new mapping.

> That VFIO re-used the FD to make a new live export isn't visible to
> the importer at all.
> 
> I think that is where this "temporary revoke" language gets confusing.
> 
> Call it "VFIO reuses the FD to create a new live mapping" is clearer
> than calling it "temporarily revoke" which sounds too much like move.

I would avoid that and just re-create the DMA-buf fd from scratch. The extra overhead is negligible and one way state transmissions are usually much easier to handle.

Christian.

> 
> Jason