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
