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 16, 2026 at 02:55:07PM +0000, Popov, Pavel E wrote:
> Bjorn, Logan,
> 
> Could you consider taking this series despite the NAK, for two reasons:
> 
> - Parity: Linux gives AMD guests preferential treatment

This is misleading. You did not propose adding Intel processors to a whitelist,
for example in `cpu_supports_p2pdma()`. Instead, you explicitly added a check
for whether the system is running in a VM.

> - No alternative: the HMAT solution doesn't exist in Linux yet

This is not how open-source development works. Let's work together to find a
solution that works for everyone.

Thanks

> 
> Thanks,
> Pavel
> 
> > -----Original Message-----
> > From: Leon Romanovsky <leon@kernel.org>
> > Sent: Tuesday, October 13, 2026 5:20 AM
> > To: Popov, Pavel E <pavel.e.popov@intel.com>
> > Cc: Bjorn Helgaas <helgaas@kernel.org>; Jim Chow <jim.chow@broadcom.com>;
> > Bjorn Helgaas <bhelgaas@google.com>; Logan Gunthorpe
> > <logang@deltatee.com>; Radu Rugina <radu.rugina@broadcom.com>; Alexey
> > Makhalov <alexey.makhalov@broadcom.com>; Wei Liu <wei.liu@kernel.org>;
> > Michael Kelley <mhklinux@outlook.com>; Lukas Wunner <lukas@wunner.de>;
> > Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>; bcm-kernel-feedback-
> > list@broadcom.com; virtualization@lists.linux.dev; linux-hyperv@vger.kernel.org;
> > linux-pci@vger.kernel.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V
> > guests on Intel hosts
> > 
> > On Mon, Oct 12, 2026 at 08:01:40PM +0000, Popov, Pavel E wrote:
> > > > Please read all of my responses. I was explicit about why the check
> > > > inside the guest VM produces random results. However, your responses
> > > > continue to focus on the guest, which is not the problem.
> > >
> > > Fair, my earlier replies were about the guest. Taking the host-side
> > > points in turn:
> > >
> > > 1. Host topology decides P2P, the guest cannot see it, and the patch
> > >    says "yes" for every pair regardless.
> > >
> > >    The topology is accounted for where the knowledge is: on the host.
> > >    Which devices land in one VM is decided by the admin, from devices
> > >    VMware has certified for passthrough in the Compatibility Guide,
> > >    and on vSphere 8+ by Device Groups, which hands devices sharing a
> > >    switch or interconnect to a VM as a topology-aware group. Hyper-V
> > >    has no equivalent grouping; DDA is plain passthrough, each device
> > >    assigned to the VM explicitly by the admin.
> > >
> > >    The blanket "yes" is not new either. On bare metal the flags = 0
> > >    whitelist entries say "yes" for any pair of Xeon Scalable root
> > >    buses, across sockets, with no knowledge of BIOS P2P settings. And
> > >    cpu_supports_p2pdma() already bypasses the host bridge check for
> > >    AMD Zen on CPUID alone, in guests included. This series gives Intel
> > >    hosts what the tree already does for AMD; if that is unacceptable
> > >    in principle, it is unacceptable for AMD guests today.
> > 
> > If you had simply added Intel CPUs to the list of supported P2P devices, I might
> > have been willing to accept that. However, you added these two lines:
> > 
> > +	    (hypervisor_is_type(X86_HYPER_VMWARE) ||
> > +	     hypervisor_is_type(X86_HYPER_MS_HYPERV)))
> > 
> > This makes your case quite different from AMD's. Their check was for hypervisor,
> > which leaked to VMs. And, yes, AMD does not work reliably in guest VMs either.
> > For our internal testing, we have carefully curated hypervisor configurations and
> > test VMs, along with custom patches, to test P2P reliably.
> > 
> > >
> > > 2. Regression: consumers that work today via a system-memory fallback
> > >    will take the P2P path and break on hosts that cannot route it.
> > >
> > >    A wrong "yes" fails safely: without host-side P2P the request is
> > >    stopped at the host IOMMU, nothing is corrupted, the same exposure
> > >    an AMD guest has today. An unconditional "no" is worse: it blocks
> > >    P2P on every host that does route it, and the guest's answer
> > >    changes nothing about whether the host routes it.
> > >
> > >    Xeon Scalable routes P2P between any two root ports, which the
> > >    whitelist already encodes. The only hypervisor-side requirement is
> > >    mapping the peer's MMIO into the VM's IOMMU domain, and that is
> > >    what passthrough P2P support means: on ESXi it was an explicit
> > >    per-VM setting for years and is the default since 9.0; Hyper-V does
> > >    it for devices assigned to the same VM, as tested on Windows Server
> > >    2025. The decision is made on the host; the guest only has to stop
> > >    vetoing it.
> > >
> > > 3. The hypervisor must describe it, HMAT is the way, NAK to anything
> > >    that does not fix the hypervisor first.
> > >
> > >    Agreed HMAT is the right source and should take precedence: consult
> > >    it first, this check only where no HMAT exists. The disagreement is
> > >    on "first". Guests on already shipped ESXi and Hyper-V releases
> > >    will never get HMAT, and those stay in production for years; the
> > >    cover letter's note on the adoption timeline was written with
> > >    VMware's input, and Jim can speak to it. Until a hypervisor emits
> > >    HMAT, this fallback is the only path that works.
> > 
> > This is VMware's problem, not the upstream kernel community's. If VMware
> > considers P2P important and its customers agree, VMware can upgrade.
> > 
> > It is no different from any other kernel feature.
> > 
> > Thanks
> > 
> > >
> > > Thanks,
> > > Pavel
> > >
>