> Replace the VFIO exporter's priv->revoked flag with a status enum of > OK, REVOKED, and DEAD. OK and REVOKED are equivalent to the existing > flag, which tracks whether invalidate_mappings & unmap has occurred > and whether attach/map are permitted. > > The DMABUF is marked DEAD in response to a new VFIO feature > VFIO_DEVICE_FEATURE_DMA_BUF_REVOKE. This passes a DMABUF by fd and > requests that the DMABUF is immediately revoked. On success, it's > guaranteed that PTEs are zapped, imports have been cleanly unmapped, > and that the buffer can never be mapped/attached or mmap()ed anymore. > Existing VFIO move semantics could permit a buffer to be mapped again > in future (e.g. revoke/unrevoke around a reset), but the DEAD state > can never become OK again. > > This enables a userspace driver process to securely reclaim VFIO PCI > BAR resources previously delegated to a subordinate process. Using > the new ioctl, the userspace driver process can ensure that resources > are inaccessible when the subordinate is deemed "done". The > originally-exported DMABUF becomes unusable, and BAR resources can > then be safely re-exported for use elsewhere. > > Refactor the revocation code out of vfio_pci_dma_buf_move() to a > function common to move and the new feature request path. This > function calls dma_buf_invalidate_mappings() and > dma_resv_wait_timeout() only on the revoke path > (vfio_pci_dma_buf_move() originally called them for both revoke and, > unnecessarily, for un-revoke). > > Signed-off-by: Matt Evans <[email protected]>
Sashiko has reviewed this patch and found no issues. It looks great! -- Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=9
