* Re: [RFC 1/2] Vfio: add callback to get tph info for dmabuf [not found] ` <20260210194014.2147481-2-zhipingz@meta.com> @ 2026-02-27 0:56 ` Keith Busch 0 siblings, 0 replies; 4+ messages in thread From: Keith Busch @ 2026-02-27 0:56 UTC (permalink / raw) To: Zhiping Zhang Cc: Jason Gunthorpe, Leon Romanovsky, Bjorn Helgaas, linux-rdma, linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas, Bjorn Helgaas The subject prefix should be lower case "vfio" to match the subsystem commit style. On Tue, Feb 10, 2026 at 11:39:54AM -0800, Zhiping Zhang wrote: > diff --git a/include/uapi/linux/vfio.h b/include/uapi/linux/vfio.h > index ac2329f24141..bff2f5f7e38d 100644 > --- a/include/uapi/linux/vfio.h > +++ b/include/uapi/linux/vfio.h > @@ -1501,6 +1501,8 @@ struct vfio_region_dma_range { > struct vfio_device_feature_dma_buf { > __u32 region_index; > __u32 open_flags; > + __u16 steering_tag; > + __u8 ph; > __u32 flags; > __u32 nr_ranges; > struct vfio_region_dma_range dma_ranges[] __counted_by(nr_ranges); I don't think you can add fields to a uapi struct like this since it breaks comptibility. Instead, I think you may be able to carve it out of the "flags" field since it's currently reserved to be 0, so I guess it's potentially available to define a new feature. ^ permalink raw reply [flat|nested] 4+ messages in thread
[parent not found: <20260210194014.2147481-3-zhipingz@meta.com>]
* Re: [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf mr [not found] ` <20260210194014.2147481-3-zhipingz@meta.com> @ 2026-02-27 1:21 ` Keith Busch 2026-03-01 17:55 ` Jason Gunthorpe 0 siblings, 1 reply; 4+ messages in thread From: Keith Busch @ 2026-02-27 1:21 UTC (permalink / raw) To: Zhiping Zhang Cc: Jason Gunthorpe, Leon Romanovsky, Bjorn Helgaas, linux-rdma, linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas, Bjorn Helgaas On Tue, Feb 10, 2026 at 11:39:55AM -0800, Zhiping Zhang wrote: > +static void get_tph_mr_dmabuf(struct mlx5_ib_dev *dev, int fd, u16 *st_index, > + u8 *ph) > +{ > + int ret; > + struct dma_buf *dmabuf; > + > + dmabuf = dma_buf_get(fd); > + if (IS_ERR(dmabuf)) > + return; > + > + if (!dif there's any implication mabuf->ops->get_tph) > + goto end_dbuf_put; > + > + ret = dmabuf->ops->get_tph(dmabuf, st_index, ph); You defined the "get_tph" function to take a pointer to a raw steering tag value, but you're passing in the steering index to it's table. But in general, since you're letting the user put whatever they want in the vfio private area, should there be some validation that it's in the valid range? I'm also not quite sure how user space comes to know what steering tag to use, or what harm might happen if the wrong one is used. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf mr 2026-02-27 1:21 ` [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf mr Keith Busch @ 2026-03-01 17:55 ` Jason Gunthorpe 0 siblings, 0 replies; 4+ messages in thread From: Jason Gunthorpe @ 2026-03-01 17:55 UTC (permalink / raw) To: Keith Busch Cc: Zhiping Zhang, Leon Romanovsky, Bjorn Helgaas, linux-rdma, linux-pci, netdev, dri-devel, Yochai Cohen, Yishai Hadas, Bjorn Helgaas On Thu, Feb 26, 2026 at 06:21:28PM -0700, Keith Busch wrote: > On Tue, Feb 10, 2026 at 11:39:55AM -0800, Zhiping Zhang wrote: > > +static void get_tph_mr_dmabuf(struct mlx5_ib_dev *dev, int fd, u16 *st_index, > > + u8 *ph) > > +{ > > + int ret; > > + struct dma_buf *dmabuf; > > + > > + dmabuf = dma_buf_get(fd); > > + if (IS_ERR(dmabuf)) > > + return; > > + > > + if (!dif there's any implication mabuf->ops->get_tph) > > + goto end_dbuf_put; > > + > > + ret = dmabuf->ops->get_tph(dmabuf, st_index, ph); > > You defined the "get_tph" function to take a pointer to a raw steering > tag value, but you're passing in the steering index to it's table. Yeah that's weird, there should be one TPH for a DMABUF, not many. > But in general, since you're letting the user put whatever they want in > the vfio private area, should there be some validation that it's in the > valid range? I'm also not quite sure how user space comes to know what > steering tag to use, or what harm might happen if the wrong one is used. If the device is VFIO compatible then it needs to ensure that whatever it does with its steering tags fit the security model of VFIO. You can't harm the device - you can't reach outside the VFIO sandbox (eg into another VF or something) and so on. Under these conditions the kernel doesn't care what TPH is used, just let userspace specify the raw bits on the wire. Jason ^ permalink raw reply [flat|nested] 4+ messages in thread
* [RFC 0/2] Retrieve tph from dmabuf for PCIe P2P memory access @ 2026-02-09 17:53 Zhiping Zhang 2026-02-09 17:53 ` [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf mr Zhiping Zhang 0 siblings, 1 reply; 4+ messages in thread From: Zhiping Zhang @ 2026-02-09 17:53 UTC (permalink / raw) To: Jason Gunthorpe, Leon Romanovsky, Bjorn Helgaas, linux-rdma, linux-pci, netdev, Keith Busch, Yochai Cohen, Yishai Hadas Cc: Bjorn Helgaas, Zhiping Zhang Currently, the steering tag can be used for a CPU on the motherboard; the ACPI check is in place to query and obtain the supported tph settings. Here we intend to use the tph info to improve RDMA NIC memory access on a vfio-based accelerator device via PCIe peer-to-peer. When an applicantion register a RDMA memory region with DMABUF for the RDMA NIC to access the device memory, the tph associated with the memory region can be retrieved and used to set the steering tag / process hint (ph). The tph contains additional instructions or hints to the GPU or accelerator device for advanced memory operations, such as, read cache selection. Note this RFC is for the discussion on the direction and is not intended to be a complete implementation. Once the direction is agreed on, we will work on the implementation or a real patch set. Signed-off-by: Zhiping Zhang <zhipingz@meta.com> [RFC 1/2] Vfio: add callback to get tph info for dmabuf [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf ^ permalink raw reply [flat|nested] 4+ messages in thread
* [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf mr 2026-02-09 17:53 [RFC 0/2] Retrieve tph from dmabuf for PCIe P2P memory access Zhiping Zhang @ 2026-02-09 17:53 ` Zhiping Zhang 0 siblings, 0 replies; 4+ messages in thread From: Zhiping Zhang @ 2026-02-09 17:53 UTC (permalink / raw) To: Jason Gunthorpe, Leon Romanovsky, Bjorn Helgaas, linux-rdma, linux-pci, netdev, Keith Busch, Yochai Cohen, Yishai Hadas Cc: Bjorn Helgaas, Zhiping Zhang The patch adds a local function to check and get tph info when available during dmabuf mr registration. Note the DMAH workflow for CPU still takes precedence in the process. Currently, it only works with the direct st_mode. Compatibility with other st_modes will be added in the forma patch set. Signed-off-by: Zhiping Zhang <zhipingz@meta.com> --- drivers/infiniband/hw/mlx5/mr.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) diff --git a/drivers/infiniband/hw/mlx5/mr.c b/drivers/infiniband/hw/mlx5/mr.c index 325fa04cbe8a..c3eb5b24ef29 100644 --- a/drivers/infiniband/hw/mlx5/mr.c +++ b/drivers/infiniband/hw/mlx5/mr.c @@ -46,6 +46,8 @@ #include "data_direct.h" #include "dmah.h" +MODULE_IMPORT_NS("DMA_BUF"); + enum { MAX_PENDING_REG_MR = 8, }; @@ -1623,6 +1625,32 @@ static struct dma_buf_attach_ops mlx5_ib_dmabuf_attach_ops = { .move_notify = mlx5_ib_dmabuf_invalidate_cb, }; +static void get_tph_mr_dmabuf(struct mlx5_ib_dev *dev, int fd, u16 *st_index, + u8 *ph) +{ + int ret; + struct dma_buf *dmabuf; + struct mlx5_core_dev *mdev = dev->mdev; + + dmabuf = dma_buf_get(fd); + if (IS_ERR(dmabuf)) + return; + + if (!dmabuf->ops->get_tph) + goto end_dbuf_put; + + ret = dmabuf->ops->get_tph(dmabuf, st_index, ph); + if (ret) { + *st_index = MLX5_MKC_PCIE_TPH_NO_STEERING_TAG_INDEX; + *ph = MLX5_IB_NO_PH; + mlx5_ib_dbg(dev, "get_tph failed (%d)\n", ret); + goto end_dbuf_put; + } + +end_dbuf_put: + dma_buf_put(dmabuf); +}; + static struct ib_mr * reg_user_mr_dmabuf(struct ib_pd *pd, struct device *dma_device, u64 offset, u64 length, u64 virt_addr, @@ -1662,6 +1690,8 @@ reg_user_mr_dmabuf(struct ib_pd *pd, struct device *dma_device, ph = dmah->ph; if (dmah->valid_fields & BIT(IB_DMAH_CPU_ID_EXISTS)) st_index = mdmah->st_index; + } else { + get_tph_mr_dmabuf(dev, fd, &st_index, &ph); } mr = alloc_cacheable_mr(pd, &umem_dmabuf->umem, virt_addr, -- 2.47.3 ^ permalink raw reply related [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-03-01 17:55 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260210194014.2147481-1-zhipingz@meta.com>
[not found] ` <20260210194014.2147481-2-zhipingz@meta.com>
2026-02-27 0:56 ` [RFC 1/2] Vfio: add callback to get tph info for dmabuf Keith Busch
[not found] ` <20260210194014.2147481-3-zhipingz@meta.com>
2026-02-27 1:21 ` [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf mr Keith Busch
2026-03-01 17:55 ` Jason Gunthorpe
2026-02-09 17:53 [RFC 0/2] Retrieve tph from dmabuf for PCIe P2P memory access Zhiping Zhang
2026-02-09 17:53 ` [RFC 2/2] RMDA MLX5: get tph for p2p access when registering dmabuf mr Zhiping Zhang
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox