Re: [PATCH 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V guests on Intel hosts

[Leon Romanovsky]

On Fri, Oct 09, 2026 at 06:21:49PM +0000, Popov, Pavel E wrote:
> > 1. Note where `hypervisor_supports_p2pdma()` is called: before
> >    `host_bridge_whitelist()`. This means the code ignores the hypervisor
> >    topology. The claim that the VM has a virtual bridge, causing
> >    `pci_p2pdma_whitelist()` to fail, describes exactly how P2P is expected
> >    to work today.
> 
> It does not ignore the topology. The check is reached only after the
> common-upstream-bridge walk and the ACS checks have failed, at the point
> where the host bridge allowlist is consulted.

Since the request comes from a VM, we always take the "skip" path,
regardless of the topology.

<...>

> 
> > 2. We are not developing an alternative solution. This is the right
> >    solution, and there is broad agreement that it is the only reliable
> >    way to enable P2P in VMs, for ALL emulation software stacks.
> 
> Agreed, and the cover letter says so. Our understanding is that HMAT
> becomes the primary source of P2PDMA information and the allowlist
> remains as a fallback; the hypervisor check is part of that fallback,
> not a competing path. When the HMAT lookup lands it takes precedence in
> the same decision path, and this check only matters where no HMAT is
> exposed. The adoption timeline of HMAT in hypervisors is uncertain, and
> guests on existing hypervisor releases will not get it at all, so the
> fallback is needed for both new and existing deployments.

I won't worry for hypervisors, they have enough brilliant developers to
take the upstream code to their codebase.

> 
> 
> > 3. This problem has existed and been known for at least the past eight
> >    years, since Logan upstreamed P2P support. The claim "we need it now
> >    and ASAP" is not valid at all.
> 
> The problem is old, the demand is not. Passing several accelerators
> through to one guest and expecting them to talk to each other is a
> recent requirement

This is not correct, at least for mlx5 devices. The need was already recognized
in 2020 in commit 90da7dc8206a ("RDMA/mlx5: Support dma-buf based userspace
memory region").

> and today P2PDMA does not work at all for
> passthrough devices in VMware or Hyper-V guests on Intel hosts. The
> series does not claim urgency beyond that: a working path exists now,
> HMAT does not yet, and the two do not conflict.
> 
> 
> > 4. The proposed hack does not solve the P2P-in-VM problem; it only makes it work
> >    in some random cases. An HMAT-based solution will still be needed, even on systems
> >    that use this hack.
> 
> It makes it work on Xeon Scalable hosts under VMware and Hyper-V, which
> is where passthrough accelerators are deployed today.

This is a very Intel-centric view. The vast majority of systems probably run on ARM
and use QEMU.

> Nothing more is claimed. I agree HMAT is still needed on top for latency, bandwidth and
> ordering attributes.
> 

The primary goal of HMAT is to eliminate the need for whitelists and to
simulate a P2P route for the VM that accounts for the hypervisor topology.
Latency and bandwidth are secondary considerations.

Thanks