The Boot-Time Gamble: Crafting an IOMMU Identity Script for Blackwell GPUs

Introduction

In the high-stakes world of large-scale GPU inference deployment, every optimization matters — and none is more consequential than peer-to-peer (P2P) DMA between GPUs. For the assistant managing a server with eight NVIDIA RTX PRO 6000 Blackwell GPUs split across two NUMA domains, the inability to use P2P DMA represented a critical performance bottleneck. Message [msg 6335] captures a pivotal moment in this debugging saga: the creation of a boot-time script designed to set IOMMU identity domains for four NUMA0 GPUs, enabling P2P DMA while preserving full IOMMU translation for the remaining four GPUs assigned to a SEV-SNP virtual machine. This message is a fascinating study in pragmatic engineering — a carefully reasoned attempt to solve an intractable runtime problem by shifting it to boot time, where the constraints are different.

The Message

The assistant's action is deceptively simple: it SSHs into the host machine (root@10.1.2.6) and writes a shell script to /usr/local/bin/gpu-iommu-identity.sh, then makes it executable:

ssh root@10.1.2.6 'cat > /usr/local/bin/gpu-iommu-identity.sh << '\''SCRIPT'\''
#!/bin/bash
# Set IOMMU identity domains for NUMA0 nvidia GPUs
# Must run BEFORE nvidia driver loads at boot
# 
# This enables GPU P2P DMA while keeping IOMMU in full translation 
# mode (amd_iommu=on) for SEV-SNP VM support.
#
# NUMA0 GPUs: 01:00.0, 11:00.0, 61:00.0, 71:00.0 -> identity (P2P works)
# NUMA1 GPUs: 81:00.0, 91:00.0, e1:00.0, f1:00.0 -> DMA-FQ (VFIO/SEV-SNP)

NUMA0_GPUS="0000:01:00.0 0000:11:00.0 0000:61:00.0 0000:71:00.0"

for gpu in $NUMA0_GPUS; do
    if [ ! -e /sys/bus/pci/devices/$gpu ]; then
        echo "gpu-iommu-identity: $gpu not found, skipping"
        continue
    fi
    
    # Check if driver is bound (at boot, should be none before nvidia loads)
    driver=$(basename $(readlink /sys/bus/pci/devices/$gpu/driver) 2>/dev/null || echo "none")
    if [ "$driver" != "none" ]; then
        echo "gpu-iommu-identity: $gpu bound to $driver, unbinding..."
        echo "$gpu" > /sys/bus/pci/devices/$gpu/driver/unbind 2>/dev/null || true
        sleep 0.5
    fi
    
    group=$(basename $(readlink /sys/bus/pci/devices/$gpu/iommu_group) 2>/dev/null)
    if [ -z "$group" ]; then
        echo "gpu-iommu-identity: $gpu has no IOMMU group, skipping"
        continue
    fi
    
    current=$(cat /sys/kernel/iommu_groups/$group/type 2>/dev/null)
    if [ "$current" = "identity" ]; then
        echo "gpu-iommu-identity: $gpu group $group already identity"
        continue
    fi
    
    echo "identity" > /sys/kernel/iommu_groups/$group/type 2>/dev/null
    result=$(cat /sys/kernel/iommu_groups/$group/type 2>/dev/null)
    echo "gpu-iommu-identity: $gpu group $group: $current -> $result"
done
SCRIPT
chmod +x /usr/local/bin/gpu-iommu-identity.sh
echo "Script created"'

The output is simply "Script created" — but the reasoning behind this seemingly mundane action is anything but simple.## The Reasoning: Why Boot Time?

To understand why the assistant created this script, we must trace the logic chain from the preceding messages. The context messages ([msg 6321] through [msg 6334]) reveal a multi-hour debugging session where the assistant systematically explored every avenue for enabling P2P DMA on Blackwell GPUs under an AMD IOMMU configured with amd_iommu=on (required for SEV-SNP virtual machine support).

The core problem is a tension between two requirements:

  1. P2P DMA requires IOMMU identity domains: When the IOMMU is in full translation mode (DMA-FQ), peer GPU direct memory access must go through IOMMU mappings. The nvidia driver's DmaRemapPeerMmio=1 parameter attempts to create these mappings automatically, but as the assistant discovered in [msg 6333], it produces only partial coverage — some GPU pairs work, others trigger IO_PAGE_FAULTs.
  2. SEV-SNP requires full IOMMU translation: The AMD Secure Encrypted Virtualization-Secure Nested Paging feature demands that the IOMMU be initialized in translation mode (amd_iommu=on). Setting the kernel-wide iommu.passthrough=1 boot parameter would break this requirement. The elegant solution is per-group IOMMU identity domains: set only the IOMMU groups containing the NUMA0 GPUs to identity mode, while leaving the NUMA1 groups in DMA-FQ mode for VFIO and SEV-SNP. This is exactly what the script attempts to do. But the assistant had already discovered a devastating constraint in [msg 6322]–[msg 6323]: the Blackwell GPU's Firmware Security Processor (FSP) cannot survive a driver rebind. When the nvidia driver is unloaded and reloaded, the FSP fails to reinitialize. This means the identity domain cannot be set at runtime — the nvidia driver must be loaded after the IOMMU groups are configured, and once loaded, it cannot be unloaded and reloaded. This leads to the boot-time strategy: at system boot, PCI devices are enumerated, IOMMU groups are created, and then device drivers are loaded. If the script runs in the narrow window after PCI enumeration but before the nvidia module loads, it can set the IOMMU groups to identity before nvidia ever touches the GPUs. The nvidia driver then probes the devices with identity-mode IOMMU groups already in place, and the FSP initializes correctly.

