The Boot-Time Gamble: Creating a Systemd Service for Blackwell GPU P2P DMA Under IOMMU

Introduction

In the high-stakes world of multi-GPU inference serving, every microsecond counts. When eight NVIDIA RTX PRO 6000 Blackwell GPUs are split between a production inference server and a confidential VM protected by AMD SEV-SNP, the IOMMU becomes both a security necessity and a performance bottleneck. Message [msg 6336] captures a pivotal moment in a deep debugging session: the creation of a systemd service designed to enable GPU peer-to-peer (P2P) DMA by switching IOMMU groups to identity mode at boot time — a carefully engineered workaround for a fundamental hardware incompatibility.

This article examines the reasoning, assumptions, and design decisions embedded in this single message, and traces the tragic arc of a solution that was logically sound but ultimately defeated by the very firmware it sought to enable.

The Message

The assistant executes two commands over SSH to the host at 10.1.2.6:

ssh root@10.1.2.6 'cat > /etc/systemd/system/gpu-iommu-identity.service << EOF
[Unit]
Description=Set IOMMU identity domains for NUMA0 nvidia GPUs (enables P2P DMA)
# Must run after PCI enumeration but before nvidia driver loads
After=systemd-modules-load.service
Before=nvidia-persistenced.service
# Also before our vfio split service (which runs before nvidia-persistenced)
Before=gpu-vfio-split.service
DefaultDependencies=no

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/bin/gpu-iommu-identity.sh

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable gpu-iommu-identity.service
echo "Service enabled"'

The output confirms success: Created symlink ... Service enabled.

The Problem: IOMMU Translation vs. GPU P2P DMA

To understand why this message exists, we must understand the architectural conflict at its heart. The system runs with amd_iommu=on to support AMD SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging), a hardware memory encryption feature for confidential VM workloads. SEV-SNP requires the IOMMU to be in full translation mode — every DMA transaction from every device must go through the IOMMU's page tables.

This is fine for most devices, but it catastrophically breaks GPU P2P DMA. When GPU A wants to directly read from or write to GPU B's memory (BAR space), it issues a PCIe transaction targeting the peer GPU's BAR address. Under full IOMMU translation, this transaction must be mapped through the IOMMU. If the mapping doesn't exist — and it often doesn't, because the nvidia driver's DmaRemapPeerMmio=1 parameter produces only partial, directional mappings — the IOMMU raises an IO_PAGE_FAULT and the transfer silently fails or corrupts data.

The assistant had already discovered ([msg 6332]–[msg 6333]) that DmaRemapPeerMmio=1 was partially working: some GPU pairs could transfer data correctly while others produced IO_PAGE_FAULTs. The pattern was directional — transfers from lower-numbered GPUs to higher-numbered ones failed, while the reverse succeeded. This pointed to an incomplete IOMMU mapping implementation in the nvidia driver.

The Discovery: Per-Group IOMMU Identity Domains

Earlier in the session ([msg 6323]), the assistant had discovered a powerful Linux kernel feature: the ability to change the IOMMU domain type for individual IOMMU groups at runtime via /sys/kernel/iommu_groups/&lt;group&gt;/type. By writing &#34;identity&#34; to this file, the IOMMU translation for that group's devices could be bypassed, allowing direct physical DMA — exactly what GPU P2P needs.

The initial attempts to use this feature hit a wall. The assistant tried unbinding the nvidia driver, setting identity, and rebinding — but the Blackwell GPU's Firmware Security Processor (FSP) failed with error code 0x177 when the driver tried to reinitialize in identity mode. The FSP apparently requires specific DMA mappings set up by the kernel's DMA API during its boot sequence, and identity mode doesn't provide them.

This led to a critical realization: the IOMMU identity domain must be set before the nvidia driver ever touches the GPU — at boot time, before driver probing. This is the motivation for the systemd service.

Design Decisions in the Systemd Unit

The service file reveals careful reasoning about boot ordering:

