Re: [RFC PATCH 0/7] vfio: selftests: Add peer-to-peer DMA selftest

[Alex Mastro <amastro@fb.com>]

Hey David,

On Wed, Nov 11, 2026 at 07:24:04PM +0000, David Matlack wrote:
 
>     Is requiring userspace to re-issue IOMMU_IOAS_MAP_FILE the expected
>     uAPI behavior? VFIO_DEVICE_RESET (and runtime PM transitions) on the
>     target device also bracket the reset with
>     vfio_pci_dma_buf_move(vdev, true) and vfio_pci_dma_buf_move(vdev,
>     false), tearing down any active IOMMU_IOAS_MAP_FILE mapping of that
>     device's BAR even though PCI_COMMAND_MEMORY remains enabled when
>     VFIO_DEVICE_RESET returns.

There was some discussion about this in the thread below. My understanding of
Jason's point is that the current behavior, and differences between what
revoking and move-capable importers see in regards to vfio-exported dma-buf is
somewhat incidental and not necessarily desirable.

https://lore.kernel.org/all/arMBqyI4XNfD+q1W@devgpu015.cco6.facebook.com/

>   - Physical target devices and P2P topology checks: mem_bar_descs[]
>     currently only matches QEMU's pci-testdev, and
>     vfio_pci_has_p2p_path() does not yet check PCI topology or ACS to
>     verify that P2P traffic can flow between two physical endpoints.
> 
>     Suggestions on physical target BARs to add to mem_bar_descs[] and on
>     checking P2P reachability from userspace are welcome.

FWIW, you can also exercise the "P2P" path with just a single device if you
IOMMU map a device's BAR into it's own IOAS, and have the device DMA itself. For
eventually validating aspects of Live Update, maybe you don't necessarily care
if an actual peer device is being DMA'd?

Alex