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