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
