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
