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
