[PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[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. 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.

Add an explicit list of the Intel Xeon server generations from
Skylake-SP to Diamond Rapids to cpu_supports_p2pdma(). These are the
CPUs whose host bridges are in pci_p2pdma_whitelist[] without
restrictions. 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>
---
Changes in v3:
- Drop the hypervisor check and move the Xeon list into
  cpu_supports_p2pdma(), next to the AMD check, as suggested by Logan
  Gunthorpe and Leon Romanovsky [1]
- Fold the VMware and Hyper-V patches into one, as the check no longer
  depends on the hypervisor

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

[1] https://lore.kernel.org/r/20261016153147.GC219304@unreal

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

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

diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
index 9334eb314663..2650d605d87d 100644
--- a/drivers/pci/p2pdma.c
+++ b/drivers/pci/p2pdma.c
@@ -21,6 +21,11 @@
 #include <linux/seq_buf.h>
 #include <linux/xarray.h>
 
+#ifdef CONFIG_X86
+#include <asm/cpu_device_id.h>
+#include <asm/intel-family.h>
+#endif
+
 struct pci_p2pdma {
 	struct gen_pool *pool;
 	bool p2pmem_published;
@@ -519,6 +524,23 @@ static void seq_buf_print_bus_devfn(struct seq_buf *buf, struct pci_dev *pdev)
 	seq_buf_printf(buf, "%s;", pci_name(pdev));
 }
 
+#ifdef CONFIG_X86
+/* Intel Xeon CPUs whose host bridges support p2pdma */
+static const struct x86_cpu_id p2pdma_intel_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),
+	{}
+};
+#endif
+
 static bool cpu_supports_p2pdma(void)
 {
 #ifdef CONFIG_X86
@@ -527,6 +549,10 @@ static bool cpu_supports_p2pdma(void)
 	/* Any AMD CPU whose family ID is Zen or newer supports p2pdma */
 	if (c->x86_vendor == X86_VENDOR_AMD && c->x86 >= 0x17)
 		return true;
+
+	/* Listed Intel Xeon CPUs support p2pdma */
+	if (x86_match_cpu(p2pdma_intel_cpu_ids))
+		return true;
 #endif
 
 	return false;

base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
-- 
2.53.0

Re: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[sashiko-bot]

> 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. 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.
> 
> Add an explicit list of the Intel Xeon server generations from
> Skylake-SP to Diamond Rapids to cpu_supports_p2pdma(). These are the
> CPUs whose host bridges are in pci_p2pdma_whitelist[] without
> restrictions. 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>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261020151305.65218-1-pavel.e.popov@intel.com?part=1

Re: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[Logan Gunthorpe]

On 2026-10-20 09:13, Pavel Popov wrote:
> 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. 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.
> 
> Add an explicit list of the Intel Xeon server generations from
> Skylake-SP to Diamond Rapids to cpu_supports_p2pdma(). These are the
> CPUs whose host bridges are in pci_p2pdma_whitelist[] without
> restrictions. 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>

I can get behind this:

Reviewed-by: Logan Gunthorpe <logang@deltatee.com>

Thanks,

Logan

Re: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[Leon Romanovsky]

On Tue, Oct 20, 2026 at 08:13:05AM -0700, Pavel Popov wrote:
> 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. 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.
> 
> Add an explicit list of the Intel Xeon server generations from
> Skylake-SP to Diamond Rapids to cpu_supports_p2pdma(). These are the
> CPUs whose host bridges are in pci_p2pdma_whitelist[] without
> restrictions. 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>
> ---
> Changes in v3:
> - Drop the hypervisor check and move the Xeon list into
>   cpu_supports_p2pdma(), next to the AMD check, as suggested by Logan
>   Gunthorpe and Leon Romanovsky [1]
> - Fold the VMware and Hyper-V patches into one, as the check no longer
>   depends on the hypervisor
> 
> 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
> 
> [1] https://lore.kernel.org/r/20261016153147.GC219304@unreal
> 
> v2: https://lore.kernel.org/r/20261016223402.19991-1-pavel.e.popov@intel.com
> v1: https://lore.kernel.org/r/20261009154034.82321-1-pavel.e.popov@intel.com
> 
>  drivers/pci/p2pdma.c | 26 ++++++++++++++++++++++++++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> index 9334eb314663..2650d605d87d 100644
> --- a/drivers/pci/p2pdma.c
> +++ b/drivers/pci/p2pdma.c
> @@ -21,6 +21,11 @@
>  #include <linux/seq_buf.h>
>  #include <linux/xarray.h>
>  
> +#ifdef CONFIG_X86
> +#include <asm/cpu_device_id.h>
> +#include <asm/intel-family.h>
> +#endif
> +
>  struct pci_p2pdma {
>  	struct gen_pool *pool;
>  	bool p2pmem_published;
> @@ -519,6 +524,23 @@ static void seq_buf_print_bus_devfn(struct seq_buf *buf, struct pci_dev *pdev)
>  	seq_buf_printf(buf, "%s;", pci_name(pdev));
>  }
>  
> +#ifdef CONFIG_X86

Do we really need all these #ifdefs? I'm pretty sure they're not needed for the
includes.

Thanks

> +/* Intel Xeon CPUs whose host bridges support p2pdma */
> +static const struct x86_cpu_id p2pdma_intel_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),
> +	{}
> +};
> +#endif
> +
>  static bool cpu_supports_p2pdma(void)
>  {
>  #ifdef CONFIG_X86
> @@ -527,6 +549,10 @@ static bool cpu_supports_p2pdma(void)
>  	/* Any AMD CPU whose family ID is Zen or newer supports p2pdma */
>  	if (c->x86_vendor == X86_VENDOR_AMD && c->x86 >= 0x17)
>  		return true;
> +
> +	/* Listed Intel Xeon CPUs support p2pdma */
> +	if (x86_match_cpu(p2pdma_intel_cpu_ids))
> +		return true;
>  #endif
>  
>  	return false;
> 
> base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
> -- 
> 2.53.0
> 
> 

Re: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[Bjorn Helgaas]

On Tue, Oct 20, 2026 at 07:14:47PM +0300, Leon Romanovsky wrote:
> On Tue, Oct 20, 2026 at 08:13:05AM -0700, Pavel Popov wrote:
> > 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. 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.
> > 
> > Add an explicit list of the Intel Xeon server generations from
> > Skylake-SP to Diamond Rapids to cpu_supports_p2pdma(). These are the
> > CPUs whose host bridges are in pci_p2pdma_whitelist[] without
> > restrictions. 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>
> > ---
> > Changes in v3:
> > - Drop the hypervisor check and move the Xeon list into
> >   cpu_supports_p2pdma(), next to the AMD check, as suggested by Logan
> >   Gunthorpe and Leon Romanovsky [1]
> > - Fold the VMware and Hyper-V patches into one, as the check no longer
> >   depends on the hypervisor
> > 
> > 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
> > 
> > [1] https://lore.kernel.org/r/20261016153147.GC219304@unreal
> > 
> > v2: https://lore.kernel.org/r/20261016223402.19991-1-pavel.e.popov@intel.com
> > v1: https://lore.kernel.org/r/20261009154034.82321-1-pavel.e.popov@intel.com
> > 
> >  drivers/pci/p2pdma.c | 26 ++++++++++++++++++++++++++
> >  1 file changed, 26 insertions(+)
> > 
> > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
> > index 9334eb314663..2650d605d87d 100644
> > --- a/drivers/pci/p2pdma.c
> > +++ b/drivers/pci/p2pdma.c
> > @@ -21,6 +21,11 @@
> >  #include <linux/seq_buf.h>
> >  #include <linux/xarray.h>
> >  
> > +#ifdef CONFIG_X86
> > +#include <asm/cpu_device_id.h>
> > +#include <asm/intel-family.h>
> > +#endif
> > +
> >  struct pci_p2pdma {
> >  	struct gen_pool *pool;
> >  	bool p2pmem_published;
> > @@ -519,6 +524,23 @@ static void seq_buf_print_bus_devfn(struct seq_buf *buf, struct pci_dev *pdev)
> >  	seq_buf_printf(buf, "%s;", pci_name(pdev));
> >  }
> >  
> > +#ifdef CONFIG_X86
> 
> Do we really need all these #ifdefs? I'm pretty sure they're not
> needed for the includes.

Apparently we do.  I experimentally removed them and cross-compiled
for arm64:

  drivers/pci/p2pdma.c:24:10: fatal error: asm/cpu_device_id.h: No such file or directory
     24 | #include <asm/cpu_device_id.h>
	|          ^~~~~~~~~~~~~~~~~~~~~

RE: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[Popov, Pavel E]

If preferred, we could use for cpu_supports_p2pdma() the pattern Logan
suggested for hypervisor_supports_p2pdma() in v1: the whole function
under #ifdef CONFIG_X86 with a stub returning false for !CONFIG_X86.
The Intel CPU list then moves into the same #ifdef block, which saves
one #ifdef, at the cost of also touching the existing AMD part.

Thanks,
Pavel

> -----Original Message-----
> From: Bjorn Helgaas <helgaas@kernel.org>
> Sent: Tuesday, October 20, 2026 9:38 AM
> To: Leon Romanovsky <leon@kernel.org>
> Cc: Popov, Pavel E <pavel.e.popov@intel.com>; Bjorn Helgaas
> <bhelgaas@google.com>; Logan Gunthorpe <logang@deltatee.com>; Lukas
> Wunner <lukas@wunner.de>; 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>; 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 v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs
> 
> On Tue, Oct 20, 2026 at 07:14:47PM +0300, Leon Romanovsky wrote:
> > On Tue, Oct 20, 2026 at 08:13:05AM -0700, Pavel Popov wrote:
> > > 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. 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.
> > >
> > > Add an explicit list of the Intel Xeon server generations from
> > > Skylake-SP to Diamond Rapids to cpu_supports_p2pdma(). These are the
> > > CPUs whose host bridges are in pci_p2pdma_whitelist[] without
> > > restrictions. 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>
> > > ---
> > > Changes in v3:
> > > - Drop the hypervisor check and move the Xeon list into
> > >   cpu_supports_p2pdma(), next to the AMD check, as suggested by Logan
> > >   Gunthorpe and Leon Romanovsky [1]
> > > - Fold the VMware and Hyper-V patches into one, as the check no longer
> > >   depends on the hypervisor
> > >
> > > 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
> > >
> > > [1] https://lore.kernel.org/r/20261016153147.GC219304@unreal
> > >
> > > v2:
> > > https://lore.kernel.org/r/20261016223402.19991-1-pavel.e.popov@intel
> > > .com
> > > v1:
> > > https://lore.kernel.org/r/20261009154034.82321-1-pavel.e.popov@intel
> > > .com
> > >
> > >  drivers/pci/p2pdma.c | 26 ++++++++++++++++++++++++++
> > >  1 file changed, 26 insertions(+)
> > >
> > > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c index
> > > 9334eb314663..2650d605d87d 100644
> > > --- a/drivers/pci/p2pdma.c
> > > +++ b/drivers/pci/p2pdma.c
> > > @@ -21,6 +21,11 @@
> > >  #include <linux/seq_buf.h>
> > >  #include <linux/xarray.h>
> > >
> > > +#ifdef CONFIG_X86
> > > +#include <asm/cpu_device_id.h>
> > > +#include <asm/intel-family.h>
> > > +#endif
> > > +
> > >  struct pci_p2pdma {
> > >  	struct gen_pool *pool;
> > >  	bool p2pmem_published;
> > > @@ -519,6 +524,23 @@ static void seq_buf_print_bus_devfn(struct seq_buf
> *buf, struct pci_dev *pdev)
> > >  	seq_buf_printf(buf, "%s;", pci_name(pdev));  }
> > >
> > > +#ifdef CONFIG_X86
> >
> > Do we really need all these #ifdefs? I'm pretty sure they're not
> > needed for the includes.
> 
> Apparently we do.  I experimentally removed them and cross-compiled for
> arm64:
> 
>   drivers/pci/p2pdma.c:24:10: fatal error: asm/cpu_device_id.h: No such file or
> directory
>      24 | #include <asm/cpu_device_id.h>
> 	|          ^~~~~~~~~~~~~~~~~~~~~

Re: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[Logan Gunthorpe]

On 2026-10-20 10:47, Popov, Pavel E wrote:
> If preferred, we could use for cpu_supports_p2pdma() the pattern Logan
> suggested for hypervisor_supports_p2pdma() in v1: the whole function
> under #ifdef CONFIG_X86 with a stub returning false for !CONFIG_X86.
> The Intel CPU list then moves into the same #ifdef block, which saves
> one #ifdef, at the cost of also touching the existing AMD part.

I personally would prefer cleaning up the #ifdef style but that's an
issue that's already in the code. I don't feel the need to make it
conditional on my Reviewed-by. If you are able to clean that up, I would
appreciate it.

Thanks,

Logan

Re: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[Leon Romanovsky]

On Tue, Oct 20, 2026, at 19:54, Logan Gunthorpe wrote:
> On 2026-10-20 10:47, Popov, Pavel E wrote:
>> If preferred, we could use for cpu_supports_p2pdma() the pattern Logan
>> suggested for hypervisor_supports_p2pdma() in v1: the whole function
>> under #ifdef CONFIG_X86 with a stub returning false for !CONFIG_X86.
>> The Intel CPU list then moves into the same #ifdef block, which saves
>> one #ifdef, at the cost of also touching the existing AMD part.
>
> I personally would prefer cleaning up the #ifdef style but that's an
> issue that's already in the code. I don't feel the need to make it
> conditional on my Reviewed-by. If you are able to clean that up, I would
> appreciate it.

Sooner or later that cleanup will be done, and I don't see any reason to delay it while we are touching that code anyway.

Thanks 

>
> Thanks,
>
> Logan

Re: [PATCH v3] PCI/P2PDMA: Allow P2PDMA on Intel Xeon server CPUs

[Leon Romanovsky]

On Tue, Oct 20, 2026, at 19:37, Bjorn Helgaas wrote:
> On Tue, Oct 20, 2026 at 07:14:47PM +0300, Leon Romanovsky wrote:
>> On Tue, Oct 20, 2026 at 08:13:05AM -0700, Pavel Popov wrote:
>> > 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. 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.
>> > 
>> > Add an explicit list of the Intel Xeon server generations from
>> > Skylake-SP to Diamond Rapids to cpu_supports_p2pdma(). These are the
>> > CPUs whose host bridges are in pci_p2pdma_whitelist[] without
>> > restrictions. 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>
>> > ---
>> > Changes in v3:
>> > - Drop the hypervisor check and move the Xeon list into
>> >   cpu_supports_p2pdma(), next to the AMD check, as suggested by Logan
>> >   Gunthorpe and Leon Romanovsky [1]
>> > - Fold the VMware and Hyper-V patches into one, as the check no longer
>> >   depends on the hypervisor
>> > 
>> > 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
>> > 
>> > [1] https://lore.kernel.org/r/20261016153147.GC219304@unreal
>> > 
>> > v2: https://lore.kernel.org/r/20261016223402.19991-1-pavel.e.popov@intel.com
>> > v1: https://lore.kernel.org/r/20261009154034.82321-1-pavel.e.popov@intel.com
>> > 
>> >  drivers/pci/p2pdma.c | 26 ++++++++++++++++++++++++++
>> >  1 file changed, 26 insertions(+)
>> > 
>> > diff --git a/drivers/pci/p2pdma.c b/drivers/pci/p2pdma.c
>> > index 9334eb314663..2650d605d87d 100644
>> > --- a/drivers/pci/p2pdma.c
>> > +++ b/drivers/pci/p2pdma.c
>> > @@ -21,6 +21,11 @@
>> >  #include <linux/seq_buf.h>
>> >  #include <linux/xarray.h>
>> >  
>> > +#ifdef CONFIG_X86
>> > +#include <asm/cpu_device_id.h>
>> > +#include <asm/intel-family.h>
>> > +#endif
>> > +
>> >  struct pci_p2pdma {
>> >  	struct gen_pool *pool;
>> >  	bool p2pmem_published;
>> > @@ -519,6 +524,23 @@ static void seq_buf_print_bus_devfn(struct seq_buf *buf, struct pci_dev *pdev)
>> >  	seq_buf_printf(buf, "%s;", pci_name(pdev));
>> >  }
>> >  
>> > +#ifdef CONFIG_X86
>> 
>> Do we really need all these #ifdefs? I'm pretty sure they're not
>> needed for the includes.
>
> Apparently we do.  I experimentally removed them and cross-compiled
> for arm64:

I'm pretty sure that it's not how asm headers are expected to be consumed.
There are general asm stubs for code outside of arch. Probably general code shouldn't include ifdefs to access these includes.

Thanks 

>
>   drivers/pci/p2pdma.c:24:10: fatal error: asm/cpu_device_id.h: No such 
> file or directory
>      24 | #include <asm/cpu_device_id.h>
> 	|          ^~~~~~~~~~~~~~~~~~~~~