Hi Praan, On 12/06/2026 20:39, Pranjal Shrivastava wrote: > On Wed, Jun 10, 2026 at 04:43:20PM +0100, Matt Evans wrote: >> 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. >> >> 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. >> >> Signed-off-by: Matt Evans <[email protected]> >> --- >> .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c | 8 +++ >> drivers/vfio/pci/vfio_pci_config.c | 30 ++++---- >> drivers/vfio/pci/vfio_pci_core.c | 70 +++++++++++++------ >> drivers/vfio/pci/vfio_pci_priv.h | 3 +- >> include/linux/vfio_pci_core.h | 1 + >> 5 files changed, 73 insertions(+), 39 deletions(-) >> >> diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c >> b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c >> index 86362ec424a5..51990f6d66d5 100644 >> --- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c >> +++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c >> @@ -1692,6 +1692,14 @@ static int hisi_acc_vfio_pci_probe(struct pci_dev >> *pdev, const struct pci_device >> if (ret) >> goto out_put_vdev; >> >> + /* >> + * hisi_acc_vfio_pci_mmap() calls down to >> + * vfio_pci_core_mmap(), so BAR mappings are still >> + * DMABUF-backed. They don't require a zap on revoke, so opt >> + * out: >> + */ >> + hisi_acc_vdev->core_device.zap_bars_on_revoke = false; >> + > > This seems to be happening after we vfio_pci_core_register_device, which > could be slightly problematic if another device in the same group races > to trigger a hot reset before we can set this to false. Could we > initialize this flag before registration instead?
Remember it is a safe default, so in the event of a driver not managing to opt-out before it's required then all that happens is a redundant unmap_mapping_range(). The default-safe was a nice suggestion from Alex on v2. Matt
