The ACS Paradox: Why Disabling PCIe Access Control Services Might (or Might Not) Enable GPU Peer-to-Peer DMA in a Proxmox VM

In the high-stakes world of multi-GPU inference serving, every microsecond of cross-GPU communication latency matters. When deploying a 200+ billion parameter model like GLM-5-NVFP4 across 8 NVIDIA RTX PRO 6000 Blackwell GPUs, the difference between a 5-microsecond and a 13-microsecond all-reduce hop can translate into seconds of additional latency per inference request. This is the story of one message in an opencode coding session—message 408—where the assistant confronts a fundamental question about PCIe Access Control Services (ACS) and whether disabling it can unlock peer-to-peer DMA in a virtualized environment.

The message arrives at a critical inflection point in a much longer debugging journey. The team has been attempting to deploy GLM-5-NVFP4 on 8 RTX PRO 6000 GPUs housed in a Proxmox virtual machine on an ASUS ESC8000A-E13 server with dual AMD EPYC processors. After resolving numerous infrastructure challenges—installing NVIDIA drivers, fixing BAR allocation failures after migrating from the legacy i440FX chipset to Q35, setting up NUMA affinity, and crafting custom NCCL topology XML files—they have hit a wall: cross-GPU communication latency is stuck at approximately 13 microseconds, roughly double what bare-metal performance would be. The root cause is that nvidia-smi topo -p2p reports NS (Not Supported) for all GPU pairs, meaning the NVIDIA driver cannot establish direct peer-to-peer DMA transfers between GPUs. Every cross-GPU memory copy must be staged through host memory via the IOMMU, incurring the latency penalty.

The user, frustrated by this limitation and savvy enough to suspect the security-oriented PCIe feature, asks directly: "pcie acs - wouldn't disabling permit p2p? or is it more hw level thing? I always want an 8 gpu vm and if not don't really care about security - I use vms for grouping, snapshots, etc. no untrusted tenants." This is a sharp question that cuts to the heart of the matter. ACS (Access Control Services) is a PCIe capability that controls whether peer-to-peer transactions are forwarded between downstream devices or redirected upward to the root complex. In VFIO-based virtualization, ACS is the mechanism that enables the IOMMU to place devices into separate, isolated groups—precisely the isolation that blocks P2P DMA between GPUs assigned to different IOMMU groups.

The Anatomy of ACS and Its Role in Blocking P2P

The assistant's response in message 408 begins by acknowledging the user's intuition and then systematically unpacks the relationship between ACS, IOMMU groups, and P2P DMA. The explanation is structured as a layered argument, each layer building on the previous one to reveal an increasingly nuanced picture.

First, the assistant explains the basic mechanism: ACS is a PCIe capability implemented on bridges and root ports. When ACS is enabled, a PCIe bridge or root port will not forward peer-to-peer Transaction Layer Packets (TLPs) between its downstream devices. Instead, those packets are redirected upward to the root complex, where the IOMMU can intercept and mediate them. VFIO relies on ACS enforcement to create separate IOMMU groups—each group represents a set of devices that can DMA to each other without IOMMU intervention. Devices in different groups must have their DMA traffic mediated by the hypervisor, which is precisely what creates the ~13 microsecond latency floor.

When ACS is disabled, the assistant explains, PCIe bridges can forward P2P transactions directly between downstream devices. Devices that share a bridge or root complex consequently merge into the same IOMMU group. Since they share an IOMMU group, VFIO treats them as a single protected domain, and the IOMMU does not need to trap and redirect their mutual DMA traffic. This is the key insight: the NVIDIA driver, upon detecting that GPUs share an IOMMU group, can recognize P2P as supported and enable direct GPU-to-GPU transfers.

This explanation demonstrates a deep understanding of the VFIO internals. The assistant correctly identifies that the bottleneck is not PCIe switching per se but IOMMU grouping. This is a subtle but crucial distinction that many practitioners miss. The common intuition is that ACS controls P2P at the PCIe electrical level—that disabling ACS somehow "loosens" the PCIe protocol to allow direct device-to-device transfers. In reality, ACS controls routing policy at the bridge level, and the P2P block in a VM is an artifact of how VFIO uses ACS-enforced IOMMU groups to create security domains. The assistant's explanation reframes the problem from a hardware limitation to a virtualization policy decision, which opens up the possibility of a software-configurable fix.

