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 <[email protected]> > Sent: Tuesday, October 13, 2026 5:20 AM > To: Popov, Pavel E <[email protected]> > Cc: Bjorn Helgaas <[email protected]>; Jim Chow <[email protected]>; > Bjorn Helgaas <[email protected]>; Logan Gunthorpe > <[email protected]>; Radu Rugina <[email protected]>; Alexey > Makhalov <[email protected]>; Wei Liu <[email protected]>; > Michael Kelley <[email protected]>; Lukas Wunner <[email protected]>; > Nathan Ciobanu <[email protected]>; bcm-kernel-feedback- > [email protected]; [email protected]; > [email protected]; > [email protected]; [email protected] > 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 > >
