The Research Pivot: When Virtualization Meets Hardware Reality in GPU P2P DMA

Introduction

In the long arc of deploying a massive 8-GPU inference system for the GLM-5-NVFP4 model across NVIDIA RTX PRO 6000 Blackwell GPUs inside a Proxmox virtual machine, there comes a moment of reckoning. After successfully resolving a crippling BAR allocation failure that prevented six of eight GPUs from being detected—fixed through a combination of Q35 chipset migration, PCIe passthrough, and the pci=realloc kernel parameter—the team faced a new, more fundamental obstacle. Message 366 captures this moment: a pure research message, devoid of bash commands or configuration changes, where the assistant pivots from "let's benchmark" to "let's understand why P2P doesn't work." This single message, consisting of two webfetch calls to NVIDIA documentation and a GitHub issue, represents the critical transition from tactical problem-solving to architectural investigation.

The Message

The subject message is concise in its structure but rich in its intent. The assistant issues two webfetch calls in parallel:

[assistant] [webfetch] {"format":"markdown","url":"https://github.com/NVIDIA/nccl/issues/1329"}
                             Why can't two GPUs in a virtual machine communicate using P2P？ · Issue #1329 · NVIDIA/nccl · GitHub
[webfetch] {"format":"markdown","url":"https://docs.nvidia.com/ai-enterprise/planning-resource/optimizing-vm-configuration-ai-inference/latest/configuring-vms.html"}
  Configuring Virtual Machines — Optimizing VM Configuration for Performant AI Inference

The message also contains the full fetched content from both URLs—the GitHub issue page and the NVIDIA documentation page—but the essence of the message is the research action itself: two parallel information-gathering operations. No analysis, no conclusions, no bash commands—just the raw act of fetching external knowledge.

Two URLs, fetched in parallel. No analysis, no conclusions, no tool output shown—just the raw act of gathering information. This is the assistant's research phase, and the message is deliberately sparse because it is waiting for the web fetches to complete before it can synthesize the findings into a coherent plan.

Why This Message Was Written: The Motivation and Context

To understand why this message exists, one must trace the conversation's immediate history. In the preceding messages, the assistant had achieved a significant milestone: all 8 GPUs were fully operational inside the VM, each with its full 96GB of VRAM, and the PCIe topology had improved from a flat bus (under the legacy i440FX chipset) to proper PHB (PCIe Host Bridge) connections under Q35. The nvidia-smi topo -m output showed PHB connections between all GPU pairs—a marked improvement over the earlier configuration.

Yet the nvidia-smi topo -p2p r output told a different story. Every cell read "NS"—Not Supported. Peer-to-peer DMA, the mechanism by which GPUs can directly exchange data across the PCIe bus without routing through system memory or the CPU, was entirely absent. This is a critical capability for multi-GPU inference workloads, where model parallelism (especially tensor parallelism and expert parallelism) requires frequent, low-latency communication between GPUs. Without P2P, every cross-GPU data transfer must traverse the host memory path, incurring significant latency overhead and consuming CPU and memory bandwidth.

The assistant's immediate instinct, shown in message 362, was to proceed with benchmarking anyway: "Let me now launch the sglang server and benchmark to see if the Q35+PCIe changes alone improve throughput." This was a reasonable impulse—after all, the GPUs were working, and measuring the actual impact of the topology change would provide valuable data. But the user intervened in message 364 with a clear redirection: "no bench, first can we fix p2p properly?"

This intervention changed the trajectory. The assistant acknowledged the correction in message 365: "You're right — let's focus on getting P2P working before benchmarking. P2P is still NS despite Q35+pcie=1+iommu=pt. Let me research what's needed for VFIO P2P between GPUs in a KVM VM." This sets the stage for message 366, which is the execution of that research plan.

The Research Targets: What the Assistant Chose to Investigate

The two URLs selected for fetching reveal the assistant's strategic thinking about where to look for answers.

First target: NVIDIA NCCL GitHub Issue #1329. The title is almost perfectly matched to the problem at hand: "Why can't two GPUs in a virtual machine communicate using P2P?" This is a community-driven resource, an issue tracker where users and developers have grappled with the exact same problem. By choosing this, the assistant is tapping into collective experience—someone else has almost certainly faced this barrier and either found a workaround or documented the fundamental limitation. The GitHub issue format often contains detailed debugging logs, configuration snippets, and resolution paths (or definitive statements of impossibility). This is the "tribal knowledge" channel.

Second target: NVIDIA's official documentation on configuring VMs for AI inference. This is the authoritative source. NVIDIA's AI Enterprise documentation provides best practices for virtualized GPU deployments, including guidance on VM configuration for optimal inference performance. By fetching this page, the assistant is seeking the vendor's official stance on P2P in virtualized environments. This is the "ground truth" channel—if NVIDIA's docs say P2P requires certain conditions (like NVSwitch, GPU Direct, or specific vGPU configurations), then that becomes the baseline reality that must be accepted or worked around.

The choice of these two targets—one community-driven, one vendor-official—shows a methodical approach to research. The assistant is triangulating: what do real users say, and what does the vendor say? The convergence (or divergence) of these sources will inform the next steps.

Input Knowledge Required to Understand This Message

A reader coming to this message without context would need to understand several layers of technical background:

PCIe topology and P2P DMA. Peer-to-peer DMA allows devices on the PCIe bus to transfer data directly between their memory spaces without involving the host CPU or system RAM. This is essential for multi-GPU workloads because model-parallel inference requires frequent all-reduce and all-gather operations across GPU shards. Without P2P, these operations must go through host memory, which adds latency and consumes memory bandwidth.

