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