The Script's Design: Careful Engineering

The script itself reveals careful thought about edge cases and failure modes. It iterates over the four NUMA0 GPU PCI addresses (0000:01:00.0, 0000:11:00.0, 0000:61:00.0, 0000:71:00.0) and for each one:

  1. Checks existence: If the PCI device isn't present in sysfs, it skips gracefully. This handles the case where a GPU might not be detected or the PCI topology is different.
  2. Checks for an already-bound driver: At boot, before nvidia loads, the GPUs should have no driver bound. But the script defensively handles the case where some other driver (e.g., vfio-pci if the blacklist failed) might have grabbed the device. It attempts to unbind the driver before proceeding.
  3. Resolves the IOMMU group: Each PCI device belongs to an IOMMU group, which is the granularity at which domain types can be set. The script reads the group number from the sysfs symlink.
  4. Idempotency check: If the group is already identity, it skips. This is important for robustness — the script might be called multiple times during boot.
  5. Sets the domain type: The critical action — writing &#34;identity&#34; to /sys/kernel/iommu_groups/$group/type. This tells the IOMMU subsystem to use identity (passthrough) mapping for this group, meaning DMA addresses from devices in this group are not translated.
  6. Logs the result: Every action produces a log line prefixed with gpu-iommu-identity:, making it easy to debug from the system journal. The script also documents its purpose and the GPU assignment clearly in the comments, showing awareness that this is a system-critical configuration file that other administrators might need to understand.

Assumptions and Knowledge Required

To fully understand this message, several pieces of input knowledge are necessary:

The Output Knowledge Created

This message produces a deployable shell script that represents a concrete hypothesis: that IOMMU identity domains can be set at boot time, before the nvidia driver loads, and that this will enable full P2P DMA for all four NUMA0 GPUs without breaking the Blackwell FSP initialization. The script is designed to be triggered by a systemd service (not yet created in this message, but implied by the comment "Must run BEFORE nvidia driver loads at boot").

The script also serves as a piece of operational documentation, encoding the server's GPU topology and IOMMU strategy in executable form. Any future administrator can read the script to understand which GPUs are assigned to identity mode and why.

The Mistake: What the Assistant Didn't Yet Know

This is where the story becomes tragicomic. The chunk summary for segment 41 reveals that this entire approach is doomed. When the assistant later tests the boot-time identity domain configuration, it discovers that the Blackwell FSP boot sequence fails with error code 0x177 even when identity domains are set before the nvidia driver loads. The FSP apparently requires specific DMA mappings that are only set up by the kernel's DMA API in translation mode — identity mode starves the FSP of these mappings, causing initialization failure.

This means that per-group IOMMU identity domains are fundamentally incompatible with Blackwell GPUs, regardless of timing. The approach cannot work. The assistant eventually reverts the change, removes the modprobe hook, and returns to the working DMA-FQ configuration with NCCL_P2P_DISABLE=1.

The irony is that the script is beautifully engineered for a problem that turns out to be unsolvable through this mechanism. The assistant's careful handling of edge cases — checking for driver binding, idempotency, graceful skipping — is all in service of a strategy that hits a hard hardware limitation.

The Thinking Process

The assistant's reasoning in this message reflects a sophisticated understanding of Linux kernel internals, PCI device enumeration, IOMMU architecture, and NVIDIA GPU firmware behavior. The key insight — that boot-time configuration avoids the driver rebind problem — is elegant and shows system-level thinking. The assistant correctly identifies that the constraint is temporal (nvidia must be loaded after IOMMU groups are configured) rather than functional (identity domains themselves don't cause the FSP to fail).

The decision to create a standalone script rather than a systemd service directly is also telling. The assistant is building the component pieces first — the script that does the actual work — before wrapping it in a service file. This modular approach allows testing the script independently before integrating it into the boot sequence.

The assistant also demonstrates awareness of the broader system context. The comments in the script explicitly mention SEV-SNP VM support, showing that the assistant is balancing the P2P DMA requirement for inference workloads against the security requirements of the virtual machine. This is not a single-issue optimization but a system-wide configuration decision.

Conclusion

Message [msg 6335] captures a moment of optimism and careful engineering in a debugging session that ultimately leads to a dead end. The boot-time IOMMU identity script is a well-reasoned attempt to solve an intractable runtime problem by changing the temporal ordering of system initialization. While the approach ultimately fails due to Blackwell FSP limitations, the reasoning process and system knowledge on display are instructive. The script itself stands as a monument to the kind of deep kernel-level debugging that modern AI infrastructure demands — and a reminder that sometimes, even the most elegant software solution cannot overcome hardware constraints.