VFIO and IOMMU in KVM. VFIO (Virtual Function I/O) is the framework used by QEMU/KVM to pass through physical devices to virtual machines. The IOMMU (I/O Memory Management Unit) provides DMA remapping and device isolation. For P2P to work between two passed-through GPUs, the IOMMU must be configured to allow direct DMA between the devices' memory regions. This requires the devices to be in the same IOMMU group—a condition that depends on the physical PCIe topology.

Proxmox and Q35 chipset. Proxmox VE is a virtualization platform based on QEMU/KVM. The Q35 chipset provides a more modern PCIe topology than the legacy i440FX, supporting PCIe root ports and proper PCIe hierarchy. The migration to Q35 was a prerequisite for getting all 8 GPUs detected, but it did not automatically enable P2P.

The ASUS ESC8000A-E13 motherboard and AMD EPYC platform. The physical hardware platform matters enormously. The ASUS ESC8000A-E13, based on the AMD EPYC 9335, has each GPU connected to its own dedicated PCIe root complex. This design maximizes per-GPU bandwidth (each GPU gets a direct x16 Gen5 link to the CPU) but creates separate IOMMU domains. Without a PCIe switch to bridge these domains, VFIO cannot grant cross-domain P2P access.

Output Knowledge Created by This Message

This message does not produce direct output in the form of commands executed or configurations changed. Its output is latent—it sets up the information that will be synthesized in subsequent messages. The knowledge created includes:

  1. A confirmed research direction. The assistant has committed to understanding the P2P limitation rather than working around it blindly. This shifts the conversation from "how do we make it work" to "why doesn't it work, and can it be made to work?"
  2. A dual-source evidence base. By fetching both a community issue and official documentation, the assistant is building a foundation for a well-informed recommendation. The synthesis of these sources will determine whether the next steps involve kernel parameter hacks, hardware topology changes, or acceptance of the limitation.
  3. A framing of the problem as architectural rather than configurational. The choice to research P2P in virtualized environments—rather than trying random kernel parameters or ACS overrides—frames the problem as one of fundamental architecture. This is a mature engineering response: before attempting workarounds, understand the constraints.

Assumptions and Potential Mistakes

The message itself contains no explicit assumptions—it is purely a fetch operation. However, the decision to research in this direction carries implicit assumptions:

Assumption: P2P is fixable through software configuration. The assistant is researching P2P enablement, which implies a belief that it might be possible to enable it through the right combination of VM settings, kernel parameters, or VFIO configuration. This assumption is challenged by the hardware topology reality discovered in later messages: each GPU sits on its own PCIe root complex, and no amount of software configuration can merge separate IOMMU domains that are physically isolated at the hardware level.

Assumption: The official NVIDIA documentation will provide actionable guidance. The assistant assumes that NVIDIA's VM configuration guide will contain relevant information about P2P in virtualized environments. This may or may not be true—the documentation might focus on vGPU configurations rather than raw passthrough, or it might simply state that P2P is not supported in VMs without addressing the underlying reasons.

Potential mistake: Not researching the host-side IOMMU group topology first. The assistant had already investigated IOMMU groups on the Proxmox host in earlier messages, discovering that ACS disable did not merge the groups. However, the research in message 366 focuses on VM-side and software-level solutions rather than confirming the hardware-level impossibility. A more direct approach might have been to research "IOMMU groups separate root complexes P2P impossible" rather than the more general "GPU P2P in VM."

The Thinking Process Visible in the Message

While the message itself does not contain explicit reasoning text (it is purely tool calls), the thinking process is visible in the selection of research targets. The assistant's reasoning can be reconstructed:

  1. Problem identification: P2P shows "NS" for all GPU pairs despite successful Q35 migration and PCIe passthrough.
  2. Hypothesis formation: The issue is related to VFIO/IOMMU configuration in the KVM environment, not to the guest OS or NVIDIA driver settings.
  3. Research strategy: Gather information from two complementary sources—community experience (GitHub issues) and vendor guidance (NVIDIA documentation).
  4. Execution: Launch parallel fetches to both sources, minimizing latency. The choice to use webfetch (a tool for fetching web content as markdown) rather than bash (for running commands on the host or guest) is significant. It signals that the assistant has exhausted the diagnostic commands available on the systems and needs external knowledge. The VM and host have been queried, dmesg has been examined, nvidia-smi has been run—the data is in. Now it's time to interpret that data against known solutions and documented constraints.

Broader Implications: The Virtualization Tax on GPU Computing

This message, in its quiet way, touches on one of the most significant challenges in modern AI infrastructure: the tension between virtualization (which provides isolation, flexibility, and manageability) and the demands of tightly-coupled multi-GPU workloads. NVIDIA's GPUs were designed for bare-metal deployments where P2P DMA is straightforward. Virtualization layers like KVM/VFIO introduce IOMMU domains that, while essential for security and isolation, can block the direct device-to-device communication that high-performance inference requires.

The research pivot in message 366 acknowledges that this is not a simple configuration problem. It is an architectural tension. The Proxmox host, the AMD EPYC platform, the ASUS motherboard design, the VFIO framework, and the NVIDIA driver all interact to produce the "NS" result. Fixing it may require changes at any of these layers—or acceptance that in this particular hardware topology, P2P is fundamentally unavailable.

Conclusion

Message 366 is a research message, and its value lies not in what it produces but in what it sets up. It is the calm before the storm of technical investigation that follows. The assistant, redirected by the user from benchmarking to problem-solving, methodically selects two high-quality information sources to understand why P2P DMA remains out of reach. This message represents the disciplined engineer's first step when faced with an unexplained limitation: stop, research, understand. The answers it yields—both from the community and from NVIDIA's own documentation—will shape the next phase of the conversation, determining whether the team can enable P2P through clever configuration or must accept the hardware topology's hard constraints.