Re: [PATCH v13 5/5] RDMA/mlx5: get tph for p2p access when registering dma-buf mr

[Leon Romanovsky <leon@kernel.org>]

On Mon, Sep 28, 2026 at 02:47:46PM -0700, Zhiping Zhang wrote:
> On Mon, Sep 28, 2026 at 10:30 AM Jason Gunthorpe <jgg@ziepe.ca> wrote:
> >
> > >
> > On Thu, Sep 24, 2026 at 11:17:57PM -0700, Zhiping Zhang wrote:
> > > On Thu, Sep 24, 2026 at 4:31 PM Jason Gunthorpe <jgg@ziepe.ca> 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
> 
> Thanks Jason, I see what you meant by Leon's series now:
>   https://lore.kernel.org/all/20260928-fix-p2p-acs-v4-0-v8-0-404453b9c435@nvidia.com/
> 
> Looking at v8, it seems patches 1-4 can stay functionally unchanged,
> while patch 5 uses dma_buf_p2pdma_map_type() on its own attachment for
> both the initial TPH query and revalidation. Is that what you expect?
> 
> If so, would you prefer that I wait for Leon's series and rebase the
> whole stack on it, or split the series so patches 1-4 can land first
> and patch 5 follows after Leon's series?

I would like you to join me there and explain to Christian why the
importer needs access to the exporter's internals.

You are already second user for the same functionally.

Thanks

> 
> Thanks,
> Zhiping