The Hardware Topology Reality Check

But then comes the twist. After laying out the promising theory, the assistant performs a reality check grounded in the specific hardware topology of the ASUS ESC8000A-E13 motherboard. This is where the message reveals its most sophisticated analytical move.

The assistant constructs a detailed ASCII diagram showing the physical PCIe topology:

CPU Socket 0                          CPU Socket 1
┌─────────────────────┐              ┌─────────────────────┐
│  Root Complex 00    │              │  Root Complex 80    │
│    └── GPU 01:00.0  │              │    └── GPU 81:00.0  │
│  Root Complex 10    │  Infinity    │  Root Complex 90    │
│    └── GPU 11:00.0  │  Fabric     │    └── GPU 91:00.0  │
│  Root Complex 50    │ ←────────→  │  Root Complex d0    │
│    └── GPU 61:00.0  │  (xGMI)     │    └── GPU e1:00.0  │
│  Root Complex 70    │              │  Root Complex f0    │
│    └── GPU 71:00.0  │              │    └── GPU f1:00.0  │
└─────────────────────┘              └─────────────────────┘

Each GPU is on its own dedicated PCIe root complex. There is no shared PCIe switch or bridge between any pair of GPUs. This is a deliberate design choice by ASUS: by giving each GPU its own root complex (directly wired to the CPU's PCIe lanes), the motherboard maximizes per-GPU bandwidth. Every GPU gets a full Gen5 x16 link directly to the CPU, with no intermediate switch to create contention.

This topology creates a paradox for ACS-based P2P enablement. ACS only controls forwarding on bridges and switches—it has nothing to do when there is no shared bridge between two devices. If GPU 0 and GPU 1 are on different root complexes, there is no PCIe bridge between them where ACS could be enabling or blocking P2P. The P2P path between any two GPUs must always traverse the CPU's internal fabric (Infinity Fabric on AMD EPYC), not a shared PCIe hierarchy.

On bare metal, AMD EPYC supports P2P between devices on different root complexes via the Data Fabric. The CPU's root complex can route PCIe TLPs between its internal PCIe bridges, and the Data Fabric provides the interconnect. This is why bare-metal systems show NODE topology in nvidia-smi topo -m—GPUs on the same socket but different root complexes communicate through the Data Fabric at relatively low latency.

In the VM, however, the situation is fundamentally different. VFIO intercepts all DMA. When GPU 0 issues a PCIe write to GPU 1's physical BAR address, the host IOMMU traps the transaction because it targets a different IOMMU group. VFIO and KVM must mediate the transfer through host memory, and this mediation is what creates the ~13 microsecond latency floor. The Data Fabric's native P2P capability is invisible to the guest because the hypervisor interposes itself on every cross-device memory access.

The IOMMU Group Insight

The assistant then synthesizes these two threads—the ACS theory and the topology reality—into a coherent recommendation. The key insight is that ACS disablement would still help, but through a different mechanism than the obvious one.

If ACS is disabled in the BIOS, the GPUs within each socket would merge into fewer IOMMU groups. On the AMD EPYC platform, each root complex is a separate PCIe domain, but ACS controls whether the root complex itself enforces isolation between its downstream ports. With ACS disabled, the root complex may group multiple downstream devices into a single IOMMU group. In the best case, all four GPUs on a socket might merge into one IOMMU group per socket, or even one giant group for all eight GPUs.

When multiple GPUs share an IOMMU group, VFIO passes them as a unit. The IOMMU maps them into the same address space, and GPU-to-GPU DMA within the same IOMMU group can bypass IOMMU translation because the devices share the same memory mapping. The NVIDIA driver, upon detecting that GPUs share an IOMMU group, would then recognize P2P as supported and enable direct DMA transfers.

This is a crucial distinction that the assistant makes explicit: "it's not about PCIe switching, it's about IOMMU grouping." The ACS disablement does not magically create a PCIe switch between GPUs that doesn't exist. Instead, it changes the IOMMU group assignment, which changes how VFIO treats the GPUs. If the GPUs end up in the same IOMMU group, VFIO stops interposing on their mutual DMA, and the NVIDIA driver can enable P2P.

The Predicted Performance Improvement

The assistant then quantifies the expected improvement with a specific prediction:

Assumptions and Potential Pitfalls

The assistant's recommendation rests on several assumptions that deserve scrutiny. First, it assumes that disabling ACS in the BIOS will actually cause the GPUs on each socket to merge into fewer IOMMU groups. This depends on the specific AMD EPYC I/O die implementation and how the BIOS configures the root complexes. Some EPYC platforms may keep GPUs in separate IOMMU groups even with ACS disabled, because the root complexes themselves are physically separate PCIe domains that cannot be merged regardless of ACS settings.

Second, the assistant assumes that the NVIDIA driver will detect the merged IOMMU groups and enable P2P. While this is the expected behavior—the NVIDIA driver queries the IOMMU group assignment through the VFIO interface—there may be additional checks that prevent P2P in virtualized environments. For example, the driver might check whether the GPUs are in a VM by reading the hypervisor CPUID leaf or checking for KVM signatures, and disable P2P as a safety measure.

Third, the assistant assumes that the user has BIOS access and can navigate the ASUS BIOS menus to find the ACS setting. The BIOS path given—AMD CBS / NBIO common options → ACS → Disabled—is plausible for an ASUS ESC8000A-E13, but BIOS menus vary between firmware versions and may have different names or nesting.

Fourth, the assistant assumes that the host reboot required to change the BIOS setting will not cause other issues. Given that the VM was temporarily unreachable at the time of the message (the assistant noted "VM seems temporarily unreachable (maybe a reboot is happening)"), the infrastructure is already in a fragile state, and a host BIOS change adds further risk.

The Broader Context: A Journey Through Virtualization Overhead

To fully appreciate message 408, it is essential to understand where it fits in the larger narrative. The conversation leading up to this message spans hundreds of exchanges across multiple segments. The team has been battling virtualization overhead for days, systematically working through layers of the stack:

  1. GPU discovery and driver installation: Getting 8 RTX PRO 6000 GPUs recognized in Ubuntu 24.04 with NVIDIA drivers and CUDA Toolkit 13.1.
  2. Flash-attn build issues: Resolving memory exhaustion during compilation by reducing parallel jobs from 128 to 20, and rebuilding against the correct PyTorch version after vLLM downgraded it.
  3. NaN decode crashes: Debugging persistent NaN values during model inference, eventually resolved by switching to working attention backends (trtllm NSA).
  4. PCIe topology and chipset migration: Moving the VM from the legacy i440FX chipset to Q35 with proper PCIe passthrough, fixing BAR allocation failures with pci=realloc.
  5. NUMA affinity and NCCL topology: Setting sysfs NUMA affinity for GPUs and creating custom NCCL topology XML files to tell NCCL the real GPU-to-NUMA mapping.
  6. IOMMU and ACS investigation: The current phase, where the team is probing whether BIOS-level changes can unlock P2P DMA. Message 408 represents the culmination of this investigation. The assistant has moved from "let's try software workarounds" to "the fundamental issue is IOMMU grouping, and ACS is the BIOS-level control for that." This is a natural progression: when software fixes (NCCL topo files, sysfs NUMA settings) prove insufficient, the next layer to examine is the hypervisor configuration, and when that is exhausted, the BIOS becomes the final frontier.

The Thinking Process: Visible Reasoning

The assistant's reasoning process is visible in several dimensions of the message. First, there is the structure itself: the assistant starts by validating the user's intuition, then provides the theoretical framework, then performs a reality check against the specific hardware topology, then synthesizes the two into a practical recommendation. This is classic diagnostic reasoning: generate a hypothesis, test it against known constraints, refine the hypothesis, and produce an actionable plan.

Second, the assistant demonstrates meta-cognitive awareness by acknowledging the limits of its own knowledge. The message includes a prediction about what will happen, but it is framed as a conditional: "Here's what should happen." The assistant is careful not to over-promise, listing both the expected positive outcomes and the potential limitations (cross-socket pairs may not improve).

Third, the assistant shows the ability to hold two competing models simultaneously. The ACS theory says "disabling ACS should enable P2P." The topology reality says "there's no shared PCIe switch, so ACS has nothing to control." Rather than discarding either model, the assistant finds the synthesis: ACS affects IOMMU grouping, and IOMMU grouping is what VFIO uses to decide whether to mediate DMA. The mechanism is indirect but real.

Fourth, the assistant's language reveals a sophisticated understanding of the PCIe protocol stack. Terms like "Transaction Layer Packets (TLPs)," "BAR address," "root complex," "downstream ports," and "ARI enumeration" are used precisely and correctly. This is not surface-level knowledge but deep architectural understanding.

Input Knowledge Required

To fully understand message 408, the reader needs knowledge spanning several domains:

Output Knowledge Created

Message 408 creates several pieces of valuable knowledge:

  1. The IOMMU group theory of P2P in VMs: The insight that ACS disablement helps not by enabling PCIe-level P2P but by merging IOMMU groups, which changes VFIO's mediation behavior.
  2. A specific, testable hypothesis: Disable ACS in BIOS, reboot the host, check IOMMU groups, restart the VM, and measure P2P latency. This is an actionable experiment with a clear predicted outcome.
  3. Quantified performance expectations: 5-8 microseconds for intra-socket pairs, potentially unchanged ~13 microseconds for cross-socket pairs.
  4. A documented hardware topology: The ASCII diagram of the ASUS ESC8000A-E13's PCIe layout, showing each GPU on its own root complex.
  5. A framework for reasoning about virtualization overhead: The message demonstrates a method for analyzing performance bottlenecks by tracing the data path (GPU→IOMMU→host memory→IOMMU→GPU) and identifying where virtualization adds latency.

The Unanswered Questions

Message 408 leaves several questions open. Will disabling ACS actually merge the IOMMU groups on this specific EPYC platform? Will the NVIDIA driver honor the merged groups and enable P2P? Will cross-socket performance improve at all? Are there side effects to disabling ACS—for example, will other PCIe devices (NVMe drives, network cards) also merge into the same IOMMU groups, potentially causing issues?

The assistant implicitly acknowledges these uncertainties by framing the recommendation as something to try rather than a guaranteed fix. The message ends with "Want to try this?"—an invitation to experiment rather than a declaration of victory.

Conclusion

Message 408 is a masterclass in diagnostic reasoning about complex systems. It takes a user's intuitive question about a PCIe feature and unpacks it into a multi-layered analysis spanning hardware topology, virtualization architecture, driver behavior, and communication patterns. The assistant navigates the tension between a promising theoretical fix and the constraints of physical hardware, ultimately producing a nuanced recommendation that acknowledges both the potential benefits and the limitations.

The message also illustrates a broader truth about performance debugging in modern AI infrastructure: the bottleneck is rarely where you first look. The team started with software workarounds (NCCL topo files, NUMA settings), moved to hypervisor configuration (Q35 chipset, BAR allocation), and is now probing BIOS-level PCIe settings. Each layer reveals new constraints and new opportunities. The ACS investigation is the latest chapter in this journey, and whether it succeeds or fails, it will produce knowledge that advances the team's understanding of their system.

For anyone deploying multi-GPU inference workloads in virtualized environments, message 408 offers both practical guidance and a model for systematic debugging. The specific recommendation—disable ACS in BIOS to merge IOMMU groups—is worth testing in any setup where P2P is blocked in a VM. But more importantly, the analytical framework—trace the data path, identify where virtualization adds overhead, and work backward through the layers until you find a configurable control point—is applicable to a wide range of performance problems.

The message is, in essence, a demonstration of how deep platform knowledge translates into actionable performance optimization. It is the kind of insight that separates those who can deploy and tune large-scale AI systems from those who can only follow installation guides.