After=systemd-modules-load.service: This ensures the PCI subsystem has enumerated all devices and IOMMU groups exist before the script runs. Without this, the script would find no PCI devices and silently skip everything.

Before=nvidia-persistenced.service: This is the critical ordering constraint. nvidia-persistenced is the service that initializes the nvidia driver and GPU firmware. By placing the identity-setting script before it, the assistant ensures the IOMMU groups are in identity mode before the Blackwell FSP boots for the first time.

Before=gpu-vfio-split.service: This references a custom service from earlier in the session that handles splitting GPUs between nvidia and VFIO drivers. The identity script must run before this split happens, because the VFIO-bound GPUs (NUMA1) should remain in DMA-FQ mode for SEV-SNP.

DefaultDependencies=no: This is a subtle but important choice. By disabling default dependencies, the service avoids pulling in sysinit.target or other heavy dependencies that might delay its execution or create circular dependencies with the nvidia stack.

Type=oneshot with RemainAfterExit=yes: The script runs once at boot and exits, but RemainAfterExit marks the service as "active" so that subsequent services can depend on it with After= ordering.

The Shell Script

The companion script created in [msg 6335] (/usr/local/bin/gpu-iommu-identity.sh) iterates over four NUMA0 GPUs (PCI addresses 01:00.0, 11:00.0, 61:00.0, 71:00.0), unbinds any bound driver, resolves the IOMMU group number, reads the current type, writes &#34;identity&#34;, and verifies the change. It gracefully handles missing devices, already-identity groups, and devices without IOMMU groups.

The script explicitly documents the split: NUMA0 GPUs get identity (for P2P), while NUMA1 GPUs remain in DMA-FQ (for VFIO/SEV-SNP). This selective approach preserves security for the VM while enabling performance for the inference server.

Assumptions Made

Several assumptions underpin this approach:

  1. Timing is sufficient: The assumption that After=systemd-modules-load.service runs early enough — before any GPU initialization — is critical. If the nvidia module loads earlier (e.g., via initramfs or built-in kernel module), the service would be too late.
  2. Blackwell FSP can initialize in identity mode: The assistant assumed that the FSP boot failure (error 0x177) was caused by the transition from translation to identity mode on an already-initialized GPU, not by identity mode itself. The boot-time approach was designed to avoid this transition entirely.
  3. Identity mode is transparent to the GPU: The assumption that the GPU would function identically under identity mode vs. DMA-FQ mode, aside from P2P behavior. This turned out to be incorrect.
  4. The IOMMU group type change is atomic and complete: The script writes &#34;identity&#34; and immediately reads back the result, assuming the kernel has fully transitioned the group.
  5. No other service interferes: The DefaultDependencies=no and explicit ordering assume no other boot service will probe the GPUs or touch the IOMMU groups before this script runs.

The Tragic Outcome

As documented in the segment summary, this approach ultimately failed. After the reboot, the Blackwell FSP boot sequence failed with error code 0x177 even with identity mode set before the nvidia driver loaded. The FSP fundamentally requires DMA translation mode — it needs specific DMA mappings set up by the kernel's DMA API during its initialization, and identity mode bypasses that entire mechanism.

This is a hardware/firmware limitation of the Blackwell architecture itself. No amount of software timing or ordering can work around it: the Blackwell FSP requires IOMMU translation to boot, period. The assistant was forced to revert the change and return to the working DMA-FQ configuration with NCCL_P2P_DISABLE=1.

Knowledge Created

Despite the failure, this message created valuable knowledge:

Conclusion

Message [msg 6336] represents a moment of elegant systems engineering — a carefully crafted boot-time workaround for a deep hardware-software impedance mismatch. The systemd unit design shows mature understanding of Linux boot ordering, IOMMU architecture, and the nvidia driver stack. Yet it also illustrates a fundamental truth about systems programming: when the hardware has a hard requirement, no amount of software cleverness can work around it. The Blackwell FSP's need for DMA translation is not a bug to be patched around but a physical constraint of the silicon itself. Sometimes the most valuable outcome of a failed experiment is the knowledge of where the boundaries truly lie.