Logan,
The intent of v1 was to avoid another list like pci_p2pdma_whitelist[]
that needs extending every generation, and to limit it to the
hypervisor so the existing bare-metal logic is untouched. ESXi runs
only on servers certified in the Broadcom Compatibility Guide, hence
the simple Skylake-and-newer check.
On dma-buf picking P2P without the user asking: P2P is enabled on ESXi
server hosts, and so in their guest VMs. A "yes" in the guest is
correct there, as on bare metal.
If the threshold is a concern, v2 can update the hypervisor check to
match an explicit list of Xeon Scalable and Xeon D, from Skylake-SP to
Diamond Rapids, server parts only:
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), /* Sierra Forest */
X86_MATCH_VFM(INTEL_ATOM_DARKMONT_X, NULL), /* Clearwater Forest */
X86_MATCH_VFM(INTEL_DIAMONDRAPIDS_X, NULL),
That is the list v1 tried to avoid, but it is bounded: these are the
generations whose host bridge is already whitelisted on bare metal.
A CPU list cannot replace the host bridge whitelist on bare metal, as
the two do not match 1:1, so it stays behind the hypervisor check.
If you still prefer the kernel command line option you suggested, v3
can add it, per-endpoint or global. It works without a patched kernel,
but puts the burden on every VMware user to know about and set it,
where v1 or v2 just works.
Thanks,
Pavel
> -----Original Message-----
> From: Logan Gunthorpe <[email protected]>
> Sent: Friday, October 16, 2026 11:18 AM
> To: Popov, Pavel E <[email protected]>; Bjorn Helgaas
> <[email protected]>
> Cc: Leon Romanovsky <[email protected]>; Jim Chow
> <[email protected]>; Bjorn Helgaas <[email protected]>; Radu
> Rugina <[email protected]>; Alexey Makhalov
> <[email protected]>; Wei Liu <[email protected]>; Michael
> Kelley <[email protected]>; Lukas Wunner <[email protected]>; Rafael J.
> Wysocki <[email protected]>; Nathan Ciobanu
> <[email protected]>; [email protected];
> [email protected]; [email protected]; linux-
> [email protected]; [email protected]
> Subject: Re: [PATCH 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V
> guests on Intel hosts
>
>
>
> On 2026-10-16 10:05, Popov, Pavel E wrote:
> > Bjorn, Logan,
> >
> > Leon's position is clear: "NAK to anything that does not fix the
> > hypervisor first". No concrete failure was described, and no change in
> > this series can address it. That leaves the decision with you. Two
> > facts: AMD guests get P2PDMA today and Intel guests do not, and HMAT
> > does not exist in Linux yet.
>
> Yikes, ok, I've followed some of that long discussion.
>
> My first thought was this didn't seem as big an issue as it seemed because if
> someone explicitly tries to do a P2PDMA transaction inside a VM and it fails
> because the IOMMU blocks it, then they just get a noisy error and they
> shouldn't
> enable P2PDMA. Except...
>
> It looks like the dma-buf paths will enable P2PDMA unconditionally if the
> test in
> question allows it, without anything the user needs to do to enable it. I
> think that
> was probably a huge mistake but I guess we have to live with that now. It
> means
> enabling new hardware with rules like this is risky. It means even adding a
> global
> rule for Intel like AMD is risky too. (Although, *maybe* eight years after I
> first
> added this code, we can say that the vast majority of Intel CPUs support it,
> in
> which case the dangers here are overblown -- but can we say that? What about
> atoms and the like? Would the rule need to be complicated by a big model list?
> These questions are why this has never happened.)
>
> So I'm inclined to agree with Leon now that accepting this patch as is may
> introduce some problematic risks. For now, maybe we need a kernel command
> line argument that can explicitly enable an endpoint or something like that so
> users that want to try it on VMware or wherever can do so without needing to
> build a custom patched kernel.
>
> I wish we could revisit the decision for dma-buf to use it without any users
> explicitly asking for it. But I don't know what the correct path forward is.
> If we can
> agree on a bulk rule for enabling Intel CPUs that might be a good compromise,
> but
> I'm uncertain if that is even possible.
>
> Logan
>
