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
