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

[Popov, Pavel E]

Bjorn, Logan,

Could you consider taking this series despite the NAK, for two reasons:

- Parity: Linux gives AMD guests preferential treatment
- No alternative: the HMAT solution doesn't exist in Linux yet

Thanks,
Pavel

> -----Original Message-----
> From: Leon Romanovsky <leon@xxxxxxxxxx>
> Sent: Tuesday, October 13, 2026 5:20 AM
> To: Popov, Pavel E <pavel.e.popov@xxxxxxxxx>
> Cc: Bjorn Helgaas <helgaas@xxxxxxxxxx>; Jim Chow <jim.chow@xxxxxxxxxxxx>;
> Bjorn Helgaas <bhelgaas@xxxxxxxxxx>; Logan Gunthorpe
> <logang@xxxxxxxxxxxx>; Radu Rugina <radu.rugina@xxxxxxxxxxxx>; Alexey
> Makhalov <alexey.makhalov@xxxxxxxxxxxx>; Wei Liu <wei.liu@xxxxxxxxxx>;
> Michael Kelley <mhklinux@xxxxxxxxxxx>; Lukas Wunner <lukas@xxxxxxxxx>;
> Nathan Ciobanu <nathan.d.ciobanu@xxxxxxxxxxxxxxx>; bcm-kernel-feedback-
> list@xxxxxxxxxxxx; virtualization@xxxxxxxxxxxxxxx; linux-hyperv@xxxxxxxxxxxxxxx;
> linux-pci@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> 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
> >