Re: [PATCH v5 9/9] vfio/pci: Permanently revoke a DMABUF on request

[Pranjal Shrivastava <praan@google.com>]

On Wed, Jul 15, 2026 at 06:47:32PM +0100, Matt Evans wrote:
> 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: Pranjal Shrivastava <praan@google.com>

Thanks,
Praan