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

[Leon Romanovsky <leon@kernel.org>]

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/20260812-hmat-p2p-v1-0-75ac41380585@nvidia.com
> > 
> > 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

>