[PATCH v2 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V guests on Intel hosts

[PATCH v2 0/2] PCI/P2PDMA: Allow P2PDMA in VMware and Hyper-V guests on Intel hosts

[Pavel Popov]

VMware and Hyper-V expose passthrough devices to guest VMs without an
explicit host bridge device. Consequently, host_bridge_whitelist()
cannot automatically identify the underlying host bridge structure,
causing Peer-to-Peer DMA (P2PDMA) requests to be rejected unless the
device IDs are explicitly listed in pci_p2pdma_whitelist[]. To enable
P2PDMA support in virtualized environments on Intel hosts, this series
introduces hypervisor_supports_p2pdma().

Although alternative P2PDMA mechanisms are in development [1], their
adoption timeline in hypervisors remains uncertain. This solution
addresses the immediate need to support both new and existing
hypervisor deployments.

The patches are organized by hypervisor for clarity. While the primary
focus is VMware, a corresponding Hyper-V patch addresses the same
pattern and is included for maintainer consideration.

[1] https://lore.kernel.org/r/20260812-hmat-p2p-v1-0-75ac41380585@nvidia.com

Changes in v2:
- Replace the Skylake-and-newer threshold with an explicit list of Intel
  Xeon server generations, from Skylake-SP to Diamond Rapids (Logan
  Gunthorpe)
- Move the CONFIG_X86 #ifdef out of hypervisor_supports_p2pdma()
  (Logan Gunthorpe)
- Rebased on current mainline

v1: https://lore.kernel.org/r/20261009154034.82321-1-pavel.e.popov@intel.com

Pavel Popov (2):
  PCI/P2PDMA: Allow P2PDMA in VMware guests on Intel hosts
  PCI/P2PDMA: Allow P2PDMA in Hyper-V guests on Intel hosts

 drivers/pci/p2pdma.c | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)


base-commit: 70dd4ee72eb2d5793c62e71c14e3aba78e5a4e56
-- 
2.53.0

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

[Pavel Popov]

Peer-to-Peer DMA (P2PDMA) between two devices requires either a shared
upstream bridge or a host bridge matching pci_p2pdma_whitelist[]. In
VMware guests, passthrough devices appear directly on virtual root
buses without host bridge devices. Consequently, P2PDMA checks
evaluate endpoint Device IDs against the host bridge whitelist,
causing P2PDMA requests to fail regardless of host support.

This affects discrete devices such as GPUs, NICs and NVMe drives.

The P2PDMA host bridge check does not work in a VMware guest. Bypass it
for host CPUs whose host bridges are in pci_p2pdma_whitelist[] without
restrictions. The list covers the Intel Xeon server generations from
Skylake-SP to Diamond Rapids. AMD Zen and newer are already covered by
cpu_supports_p2pdma(), so only Intel entries are needed.

Tested with the Intel Level Zero P2P benchmark (ze_peer) on Arc Pro B60
cards in a Linux guest on VMware ESXi 9.0 (Emerald Rapids host).

Signed-off-by: Pavel Popov <pavel.e.popov@intel.com>
---
 drivers/pci/p2pdma.c | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 9334eb314663..1b4886d4f9be 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -21,6 +21,12 @@
 #include <linux/seq_buf.h>
 #include <linux/xarray.h>
 
+#ifdef CONFIG_X86
+#include <asm/cpu_device_id.h>
+#include <asm/hypervisor.h>
+#include <asm/intel-family.h>
+#endif
+
 struct pci_p2pdma {
 	struct gen_pool *pool;
 	bool p2pmem_published;
@@ -532,6 +538,37 @@ static bool cpu_supports_p2pdma(void)
 	return false;
 }
 
