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
