From: Matt Evans matt@ozlabs.org Sent: Thursday, July 16, 2026 1:48 AM
Expand the VFIO DMABUF revocation state to three states: Not revoked, temporarily revoked, and permanently revoked.
The first two are for existing transient revocation, e.g. across a function reset, and the DMABUF is put into the last in response to a new VFIO feature VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE.
VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE passes a DMABUF by fd and requests that the DMABUF is permanently revoked. On success, it's guaranteed that the buffer can never be imported/attached/mmap()ed in future, that dynamic imports have been cleanly detached, and that all mappings have been made inaccessible/PTEs zapped.
This is useful for lifecycle management, to reclaim VFIO PCI BAR ranges previously delegated to a subordinate client process: by revoking, the driver process can ensure that the loaned resources are made inaccessible when the client is deemed "done". The original DMABUF is defunct, and BAR resources can then be safely re-exported for use by new clients.
Refactor the revocation code out of vfio_pci_dma_buf_move() to a function common to move and the new feature request path. Note: this now only calls dma_buf_invalidate_mappings()/dma_resv_wait_timeout() on the revoke path, whereas vfio_pci_dma_buf_move() originally called them for both revoke and (unnecessarily) un-revoke.
Signed-off-by: Matt Evans matt@ozlabs.org
Reviewed-by: Kevin Tian kevin.tian@intel.com