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

[Popov, Pavel E]

Logan, Leon,

I kept the hypervisor check to avoid changing what the host bridge
whitelist refuses on bare metal. Looking at those cases again, on the
listed Xeon CPUs this is a limitation of the whitelist itself, not a
known hardware limit, and it is why Intel QAT/DSA/IAA had to be added
by ID. So I'd drop the hypervisor check.

Would a v3 that moves the Xeon list into cpu_supports_p2pdma(), the
same way as the AMD check, be acceptable to you both?

Thanks,
Pavel

> -----Original Message-----
> From: Popov, Pavel E
> Sent: Saturday, October 17, 2026 8:21 AM
> To: Logan Gunthorpe <logang@xxxxxxxxxxxx>; Bjorn Helgaas
> <bhelgaas@xxxxxxxxxx>
> Cc: Leon Romanovsky <leon@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
> 
> 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