The Passthrough Paradox: Wrestling IOMMU Identity Domains on Blackwell GPUs

Introduction

In the course of a complex infrastructure debugging session spanning GPU topology reconfiguration, IOMMU domain manipulation, and NVIDIA driver internals, message [msg 6325] captures a pivotal moment of strategic reconsideration. The assistant, having spent multiple rounds battling a chicken-and-egg problem with Blackwell GPU initialization under IOMMU identity domains, pauses to evaluate a fundamentally different approach: changing the kernel's default IOMMU domain type via boot parameters. This message is a window into real-time technical decision-making under constraints, where the assistant weighs architectural knowledge, empirical evidence from earlier failures, and external coordination boundaries to chart the next course of action.

The Context: Why This Message Was Written

To understand why message [msg 6325] exists, one must appreciate the deadlock that preceded it. The session's overarching goal was to restore P2P (peer-to-peer) DMA between Blackwell GPUs on a system with SEV-SNP (Secure Encrypted Virtualization - Secure Nested Paging) enabled. P2P DMA requires IOMMU groups to be in "identity" (passthrough) mode, where DMA requests bypass translation. However, the assistant had discovered a critical incompatibility: the Blackwell GPU's Firmware Security Processor (FSP) fails during boot with error code 0x177 when IOMMU is in identity mode, apparently requiring specific DMA mappings that only translation mode provides.

The assistant had been attempting a delicate surgical approach: set the IOMMU groups to identity mode while the GPUs were unbound from the NVIDIA driver, then remove the GPUs from the PCI bus, perform a Secondary Bus Reset (SBR), reload the NVIDIA driver, and rescan — hoping the fresh probe would succeed with identity mode already in place. This failed repeatedly. The root cause was a fundamental ordering constraint: NVIDIA's modprobe refuses to load without matching PCI devices present, but the identity mode had to be set before the GPUs reappeared. The assistant could not set identity mode while NVIDIA was bound to the devices, could not unbind NVIDIA without corrupting the FSP state, and could not load NVIDIA without devices present. Every path led to a dead end.

Message [msg 6325] opens with the assistant having just restored working GPUs under the default DMA-FQ (translation) mode using the sequence of loading NVIDIA first, then rescanning. This was the recovery path, not the solution. The real problem — enabling identity mode for P2P — remained unsolved. The message represents the moment when the assistant pivots from surgical runtime manipulation to considering a systemic kernel-level configuration change.

The Reasoning Process: A Journey Through Kernel Parameters

The message reveals a multi-layered reasoning process that unfolds in real time. The assistant begins by introducing the concept of a kernel boot parameter: iommu.passthrough=1. This parameter, when set in the kernel command line, changes the default IOMMU domain type to identity (passthrough) for all devices. The assistant immediately identifies the critical question: "The question is whether this breaks SEV-SNP."

