The P2P Question: When IOMMU Blocks GPU-to-GPU DMA

Subject Message (msg 6238): [user] Is there anything that can be done to get p2p going with iommu? Any bios settings about iommu coverage, related settingsL

Introduction

In the middle of an intense, multi-session optimization campaign deploying large language models on a cluster of 8× NVIDIA RTX PRO 6000 Blackwell GPUs, a single user question arrives that cuts to the heart of a fundamental tension in modern hardware virtualization. The message is brief—just two sentences, one of them trailing off with a typo ("settingsL" instead of "settings?")—but it represents a pivot point in the conversation. The user, who has just been presented with a successful deployment of Qwen3.5-122B-A10B BF16 achieving up to 2,800 tok/s at high concurrency, is not satisfied. They want to know if the performance penalty imposed by the IOMMU can be eliminated, restoring the full GPU-to-GPU peer-to-peer DMA capability that was sacrificed as a workaround.

This article examines that single message: why it was written, the assumptions it encodes, the knowledge it draws upon, and the investigation it triggered.

Context: How We Got Here

To understand the question, one must understand the chain of events that preceded it. The system under management is a Proxmox VE host running Ubuntu 24.04 with 8× RTX PRO 6000 Blackwell GPUs (96 GB GDDR7 each, PCIe Gen5 x16). These GPUs are split into two groups of four: NUMA 0 GPUs are bound to the nvidia driver for an LXC container running SGLang inference, while NUMA 1 GPUs are bound to vfio-pci for passthrough to a SEV-SNP confidential VM managed by another tenant.

The SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging) configuration requires the kernel to boot with amd_iommu=on in full translation mode, rather than the more permissive iommu=pt (passthrough) mode. This is not optional—AMD's SEV-SNP specification mandates full IOMMU translation for the memory encryption and integrity guarantees it provides. The consequence, however, is severe: every GPU-to-GPU peer-to-peer DMA transfer through the IOMMU produces corrupted data, as the IOMMU has no mappings for GPU BAR addresses in peer devices' domains. The assistant diagnosed this through IO_PAGE_FAULTs in dmesg and confirmed it with a CUDA P2P copy test that showed every inter-GPU transfer producing mismatches.

The workaround was NCCL_P2P_DISABLE=1, which forces NCCL to use shared memory (SHM) transport instead of P2P DMA. This works correctly—NCCL all-reduce passes validation—but it comes at a performance cost. The assistant's own benchmark summary shows the Qwen3.5-122B BF16 model achieving 108 tok/s single-stream and 2,800 tok/s at C=128 concurrency. The user, looking at these numbers and knowing the hardware's theoretical capability, asks the natural question: can we have both security and performance?

The Reasoning and Motivation Behind the Question

The user's question is motivated by a sophisticated understanding of the trade-off at play. They are not asking "why is it slow?"—they already know the answer. They are asking "can we fix the root cause?" This is a qualitatively different kind of question. It signals that the user is thinking at the systems architecture level, not just the application level.

The user has just received ([msg 6237]) a detailed summary of the current configuration, which explicitly lists "NCCL: P2P disabled (IOMMU full translation breaks GPU-to-GPU DMA)" as a known limitation. The assistant's summary also includes a "Critical Fix: IOMMU / P2P" section explaining that the SEV-SNP setup changed IOMMU from passthrough to full translation mode. The user's question directly engages with this limitation.

The trailing "L" in "settingsL" is a typo—likely "settings?" was intended—but it reveals the casual, rapid-fire nature of the interaction. The user is typing quickly, engaged, and thinking about the next step even as the assistant is presenting the current state.

Several implicit assumptions underlie the question:

1. P2P DMA is worth restoring. The user assumes that the performance gain from P2P DMA justifies the effort of investigating BIOS and kernel options. This is a reasonable assumption: P2P DMA avoids a trip through system memory, reducing latency and bandwidth pressure on the memory bus. For NCCL all-reduce operations—which are the backbone of tensor parallelism in LLM inference—P2P can significantly improve throughput.
2. There might be a BIOS setting that helps. The user specifically asks about "iommu coverage" and "related settings." This suggests familiarity with AMD IOMMU architecture, where "coverage" likely refers to the address space that the IOMMU translates. If the IOMMU could be configured to cover (or not cover) the GPU BAR regions, P2P transfers might bypass translation entirely.
3. The solution might not require disabling SEV-SNP. The user does not ask "can we turn off SEV-SNP?" They ask about restoring P2P with IOMMU still active. This is a constrained optimization problem: maximize performance within the security boundary.
4. The assistant can investigate without making changes. The question is framed as research ("Is there anything that can be done...?"), not as an instruction to change settings. This is important because the user has previously instructed the assistant not to reboot the host or change BIOS settings without coordination, as another tenant is active.

Input Knowledge Required to Understand This Message

A reader needs substantial context to grasp the significance of this question:

