> From: Matt Evans <[email protected]> > 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 <[email protected]>
Reviewed-by: Kevin Tian <[email protected]>
