On Fri, Oct 09, 2026 at 11:58:33AM -0500, Bjorn Helgaas wrote: > On Fri, Oct 09, 2026 at 08:40:32AM -0700, Pavel Popov wrote: > > VMware and Hyper-V expose passthrough devices to guest VMs without an > > explicit host bridge device. Consequently, host_bridge_whitelist() > > cannot automatically identify the underlying host bridge structure, > > causing Peer-to-Peer DMA (P2PDMA) requests to be rejected unless the > > device IDs are explicitly listed in pci_p2pdma_whitelist[]. To enable > > P2PDMA support in virtualized environments on Intel hosts, this series > > introduces hypervisor_supports_p2pdma(). > > > > Although alternative P2PDMA mechanisms are in development [1], their > > adoption timeline in hypervisors remains uncertain. This solution > > addresses the immediate need to support both new and existing > > hypervisor deployments. > > > > The patches are organized by hypervisor for clarity. While the primary > > focus is VMware, a corresponding Hyper-V patch addresses the same > > pattern and is included for maintainer consideration. > > > > [1] https://lore.kernel.org/r/[email protected] > > > > Pavel Popov (2): > > PCI/P2PDMA: Allow P2PDMA in VMware guests on Intel hosts > > PCI/P2PDMA: Allow P2PDMA in Hyper-V guests on Intel hosts > > > > drivers/pci/p2pdma.c | 21 +++++++++++++++++++++ > > 1 file changed, 21 insertions(+) > > Applied with the #ifdef tweak Logan suggested to pci/p2pdma for v7.4, > thanks!
Bjorn, I disagree with this decision for several reasons: 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. 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. 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. 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. Let's get the HMAT solution merged sooner rather than later. To make that happen, we need a coordinated effort across the industry, not hacks to work around the problem. > > FWIW, it's better if responses like Jim's Reviewed-by actually appear > on the mailing list. I don't see anything in lore, so I assume it > must have been private review. Unfortunately, this patch series was not given enough time for review. Thanks >
