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

[Popov, Pavel E]

Logan,

To keep the record straight:

- A global CPU check was never proposed: v1 and v2 are both limited to
  the hypervisor, for the reasons in my previous mail. The argument
  was parity with AMD guests.
- v2 does not depend on Broadcom certification. The explicit list
  matches only the Xeon generations whose host bridges are already
  whitelisted, which is stricter than the AMD global CPU check.
- HMAT's direction was never questioned. There is no HMAT solution
  today, and current ESXi releases need one. As a side remark, the
  timeline for ESXi to adopt HMAT deserves consideration too.

Thanks,
Pavel

> -----Original Message-----
> From: Leon Romanovsky <leon@xxxxxxxxxx>
> Sent: Saturday, October 17, 2026 12:48 AM
> To: Logan Gunthorpe <logang@xxxxxxxxxxxx>
> Cc: Popov, Pavel E <pavel.e.popov@xxxxxxxxx>; Bjorn Helgaas
> <bhelgaas@xxxxxxxxxx>; Jim Chow <jim.chow@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 v2 1/2] PCI/P2PDMA: Allow P2PDMA in VMware guests
> on Intel hosts
> 
> 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@xxxxxxxxxxxx>
> > > Sent: Friday, October 16, 2026 3:55 PM
> > > To: Popov, Pavel E <pavel.e.popov@xxxxxxxxx>; Bjorn Helgaas
> > > <bhelgaas@xxxxxxxxxx>
> > > Cc: Jim Chow <jim.chow@xxxxxxxxxxxx>; Radu Rugina
> > > <radu.rugina@xxxxxxxxxxxx>; Alexey Makhalov
> > > <alexey.makhalov@xxxxxxxxxxxx>; Wei Liu <wei.liu@xxxxxxxxxx>;
> > > Michael Kelley <mhklinux@xxxxxxxxxxx>; Lukas Wunner
> > > <lukas@xxxxxxxxx>; Leon Romanovsky <leonro@xxxxxxxxxx>; 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 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