The Honest Assessment: Why P2P GPU DMA Cannot Be Enabled in a Virtualized Environment

Introduction

In the world of high-performance machine learning inference, few things are as frustrating as a bottleneck you cannot fix. For the operator of a Proxmox VM equipped with eight NVIDIA RTX PRO 6000 Blackwell GPUs, the quest to enable Peer-to-Peer (P2P) DMA had become an obsession spanning multiple days of intensive work. The VM had been migrated from the legacy i440FX chipset to Q35, kernel parameters had been tuned with pci=realloc, IOMMU passthrough had been enabled on the Proxmox host, and Access Control Services (ACS) had been toggled in the BIOS. Yet nvidia-smi topo -p2p r stubbornly returned "NS" (Not Supported) for every cross-GPU pair. The user, after seeing the assistant pivot toward benchmarking the newly stabilized configuration, pushed back with a clear directive in message [msg 364]: "no bench, first can we fix p2p properly?"

Message [msg 369] is the assistant's response to that demand — and it is a masterclass in delivering bad news with clarity, technical depth, and actionable alternatives. This article examines that single message in detail, unpacking the reasoning, assumptions, knowledge, and thinking process that produced it.

The Context: A Long Journey to a Dead End

To understand message [msg 369], one must appreciate the journey that preceded it. The session had been a multi-day effort to deploy the GLM-5-NVFP4 large language model across eight Blackwell GPUs for inference. Early attempts had crashed with NaN errors during decode, requiring deep debugging of attention backends and quantization compatibility. Once the model was running, the team discovered that cross-GPU communication was painfully slow — the hallmark of a missing P2P DMA path.

The investigation had peeled back layer after layer. The Proxmox host's PCIe topology was examined: each GPU sat on its own dedicated root complex of an AMD EPYC processor, connected via PCIe Gen5 x16 links. The VM was migrated from i440FX to Q35 with pcie=1 to expose proper PCIe topology. A BAR allocation failure that initially caused six of eight GPUs to disappear was fixed with pci=realloc. IOMMU passthrough (amd_iommu=on iommu=pt) was enabled on the host. ACS was disabled in an attempt to merge IOMMU groups. Each change brought incremental progress — all eight GPUs now had their full 96GB of VRAM, the topology matrix showed "PHB" (PCIe Host Bridge) instead of flat bus — but P2P remained stubbornly "NS."

The user's patience was wearing thin. When the assistant suggested moving on to benchmarking in message [msg 362], the user responded with a crisp redirection: "no bench, first can we fix p2p properly?" This set the stage for the assistant to conduct deeper research, run bandwidth tests, and ultimately deliver the verdict in message [msg 369].

The Message: An Honest Assessment

Message [msg 369] opens with a direct comparison of bandwidth numbers before and after the host configuration changes:

The numbers are virtually identical to before the host changes. The 13µs latency floor is the fundamental bottleneck and it's not related to IOMMU settings — it's the inherent cost of GPU→CPU memory→GPU staged copies via the QEMU/KVM virtual device model.

This is the thesis statement of the entire message. The assistant had just run a comprehensive bandwidth sweep across transfer sizes from 12KB to 16MB (shown in the preceding message [msg 368]), revealing a consistent ~13µs latency floor for small transfers. By stating that these numbers are "virtually identical to before," the assistant is making a critical claim: all the hardware reconfiguration work — the chipset migration, the BAR reallocation, the IOMMU passthrough — had not moved the needle on the one metric that matters for cross-GPU communication latency.

The message then delivers the core conclusion under a bold header:

P2P (direct GPU-to-GPU DMA) cannot be enabled in this VM setup.

This is followed by three numbered reasons that systematically dismantle any remaining hope of a software fix.

The Reasoning: Three Layers of Impossibility

The assistant's argument unfolds in three logically ordered points, each building on the previous.

Point 1: The physical hardware topology prevents P2P even on bare metal. The eight GPUs are attached to eight separate PCIe root complexes on the AMD EPYC platform. There is no shared PCIe switch bridging them. On bare metal, any data transfer between these GPUs would traverse the CPU's Infinity Fabric — a path that is not true PCIe P2P. This is a crucial insight because it reframes the problem: the VM is not breaking something that would work on bare metal; rather, the VM is faithfully reproducing a hardware topology that was never designed for direct GPU-to-GPU DMA in the first place.

