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 <[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 > > > >