• IOMMU modes: Understanding the difference between IOMMU passthrough mode (iommu=pt), where devices can DMA directly to physical addresses without translation, and full translation mode (amd_iommu=on), where all DMA goes through the IOMMU's address translation tables. This is not a trivial distinction—it affects every PCIe device in the system.
• GPU P2P DMA: The mechanism by which GPUs transfer data directly to each other's memory without involving the CPU or system RAM. This is critical for multi-GPU tensor parallelism, where model shards must communicate activations and gradients.
• SEV-SNP requirements: AMD's Secure Encrypted Virtualization with Secure Nested Paging requires full IOMMU translation to enforce memory encryption and integrity. This is a hardware security feature for confidential computing, not something that can be disabled without losing the security guarantee.
• NCCL (NVIDIA Collective Communications Library): The library that handles multi-GPU communication in PyTorch. Its P2P_DISABLE flag forces fallback to SHM transport, which uses system memory as an intermediary.
• The hardware topology: 8× RTX PRO 6000 Blackwell GPUs on PCIe Gen5, split across two NUMA domains, with four in an LXC container and four in a SEV-SNP VM.
• The previous diagnostic work: The assistant's P2P corruption test, NCCL validation, and dmesg IO_PAGE_FAULT analysis are all prerequisites for understanding why the question matters.

Output Knowledge Created by This Message

The question itself is only two sentences, but it generates a substantial investigation. The assistant responds by:

1. Examining the kernel cmdline on the Proxmox host to confirm the boot parameters (amd_iommu=on, mem_encrypt=on, kvm_amd.sev=1).
2. Checking IOMMU group assignments for each GPU, discovering that each GPU is in its own IOMMU group (ACS enabled) with type DMA-FQ (DMA with flush queue).
3. Researching per-group IOMMU identity domains via sysfs (/sys/kernel/iommu_groups/<id>/type), a feature available since kernel v5.11 that allows setting specific IOMMU groups to "identity" (passthrough) mode while leaving others in translation mode.
4. Spawning a subagent task to deeply investigate the feasibility of per-group identity domains, including whether this would break SEV-SNP requirements. The investigation reveals a promising lead: the Linux kernel's sysfs interface for IOMMU groups supports switching individual groups to identity (passthrough) mode. If the four nvidia-bound GPUs (NUMA 0) could be placed in identity domains while the four vfio-pci GPUs (NUMA 1) remain in translation mode for SEV-SNP, P2P DMA might be restored for the inference workload without compromising the confidential VM's security.

Assumptions and Potential Mistakes

The user's question makes one critical assumption that deserves scrutiny: that restoring P2P DMA would meaningfully improve throughput. While P2P is generally faster than SHM transport, the benchmark results show the system already achieving 2,800 tok/s at C=128 with P2P disabled. The bottleneck may not be inter-GPU communication at all—it could be compute-bound (MoE expert computation) or memory-bandwidth-bound (KV cache access). If P2P restoration yields only marginal gains, the engineering effort might be better spent on other optimizations like MTP/NEXTN speculative decoding or fused MoE all-reduce.

There is also an unstated assumption that per-group IOMMU identity domains are compatible with SEV-SNP. This is not guaranteed. SEV-SNP's security model may require all DMA to go through IOMMU translation to prevent side-channel attacks or integrity violations. If even one device bypasses translation, the entire security posture could be compromised. The assistant's subagent research correctly identifies this as an open question requiring further investigation.

The typo "settingsL" is minor but worth noting—it suggests the user was typing quickly and may not have fully formulated the question. The trailing character could indicate they were interrupted or moved on to the next thought before finishing.

The Thinking Process Visible in the Conversation

The user's question reveals a pattern of thinking that has characterized the entire session: probe the constraint boundary. Throughout the conversation, the user has consistently pushed back against limitations, asking whether each workaround can be replaced with a proper fix. When flash-attn failed to build, they asked about compilation flags. When FP8 KV cache produced NaN outputs, they asked about BF16 forcing. When the GPU split broke NCCL, they asked about P2P disable. Now, with P2P disabled, they ask about restoring it.

This is not a user who accepts "no" as a final answer. They understand that systems engineering is about trade-offs, and they want to explore the full design space before settling on a compromise. The question is also remarkably well-scoped: it doesn't ask "fix P2P" (which would require changing the SEV-SNP configuration), but rather "can P2P work with IOMMU?"—a much more constrained and answerable question.

The assistant's response pattern mirrors this thinking. Rather than immediately trying BIOS changes (which would require coordination with the other tenant), the assistant first gathers information: kernel cmdline, IOMMU group assignments, sysfs features. Then it spawns a research subagent to investigate the per-group identity domain approach. This methodical, information-first approach is exactly what the user's question demands.

Conclusion

The user's two-sentence question at msg 6238 is a masterclass in constrained optimization inquiry. It acknowledges the current workaround (P2P disabled), identifies the root cause (IOMMU full translation), and asks whether the constraint itself can be relaxed without violating the security requirements that imposed it. The question generates a rich investigation into per-group IOMMU identity domains, kernel sysfs interfaces, and the boundary conditions of AMD's SEV-SNP specification. Whether or not the approach ultimately works, the question itself demonstrates the kind of systems-level thinking that drives real engineering progress: never accept a workaround as final until you've explored every path to a proper fix.