Point 2: VFIO mediation is the real bottleneck, not topology reporting. The assistant anticipates a potential objection — "what if we create virtual PCIe switches in QEMU to trick the NVIDIA driver?" — and preemptively dismantles it. Even if virtual PCIe switches changed the nvidia-smi topo output from "NS" to "PIX" (indicating GPUs behind a PCIe switch), the actual data path would remain unchanged. VFIO mediates all inter-GPU DMA through host memory, regardless of virtual topology tricks. The ~13µs latency floor is inherent to this GPU→host memory→GPU staged copy path, not to any configuration setting.

Point 3: The NVIDIA documentation on virtual PCIe topology applies to a fundamentally different scenario. The assistant references the HGX H200 guide found during research, which describes exposing NVLink-connected GPUs with NVSwitch through a VM. This is an entirely different hardware situation — one where real hardware P2P exists via NVLink and the VM simply needs to expose it correctly. The assistant is careful to distinguish this from the current setup, where no such hardware P2P path exists to expose.

Assumptions and Their Validation

The message reveals several assumptions that were tested and either validated or invalidated over the course of the investigation.

Assumption 1: P2P could be enabled with the right VM configuration. This was the implicit assumption driving the entire multi-day effort. The assistant had invested significant effort in migrating to Q35, enabling IOMMU passthrough, and disabling ACS — all in service of the belief that P2P was a configuration problem. Message [msg 369] represents the moment this assumption is finally laid to rest.

Assumption 2: IOMMU passthrough (iommu=pt) would improve cross-GPU bandwidth. The bandwidth tests showed that iommu=pt produced marginal improvements at best (33.67 GB/s vs ~32.6 GB/s for 4MB transfers). While iommu=pt does reduce IOMMU translation overhead for individual DMA operations, the dominant cost for cross-GPU transfers is the staged copy path through host memory, not the translation overhead.

Assumption 3: The "NS" status in nvidia-smi topo was the root cause of poor performance. The assistant's analysis suggests this is a red herring. The "NS" status is a symptom of the underlying hardware topology, not a separate problem. Even if the status were changed through virtual topology tricks, the actual performance would not improve because the data path would remain the same.

The Thinking Process: From Investigation to Conclusion

The thinking process visible in message [msg 369] and its surrounding context reveals a methodical, evidence-driven approach.

The assistant began by researching VFIO P2P configurations, consulting NVIDIA documentation, GitHub issues, and kernel patches. This research produced a critical insight: NVIDIA's own documentation on virtual PCIe topology was aimed at NVLink-connected systems, not the root-complex-isolated topology of the AMD EPYC platform.

The assistant then ran empirical tests — bandwidth sweeps across multiple transfer sizes — to establish a baseline and compare against earlier measurements. The discovery that the numbers were "virtually identical" despite all the configuration changes was the decisive evidence.

The structure of the argument — first establishing the empirical evidence (identical numbers), then stating the conclusion (P2P cannot be enabled), then providing three layers of reasoning, and finally offering actionable alternatives — reflects a deliberate rhetorical strategy. The assistant is not just delivering bad news; it is building an airtight case that no reasonable objection can penetrate.

Input Knowledge Required

To fully understand message [msg 369], several pieces of domain knowledge are necessary:

PCIe topology and root complexes: The concept of a PCIe root complex as the bridge between the CPU and PCIe devices, and the fact that devices on different root complexes cannot perform direct P2P DMA without CPU involvement.

VFIO and IOMMU groups: The Virtual Function I/O framework in Linux, which mediates device access in virtualized environments, and the IOMMU group concept that determines which devices can share DMA translations.

NVIDIA's P2P detection mechanism: The NVIDIA driver checks PCIe topology to determine whether P2P DMA is possible between GPUs. The "NS" status indicates the driver has determined that the hardware path does not support direct GPU-to-GPU transfers.

NCCL transport paths: NVIDIA Collective Communications Library can use different transport mechanisms — P2P (direct GPU-to-GPU DMA via PCIe or NVLink), SHM (shared memory via CPU), and network transports. The assistant's bandwidth test reveals that the SHM path is the fallback in this configuration.