+#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;
+}
+#else /* !CONFIG_X86 */
+static bool hypervisor_supports_p2pdma(void)
+{
+	return false;
+}
+#endif /* CONFIG_X86 */
+
 static const struct pci_p2pdma_whitelist_entry {
 	unsigned short vendor;
 	int device;
@@ -781,6 +818,7 @@ calc_map_type_and_dist(struct pci_dev *provider, struct pci_dev *client,
 
 map_through_host_bridge:
 	if (!cpu_supports_p2pdma() &&
+	    !hypervisor_supports_p2pdma() &&
 	    !host_bridge_whitelist(provider, client, acs_redirects)) {
 		if (verbose)
 			pci_warn(client, "cannot be used for peer-to-peer DMA as the client and provider (%s) do not share an upstream bridge or whitelisted host bridge\n",
-- 
2.53.0

[PATCH v2 2/2] PCI/P2PDMA: Allow P2PDMA in Hyper-V guests on Intel hosts

[Pavel Popov]

Peer-to-Peer DMA (P2PDMA) between two devices requires either a shared
upstream bridge or a host bridge matching pci_p2pdma_whitelist[]. In
Hyper-V guests, each passthrough device appears in a PCI domain of its
own without a host bridge device. Consequently, P2PDMA checks evaluate
endpoint Device IDs against the host bridge whitelist, causing P2PDMA
requests to fail regardless of host support.

This affects discrete devices such as GPUs, NICs and NVMe drives.

The P2PDMA host bridge check does not work in a Hyper-V guest. Apply
the same bypass as for VMware, on the same Intel Xeon generations.

Tested with the Intel Level Zero P2P benchmark (ze_peer) on Arc Pro B60
cards in a Linux guest on Windows Server 2025 (Emerald Rapids host).

Signed-off-by: Pavel Popov <pavel.e.popov@intel.com>
---
 drivers/pci/p2pdma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 1b4886d4f9be..9d643dd41008 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -557,7 +557,8 @@ static const struct x86_cpu_id hypervisor_p2pdma_cpu_ids[] = {
 static bool hypervisor_supports_p2pdma(void)
 {
 	/* Hypervisor hides host topology, allow p2pdma on whitelisted CPUs */
-	if (hypervisor_is_type(X86_HYPER_VMWARE))
+	if (hypervisor_is_type(X86_HYPER_VMWARE) ||
+	    hypervisor_is_type(X86_HYPER_MS_HYPERV))
 		return x86_match_cpu(hypervisor_p2pdma_cpu_ids);
 
 	return false;
-- 
2.53.0

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

[Logan Gunthorpe]

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

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

[Popov, Pavel E]

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.

Thanks,
Pavel

> -----Original Message-----
> From: Logan Gunthorpe <logang@deltatee.com>
> Sent: Friday, October 16, 2026 3:55 PM
> To: Popov, Pavel E <pavel.e.popov@intel.com>; Bjorn Helgaas
> <bhelgaas@google.com>
> Cc: Jim Chow <jim.chow@broadcom.com>; Radu Rugina
> <radu.rugina@broadcom.com>; Alexey Makhalov
> <alexey.makhalov@broadcom.com>; Wei Liu <wei.liu@kernel.org>; Michael
> Kelley <mhklinux@outlook.com>; Lukas Wunner <lukas@wunner.de>; Leon
> Romanovsky <leonro@nvidia.com>; Nathan Ciobanu
> <nathan.d.ciobanu@linux.intel.com>; bcm-kernel-feedback-
> list@broadcom.com; virtualization@lists.linux.dev; linux-
> hyperv@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> kernel@vger.kernel.org
> 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

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

[Leon Romanovsky]

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@deltatee.com>
> > Sent: Friday, October 16, 2026 3:55 PM
> > To: Popov, Pavel E <pavel.e.popov@intel.com>; Bjorn Helgaas
> > <bhelgaas@google.com>
> > Cc: Jim Chow <jim.chow@broadcom.com>; Radu Rugina
> > <radu.rugina@broadcom.com>; Alexey Makhalov
> > <alexey.makhalov@broadcom.com>; Wei Liu <wei.liu@kernel.org>; Michael
> > Kelley <mhklinux@outlook.com>; Lukas Wunner <lukas@wunner.de>; Leon
> > Romanovsky <leonro@nvidia.com>; Nathan Ciobanu
> > <nathan.d.ciobanu@linux.intel.com>; bcm-kernel-feedback-
> > list@broadcom.com; virtualization@lists.linux.dev; linux-
> > hyperv@vger.kernel.org; linux-pci@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > 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