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