The staged copy path: In virtualized environments without P2P, cross-GPU transfers follow a GPU→host memory (via PCIe DMA)→GPU path, with each hop adding latency.

Output Knowledge Created

Message [msg 369] creates several important pieces of knowledge:

A definitive diagnosis: The cross-GPU communication bottleneck in this VM is not a configuration problem but a fundamental hardware topology constraint. No amount of software tuning can create a P2P path where none exists in hardware.

A validated latency floor: The ~13µs minimum latency for small cross-GPU transfers is identified as the inherent cost of the virtualized staged-copy path. This provides a benchmark against which any future optimization can be measured.

A reframed problem: The "NS" status is identified as a red herring. The assistant explicitly states that the real bottleneck is "the 13µs per small transfer × many layers × many all-reduce ops" — shifting focus from topology to the communication pattern itself.

Actionable alternatives: Rather than leaving the user with a dead end, the assistant provides concrete optimization strategies: TP4+PP2 (reducing the number of GPUs in each all-reduce from 8 to 4), NCCL tuning for the SHM transport path, and benchmarking to see if the Q35/pcie=1 changes indirectly help sglang.

Mistakes and Incorrect Assumptions

While message [msg 369] is largely accurate and well-reasoned, it is worth examining whether any assumptions embedded in it could be challenged.

The assistant's claim that "even on bare metal, PCIe P2P between them would traverse the CPU's Infinity Fabric — it wouldn't be direct PCIe P2P" is technically correct but may understate the performance of Infinity Fabric on modern AMD EPYC processors. Infinity Fabric can achieve substantial bandwidth between sockets and within a socket, and bare-metal NCCL implementations may optimize for this path differently than the VFIO-mediated path in a VM. The key point — that P2P cannot be enabled in the VM — remains correct, but the bare-metal comparison could be nuanced.

The assistant's dismissal of virtual PCIe switches as purely cosmetic ("the actual data path wouldn't change") is also worth examining. While it is true that VFIO mediates all inter-GPU DMA through host memory, the efficiency of that mediation can vary. A virtual PCIe switch topology might enable different DMA mapping strategies or reduce TLB misses in the IOMMU. However, the bandwidth test results — showing no improvement from the Q35/pcie=1 changes — provide empirical support for the assistant's position that topology tricks do not help.

The Rhetorical Strategy: Delivering Bad News

Message [msg 369] is notable for its rhetorical structure. The assistant is delivering news that the user does not want to hear: after days of work, the core problem cannot be fixed. The message manages this by:

  1. Leading with evidence: The bandwidth numbers come first, establishing an objective foundation.
  2. Stating the conclusion clearly and boldly: "P2P (direct GPU-to-GPU DMA) cannot be enabled in this VM setup." No hedging, no "maybe," no "it depends."
  3. Providing layered reasoning: Three distinct arguments, each addressing a different aspect of the problem.
  4. Reframing the problem: The "NS" status is a red herring; the real bottleneck is the communication pattern.
  5. Offering a path forward: TP4+PP2, NCCL tuning, benchmarking — not just a dead end but a new direction. The final line — "Want me to proceed with launching sglang and benchmarking to see if there's any throughput improvement from the VM config changes, and then try TP4+PP2?" — pivots from diagnosis to action, giving the user a concrete next step.

Conclusion

Message [msg 369] represents a critical turning point in this opencode session. It is the moment when the investigation shifts from trying to fix a hardware constraint to optimizing within that constraint. The assistant's honest assessment — that P2P cannot be enabled due to the fundamental hardware topology — is delivered with clarity, evidence, and actionable alternatives.

The message demonstrates the value of systematic investigation: the assistant did not simply declare defeat but ran bandwidth tests, researched NVIDIA documentation, and built a multi-layered argument that no reasonable objection could penetrate. It also demonstrates the importance of knowing when to stop pursuing a dead end and pivot to what can actually be improved.

For the reader, message [msg 369] serves as a case study in diagnosing and accepting hardware constraints in virtualized environments, and in the art of delivering bad news in a way that preserves forward momentum.