On Thu, Jun 18, 2026 at 05:06:27PM +0100, Matt Evans wrote: > Hi Praan, > > On 12/06/2026 20:39, Pranjal Shrivastava wrote: > >>
[...] > >> 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. > Ack. I see. That makes sense. Thanks, Praan
