On Fri, Oct 09, 2026 at 09:08:47PM +0300, Leon Romanovsky wrote: > 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.
OK, I'll drop this while we discuss it.
