On Thu, Sep 24, 2026 at 11:17:57PM -0700, Zhiping Zhang wrote: > On Thu, Sep 24, 2026 at 4:31 PM Jason Gunthorpe <[email protected]> wrote: > > > > > > > On Wed, Sep 23, 2026 at 11:24:56PM -0700, Zhiping Zhang wrote: > > > I don't think this belongs in the importer. Every in-tree dma-buf > > > caller of pci_p2pdma_distance() is the exporter, in its .attach, > > > clearing attach->peer2peer -- amdgpu_dma_buf.c, xe_dma_buf.c, > > > habanalabs memory.c. There is no importer-side caller. > > > > Right, and they shouldn't be doing that, but it still has to be > > checked that the st is going directly to the peer device not the host > > bridge. Not using the distance, but by the PCI_P2PDMA_MAP_BUS_ADDR > > indication. > > > > I fear you will need some of Leon's series to make that happen. > > > > So probably the proposed change to dmabuf ops is far too simple. > > > > Jason > > Hi Jason, > > Thanks for the comments. > > Agreed -- the tag should not be handed out unless the routing is > PCI_P2PDMA_MAP_BUS_ADDR. That can be enforced conservatively on 7.3 > with two changes. I can fold both into patch 4. > ``` > In drivers/pci/p2pdma.c, make pci_p2pdma_map_type() callable from > tristate VFIO_PCI_CORE: > > EXPORT_SYMBOL_GPL(pci_p2pdma_map_type);
No, that's been rejected several times already. > and in drivers/vfio/pci/vfio_pci_dmabuf.c, > vfio_pci_dma_buf_get_pci_tph() gains: > > struct dma_buf_attachment *attach; > > if (list_empty(&dmabuf->attachments)) > return -EOPNOTSUPP; > > list_for_each_entry(attach, &dmabuf->attachments, node) > if (pci_p2pdma_map_type(priv->provider, attach->dev) != > PCI_P2PDMA_MAP_BUS_ADDR) > return -EOPNOTSUPP; > ``` Also no, this has to be done via PCI_P2PDMA_MAP_BUS_ADDR which also enforces putting the determination in the right place in the code flow.. > Two properties are worth stating explicitly: Ah! AI! Jason
