Re: [PATCH v2 1/2] PCI/P2PDMA: Allow P2PDMA in VMware guests on Intel hosts

[Leon Romanovsky <leon@kernel.org>]

On Sat, Oct 17, 2026 at 12:31:49AM +0000, Popov, Pavel E wrote:
> Logan,
> 
> > Why does this now need to be related to the hypervisor? Wouldn't it
> > make sense to do this check regardless of whether VMware is involved?
> 
> The whitelist decides per host bridge, and a global CPU check would
> override it on these CPUs, for example:
> 
> - It allows VMD domains, CXL 1.1 devices and other RCiEPs, which are
>   not whitelisted.
> - It overrides the emulated topology in KVM/QEMU guests, which already
>   decides P2P there.
> - It makes the existing QAT, DSA and IAA whitelist entries pointless,
>   since any RCiEP would be allowed.
> 
> Limiting it to the hypervisor keeps the whitelist logic unchanged on
> bare metal and in other guests.

Logan,

You can see how convoluted and illogical this discussion has become.

Initially, Pavel was told that P2P inside a VM is not working reliably
(to put it mildly). His response was that he wanted Intel to provide
the same poor experience that AMD currently provides. We agreed.

Now he points out that AMD's solution does not work well and proposes
keeping his hack, which will not work any better.

Moreover, it is unrealistic to expect users to run this software and VMware's
code only on machines certified by Broadcom. It shows complete
misunderstanding of users.

His claim that HMAT's future is unclear is also inaccurate. Half the work
had already been done: p2p ACS had been cleaned up and was waiting for
Bjorn to pick it up; an initial version of the HMAT specification had
been drafted and verified against the current kernel implementation;
and the community had been consulted and had endorsed the approach at
LPC. The remaining work is to update the specification, move it through
the code-first process, and implement it in QEMU.

The direction is clear, and developer time has been allocated. This will
happen.

Thanks

> 
> Thanks,
> Pavel
> 
> > -----Original Message-----
> > From: Logan Gunthorpe <logang@deltatee.com>
> > Sent: Friday, October 16, 2026 3:55 PM
> > To: Popov, Pavel E <pavel.e.popov@intel.com>; Bjorn Helgaas
> > <bhelgaas@google.com>
> > Cc: Jim Chow <jim.chow@broadcom.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>; Leon
> > Romanovsky <leonro@nvidia.com>; 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 v2 1/2] PCI/P2PDMA: Allow P2PDMA in VMware guests
> > on Intel hosts
> > 
> > 
> > 
> > On 2026-10-16 16:34, Pavel Popov wrote:
> > > +#ifdef CONFIG_X86
> > > +/* CPUs whose host bridges support p2pdma, see pci_p2pdma_whitelist[]
> > > +*/ static const struct x86_cpu_id hypervisor_p2pdma_cpu_ids[] = {
> > > +	X86_MATCH_VFM(INTEL_SKYLAKE_X, NULL),
> > > +	X86_MATCH_VFM(INTEL_ICELAKE_X, NULL),
> > > +	X86_MATCH_VFM(INTEL_ICELAKE_D, NULL),
> > > +	X86_MATCH_VFM(INTEL_SAPPHIRERAPIDS_X, NULL),
> > > +	X86_MATCH_VFM(INTEL_EMERALDRAPIDS_X, NULL),
> > > +	X86_MATCH_VFM(INTEL_GRANITERAPIDS_X, NULL),
> > > +	X86_MATCH_VFM(INTEL_GRANITERAPIDS_D, NULL),
> > > +	X86_MATCH_VFM(INTEL_ATOM_CRESTMONT_X, NULL),
> > > +	X86_MATCH_VFM(INTEL_ATOM_DARKMONT_X, NULL),
> > > +	X86_MATCH_VFM(INTEL_DIAMONDRAPIDS_X, NULL),
> > > +	{}
> > > +};
> > > +
> > > +static bool hypervisor_supports_p2pdma(void) {
> > > +	/* Hypervisor hides host topology, allow p2pdma on whitelisted CPUs
> > */
> > > +	if (hypervisor_is_type(X86_HYPER_VMWARE))
> > > +		return x86_match_cpu(hypervisor_p2pdma_cpu_ids);
> > > +
> > > +	return false;
> > > +}
> > One quick thought, after a very quick pass at this:
> > 
> > Why does this now need to be related to the hypervisor? Wouldn't it make
> > sense to do this check regardless of whether VMWare is involved?
> > 
> > Logan