> 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. It skips that lookup on the matched hypervisors, the same way cpu_supports_p2pdma() already skips it for AMD. The lookup cannot work there because VMware and Hyper-V expose no host bridge device at all on the root buses carrying passthrough devices, so pci_host_bridge_dev() returns the passthrough endpoint itself. That is described in the commit messages. > 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. > 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, 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. Nothing more is claimed. I agree HMAT is still needed on top for latency, bandwidth and ordering attributes.