This is the crux of the tension. SEV-SNP is a security feature that encrypts VM memory and requires active IOMMU translation to enforce access controls. If passthrough mode disables the IOMMU's ability to enforce these protections, SEV-SNP could be compromised. The assistant's reasoning shows awareness that VFIO (the driver used for the VM's GPUs) "overrides this for its own devices," meaning VFIO creates translated domains regardless of the default. This is a crucial insight: the kernel's IOMMU subsystem allows individual device drivers to request specific domain types, so a global passthrough default would not force VFIO-managed devices into identity mode — they would still get translation.

The assistant then refines the approach, considering iommu=pt as an alternative parameter. This is a slightly different mechanism — iommu=pt is a legacy parameter that enables passthrough mode for the Intel IOMMU, while iommu.passthrough=1 is the generic parameter. The assistant's thinking shows a deep understanding of the kernel's IOMMU architecture, distinguishing between the AMD IOMMU (amd_iommu=on) and the generic IOMMU subsystem parameters.

A critical assumption surfaces: "The research said that VFIO always creates its own translated domain regardless." This assumption is based on prior knowledge of VFIO internals — that VFIO explicitly requests DMA translation domains for its devices, overriding any global default. If this assumption holds, then iommu.passthrough=1 would give NVIDIA GPUs identity mode (enabling P2P) while VFIO GPUs retain translation (preserving SEV-SNP compatibility). The assistant hedges, noting "the notes say SEV-SNP requires non-passthrough mode," acknowledging uncertainty.

The reasoning then deepens further. The assistant recalls kernel source details: "amd_iommu=on + iommu.passthrough=1 would set the default domain to identity but keep the AMD IOMMU initialized in translation mode." This is a nuanced understanding — the AMD IOMMU hardware can be initialized in translation mode (which is what amd_iommu=on ensures) while the default domain type for devices is identity. The IOMMU hardware remains capable of translation; it simply doesn't assign translation domains to devices by default. The SEV-SNP check specifically looks for amd_iommu=on to confirm the IOMMU hardware is active, not to check the domain type of individual devices. This suggests the approach might work.

The Constraint That Changed Everything

Then comes the pivotal moment: "But I was told not to reboot or change kernel cmdline without coordination." This external constraint — a coordination boundary with the user or system administrator — forces the assistant to abandon the boot parameter approach entirely. The assistant cannot simply try it and see; the reboot requirement makes it a coordinated action.

This constraint is what makes the message so interesting. The assistant has just reasoned through a complex multi-layered analysis of kernel parameters, IOMMU internals, VFIO behavior, and SEV-SNP requirements, arriving at a plausible solution — only to be blocked by a non-technical constraint. The assistant immediately pivots: "Let me try yet another approach — can we write to the kernel's default domain parameter at runtime?"

The Runtime Probe: Seeking an Escape Hatch

The assistant executes a bash command to probe for runtime-accessible kernel parameters:

cat /sys/module/iommu/parameters/* 2>/dev/null
ls /sys/module/iommu/parameters/ 2>/dev/null
cat /proc/cmdline | tr " " "\n" | grep iommu

This probe checks two things: first, whether the iommu kernel module exposes any writable parameters via the parameters sysfs directory (which would allow changing the default domain type without a reboot); second, what IOMMU-related kernel command-line parameters are currently active.

The result is revealing: amd_iommu=on is the only IOMMU parameter in the kernel command line, and the iommu module's parameters directory appears empty (or doesn't exist), meaning there is no runtime knob to change the default domain type. The assistant's hope for a runtime escape hatch is dashed.

Assumptions and Their Implications

Several assumptions underpin the reasoning in this message:

  1. VFIO always creates translated domains: This is a well-founded assumption based on VFIO's architecture, but it has not been empirically verified on this specific kernel version (likely 6.8+ given the Ubuntu 24.04 context). If this assumption were wrong, setting iommu.passthrough=1 could break the VM's GPU passthrough.
  2. SEV-SNP only checks for amd_iommu=on: The assistant assumes the SEV-SNP initialization path only verifies the IOMMU is active, not that specific devices use translation domains. This is plausible but not confirmed.
  3. The iommu module has no runtime parameters: The probe confirms this, but the assumption that this is the only path to change the default domain type at runtime may be incomplete — there could be other mechanisms (e.g., iommu_group type files, which the assistant has been using, or device-specific overrides).
  4. The kernel cmdline is the only way to change the default: This appears correct based on the kernel's IOMMU architecture, where the default domain type is determined at boot time and cannot be changed dynamically.

Input Knowledge Required

To fully understand this message, one needs:

Output Knowledge Created

This message produces several valuable pieces of knowledge:

  1. Confirmation that no runtime parameter exists for changing the default IOMMU domain type on this system
  2. Confirmation that the kernel cmdline only contains amd_iommu=on, with no passthrough or other IOMMU parameters
  3. A documented reasoning chain for why iommu.passthrough=1 might work with SEV-SNP (VFIO override, AMD IOMMU hardware remaining active)
  4. A clear constraint boundary: the assistant cannot proceed with boot parameter changes without coordination
  5. The dead end of runtime approaches: all paths to setting identity mode without a reboot have been exhausted

The Broader Significance

Message [msg 6325] is a microcosm of the entire session's struggle. The assistant has been chasing a solution that requires setting IOMMU identity mode for Blackwell GPUs, but every approach runs into fundamental incompatibilities: the FSP boot failure under identity mode, the chicken-and-egg problem with NVIDIA driver loading, and now the constraint against boot parameter changes. The message captures the moment when the assistant realizes that the only remaining option — a kernel boot parameter — is blocked by coordination requirements, and that runtime alternatives don't exist.

This message also demonstrates the assistant's disciplined approach to problem-solving. Rather than forcing the boot parameter change without coordination (which might work but violates the constraint), the assistant explicitly acknowledges the constraint and pivots to explore alternatives. When those alternatives fail, the assistant doesn't give up — it documents the findings and prepares to present the situation to the user for a coordinated decision.

The final result — the bash command output showing only amd_iommu=on — is a quiet anticlimax. After pages of complex reasoning about kernel parameters, VFIO behavior, and SEV-SNP requirements, the answer is simply: there is no runtime knob, and a reboot is required but blocked. This anticlimax is itself instructive: sometimes the most important output of a debugging session is not a solution but a clear map of the solution space, showing which paths are viable and which are blocked.

Conclusion

Message [msg 6325] is a masterclass in constrained technical reasoning. The assistant navigates a complex problem space involving kernel internals, GPU firmware behavior, virtualization security features, and operational constraints, all while maintaining a clear chain of reasoning. The message shows the importance of understanding not just the technical solution but also the boundaries within which solutions must operate. When the assistant realizes the boot parameter approach is blocked, it doesn't stop — it probes for alternatives, documents the dead ends, and prepares to communicate the situation clearly. This is the essence of disciplined system debugging: not just finding the answer, but mapping the entire problem space so that informed decisions can be made.