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..
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.
Jason
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
On Wed, Sep 23, 2026 at 04:40:03PM +0100, Matt Evans wrote:
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;
Yeah OK. DEFUNCT is good too
Jason
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
Hi Leon,
On 23/09/2026 17:52, Leon Romanovsky wrote:
On Wed, Sep 23, 2026 at 04:40:03PM +0100, Matt Evans wrote:
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.
I wasn't meaning to imply that! :)
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.
That makes sense, and it's good to know that background.
Thank you,
Matt
linaro-mm-sig@lists.linaro.org
-
Jason Gunthorpe -
Leon Romanovsky -
Matt Evans