On Mon, Sep 14, 2026 at 08:36:47AM -0300, Jason Gunthorpe wrote:
On Sun, Sep 13, 2026 at 07:52:44PM +0300, Leon Romanovsky wrote:
On Fri, Sep 11, 2026 at 10:41:57PM +0100, Matt Evans wrote:
Expand the VFIO DMABUF revocation state to three states: Not revoked, temporarily revoked, and permanently revoked.
The thing is that "temporarily revoked" is actually the standard invalidate_mappings/move_notify mechanism of DMABUF, which wasn't good for VFIO.
I think temporarily revokes here means it is revoked from a dmabuf perspective
My guess is that this is more of a "change owner" operation than a revoke operation.
The main issue here is that we have to guess the semantics instead of having a properly named and documented operation. As Christian pointed out, the patches describe what they are doing well, but they do not explain why they are doing it.
Just that VFIO can make it's internal dmabuf work again, there won't be a notification to any importer or an expectation that something like iommufd will re-establish mapping automatically.
This is principally a kernel self protection mechanism where the userspace was expected to have removed the dmabuf before issuing a reset/etc. If they didn't then the kernel plonks it and userspace gets a mess to clean up.
Revoke/invalidate means that the importer should stop accessing the buffer provided by the exporter. It does not specify what the exporter should do afterwards.
So I still think that "temporarily revoked" is closer to invalidate_mappings, with some additional dma-buf documentation to lose the expectation that the buffer will become available again.
Thanks
Jason