From: Matt Evans matt@ozlabs.org Sent: Wednesday, June 10, 2026 11:43 PM
Previously, vfio_pci_zap_bars() (and the wrapper vfio_pci_zap_and_down_write_memory_lock()) calls were paired with calls to vfio_pci_dma_buf_move().
This commit replaces them with a unified new function, vfio_pci_zap_revoke_bars() containing both the vfio_pci_dma_buf_move() and the unmap_mapping_range(), making it harder for callers to omit one. It adds a wrapper, vfio_pci_lock_zap_revoke_bars(), which takes the write memory_lock before zapping, and adds a new vfio_pci_unrevoke_bars() for the re-enable path.
It's unusual to have three verbs (lock/zap/revoke) in one function name.
I wonder whether it's simpler to have: vfio_pci_zap_bars_locked() // caller already holds the lock vfio_pci_zap_bars()
'revoke' is just a side-effect of 'zap', not necessarily to highlight it in the name.
As of "vfio/pci: Convert BAR mmap() to use a DMABUF", the unmap_mapping_range() to zap is no longer performed for vfio-pci since the DMABUFs used for BAR mappings already zap PTEs when the vfio_pci_dma_buf_move() occurs.
However, it must be assumed that VFIO drivers which override the .mmap op could create mappings _not_ backed by DMABUFs. So, the zap is still performed on revoke if .mmap is overridden, using a new zap_bars_on_revoke flag. A driver can explicitly opt out; the flag is cleared by the hisi_acc_vfio_pci driver, since its .mmap just wraps vfio_pci_core_mmap() and so still uses DMABUFs.
the cost of unmap_mapping_range() is trivial when there is no mmap on the device fd.
so it could be simpler by always doing:
vfio_pci_dma_buf_move(); unmap_mapping_range();
and remove the flag.