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

[Matt Evans]

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.

> We probably should not have made it have this move compatible
> restoration and had things more consistent. User space can't know if
> the importer is move capable or not so it has to assume revoke and it
> has to go and unmap things before resetting/etc.
> >> This series doesn't intend to change the behavior of either. Is the
confusion
>> about whether the current behavior is intentional and/or desirable? If the
>> answer to both is "no", then IMO this series paves the way nicely towards making
>> PERM_REVOKED the only supported semantic later.
> 
> Right, I think the only concern is language.
In that case, the VFIO-internal tracking could be:

 priv->status = VFIO_PCI_DMABUF_OK;      /* was priv->revoked = false */
 priv->status = VFIO_PCI_DMABUF_REVOKED; /* was priv->revoked = true */
 priv->status = VFIO_PCI_DMABUF_DEAD;

The latter means that an invalidate_mappings was performed (due to a new
userspace ioctl trigger), and that all future dma_buf_*attach() attempts
must fail.  I'd add a comment to explain this clearly in the enum.

If that's too macabre, DEFUNCT?  (A word implying guaranteed
permanence...).  The userspace action causing all this can IMHO be
called REVOKE still; it's what it does.  (I'll clarify the observable
effect from the POV of an importer in the UAPI.)

WDYT?


Matt