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

[Leon Romanovsky]

On Wed, Sep 23, 2026 at 04:40:03PM +0100, Matt Evans wrote:
> Hi Jason, Alex,
> 
> On 22/09/2026 23:57, Jason Gunthorpe wrote:
> > On Tue, Sep 22, 2026 at 03:31:07PM -0700, Alex Mastro wrote:
> > 
> >> So I empathize with Matt's contention that the _existing_ behavior that the
> >> priv->revoked flag represents is actually "temporarily revoked": the importer
> >> can use the same dma-buf again, later, without having to re-import
> >> it!
> > 
> > mlx5 isn't a revoking importer, it is move capable. So the above
> > sequence isn't a revoke, it is a move with an unmapped placement for a
> > while.
> > 
> > This is why "temporarily revoked" is a confusing phrase.
> > 
> > The API is such that move and revoke importers can co-exist like this
> > but they experiance a different version of things..
> 
> Ahhhhh.  That was very helpful (esp. to contrast with the previous
> iommufd statement about invalidate_mappings being permanent), thank you!
> 
> So the worry was that the VFIO DMABUF's temp/perm state could be
> misconstrued as an implication/guarantee about the future availability
> of that DMABUF to importers, OK.  And we want the existing move(false)
> behaviour still, for dynamic importers that treat it as a move.

This is not a bug; the behavior is intentional. During review of the initial
versions of the revoke mechanism, it was pointed out that
`move_notify == invalidate_mappings == revoke`. The initial versions
introduced a separate function call for revocation, which we abandon in
favour of move semantics.

Thanks