On Tue, Sep 15, 2026 at 1:49 PM Alex Williamson <[email protected]> wrote: > > > > On Mon, 14 Sep 2026 09:44:57 -0700 > Zhiping Zhang <[email protected]> wrote: > > > Thanks Christian -- no worries on the bandwidth, I'll add the Acked-by > > to patch 3. > > > > Hi Alex, Jason, Bjorn, > > > > Could you help with reviews on patch 4 (vfio/pci) and patch 5 > > (RDMA/mlx5), plus acks on patches 1-2 (PCI TPH core) so the set can > > travel whole if it goes through the VFIO tree, which is the route > > Christian suggests? > > > > I've also rebased the set onto 7.3 (base 5225b8eec4c9) and retested on > > hardware -- PCIe analyzer captures confirming the requested ST and PH > > on outbound TLPs, no splats. > > > > One thing to decide: upstream took 13 for > > VFIO_DEVICE_FEATURE_ZPCI_ERROR after v13 went out, so > > VFIO_DEVICE_FEATURE_DMA_BUF_TPH becomes 14 in the respin -- let me > > know if you'd rather it be something else. > > > > I'll post v14 after I hear from you. Delta from v13 is the rebase, > > that feature-number move, and nothing else functional. > > IIRC, we're pretty well settled on the vfio-pci front. The feature > number does need to be iterated to the next available. We still need > acks from PCI and mlx5, and given the extent of the mlx5 changes I > expect I need to provide a branch for Jason/Leon once I merge it. > Thanks, > > Alex >
Thanks Alex, it is great to know the vfio-pci side is settled! Bjorn acked patches 1 and 2 today, so PCI is covered. Hi Jason, Leon, could you take a look at patch 5, the RDMA/mlx5 consumer? https://lore.kernel.org/linux-pci/[email protected]/ Thanks, Zhiping
