Re: [PATCH v3 6/9] vfio/pci: Clean up BAR zap and revocation

[Matt Evans <matt@ozlabs.org>]

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 <matt@ozlabs.org>
>> ---
>>  .../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