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 <[email protected]>; Bjorn Helgaas > <[email protected]> > Cc: Leon Romanovsky <[email protected]>; Jim Chow > <[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- > [email protected]; [email protected]; linux- > [email protected]; [email protected]; > [email protected] > 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 <[email protected]> > > Sent: Saturday, October 17, 2026 12:48 AM > > To: Logan Gunthorpe <[email protected]> > > Cc: Popov, Pavel E <[email protected]>; Bjorn Helgaas > > <[email protected]>; Jim Chow <[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]; linux- > > [email protected]; [email protected]; linux- > > [email protected] > > 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 <[email protected]> > > > > Sent: Friday, October 16, 2026 3:55 PM > > > > To: Popov, Pavel E <[email protected]>; Bjorn Helgaas > > > > <[email protected]> > > > > Cc: Jim Chow <[email protected]>; Radu Rugina > > > > <[email protected]>; Alexey Makhalov > > > > <[email protected]>; Wei Liu <[email protected]>; > > > > Michael Kelley <[email protected]>; Lukas Wunner > > > > <[email protected]>; Leon Romanovsky <[email protected]>; Nathan > > > > Ciobanu <[email protected]>; bcm-kernel-feedback- > > > > [email protected]; [email protected]; linux- > > > > [email protected]; [email protected]; linux- > > > > [email protected] > > > > 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
