Key Takeaways
- Today the GPU never touches the VM’s private memory. In an Intel TDX guest, the NVIDIA driver and the GPU exchange encrypted data through bounce buffers in shared memory, and you check the GPU with an NVIDIA attestation that is separate from the TDX quote.
- TDISP changes the data path and the device check. Under this PCI-SIG protocol, and Intel’s implementation of it, TDX Connect, the VM checks a device’s identity and locked configuration, accepts it, and the device then reads and writes private memory directly, over an IDE-encrypted PCIe link.
- It is not what our VMs run. On 27 October 2026, NVIDIA ties the TDISP path to Blackwell and its confidential VM documentation lists no TDISP mode; Linux has host-side TDISP code since 6.19. Our Confidential VMs use the model without TDISP, and the evidence files are linked below.
A confidential GPU today works around the PCIe bus, not through it. The GPU is not allowed to read the confidential VM’s private memory, so the driver encrypts data and hands it over through buffers that the host can also see. PCIe TDISP, the TEE Device Interface Security Protocol, is designed to let a device that the VM has checked read and write that private memory directly, over an encrypted link. Intel’s implementation is called TDX Connect.
This article explains both models from public documents only: PCI-SIG’s summaries of its specifications, Intel’s TDX Connect specifications, NVIDIA’s documentation and the Linux kernel, each linked where it is used and read on 27 October 2026. The last sections say where our own Confidential VMs stand, with the evidence files we publish.
How a confidential GPU works today, without TDISP
Intel’s TDX Connect architecture specification describes the starting point. A trust domain (TD), Intel’s confidential VM, has private memory, encrypted with keys of its own, and shared memory that host software and devices can reach. “By default, all PCIe devices are considered untrusted and are therefore not permitted to access TD private memory directly,” so device I/O goes through shared buffers, and the TD copies and encrypts data between the two kinds of memory. Intel calls this bounce buffering and notes that it “introduces overhead and complexity,” especially for “accelerators that require direct access to plaintext data, such as GPUs or Smart-NICs.”
NVIDIA’s confidential computing mode works inside that limit. The NVIDIA driver, running in the TD, and the GPU move data “through an encrypted bounce buffer, which is allocated in shared system memory and accessible to the GPU,” and command buffers and CUDA kernels are “encrypted and signed before crossing the PCIe bus” (NVIDIA, August 2023). NVIDIA’s white paper (version 1.3, August 2025) describes 256-bit AES-GCM on every path into and out of the GPU, an initialization vector that changes with each message so that a replayed one fails, and keys replaced before the counter runs out. The bounce buffer “contains only encrypted data.”
The proof is split in two. The CPU side is a TDX quote, signed through Intel’s certificate chain. The GPU side is an NVIDIA attestation: the GPU signs its measurements, and a verifier, such as NVIDIA’s Remote Attestation Service (NRAS), compares them with NVIDIA’s reference values. NVIDIA’s threat model states that neither covers the other: “A successful GPU attestation does not validate the CPU TEE or the tenant’s workload. Likewise, CPU evidence alone does not establish the state of the attached GPUs.” The tenant checks both and has to tie them together.
Eight GPUs and NVLink
For eight-GPU Hopper systems NVIDIA has a separate mode, Protected PCIe, “exclusively supported in eight-GPU four-NVSWITCH HGX Hopper air-cooled systems.” All eight GPUs go to one VM; traffic between the CPU and the GPUs still goes through encrypted bounce buffers, “while data traffic between GPUs over NVLINK remains unencrypted” (white paper). The threat model adds that the assessment “must also account for protection of the fabric, including NVSwitch and physical access.” For Blackwell, NVIDIA lists a multi-GPU confidential computing mode in which NVLink traffic is encrypted.
What PCIe TDISP is
TDISP is a PCI-SIG engineering change notice (ECN) dated 11 August 2022, written against the PCIe Base Specification 5.0 and 6.0 and the IDE ECN. Its text is on PCI-SIG’s member site; the public summary calls it “an architecture for trusted I/O virtualization” with three functions: establishing a trust relationship between a confidential VM and a device, securing the interconnect between the host and the device, and attaching and detaching a device interface to the VM “in a trusted manner.” It builds on CMA/SPDM, the protocol a device uses to authenticate itself and report its measurements (SPDM is a DMTF standard), and on IDE.
IDE, Integrity and Data Encryption, is the earlier ECN (2 December 2020) that encrypts PCIe traffic. In PCI-SIG’s summary, it “provides confidentiality, integrity, and replay protection” for PCIe transaction layer packets, its security model “considers threats from physical attacks on Links,” lab equipment and purpose-built interposers included, and its final version supports only 256-bit keys for AES-GCM. A follow-up ECN, TDISP eXtended TEE (XT) Extensions, dated 22 April 2025, amends the IDE, ATS and TDISP sections of PCIe Base 6.3.
Four roles, four states
Intel’s specification summarizes the four parties that TDISP defines:
- TVM, the TEE virtual machine: the confidential VM. In TDX Connect, a TD.
- TDI, the TEE device interface: the part of a device that is assigned, such as a function.
- TSM, the TEE security manager: the host-side authority that protects the VM’s isolation. In TDX Connect, the TDX module, with extensions of the CPU’s root complex.
- DSM, the device security manager: the logic in the device that runs its side of the protocol.
A device interface goes through four states. In CONFIG_UNLOCKED the host configures it, and memory requests from the VM are rejected. In CONFIG_LOCKED its configuration is frozen, and any change sends it to ERROR. In RUN the VM has accepted it and it works. In ERROR it must not expose the VM’s data. The TSM drives these states with TDISP messages (LOCK_INTERFACE_REQUEST, GET_DEVICE_INTERFACE_REPORT, START_INTERFACE_REQUEST, STOP_INTERFACE_REQUEST) carried in an SPDM session encrypted with AES-256-GCM; the host only delivers them to the device.
The VM decides
For a tenant, the step that matters is acceptance. A device is not part of the VM’s trusted computing base unless the VM “explicitly accepts and verifies” it: the VM checks the device’s identity from its SPDM certificates and measurements, and its locked configuration from the TDISP report. Then the TSM enables trusted DMA and MMIO, and the device moves to RUN. From then on its DMA requests travel in an IDE stream marked as TEE requests (the T bit), and in TDX Connect only those requests can reach the TD’s private memory (Intel, section 2.2).
Acceptance widens what you trust. Intel’s TEE-IO device guide, citing the TDISP specification: “Once the TVM accepts a TDI, the TVM extends its TEE TCB to the entire TEE-IO device DSM, even if only one TDI from the device is accepted by the TVM.” And, as with TDX itself: “There is no requirement for the protection of TVMs against denial-of-service attacks.”
What Intel TDX Connect adds
Intel’s TDX documentation page puts it in one line: “Intel TDX version 2.0 extends Intel TDX to support Trusted Execution Environment for device I/O (TEE-IO).” In TDX Connect the TDX module plays the TSM: it opens the SPDM session with the device and manages the IDE keys. The CPU’s root complex gains IDE and a second set of IOMMU translation tables for trusted DMA, whose access rules only the TDX module can set, while the host keeps managing ordinary DMA. TDX Connect uses Selective IDE, the end-to-end form of IDE, so that PCIe switches stay outside the trust boundary.
The life cycle in the specification, shortened:
- Connect. The host asks the TDX module to open the SPDM session with the device (TDH.SPDM.CONNECT), then to set up the IDE stream and program its keys at both ends (TDH.IDE.STREAM.KM).
- Bind. The host binds the device interface to the TD (TDH.TDI.BIND). The call returns the TDISP report, which the host hands to the TD with the device’s SPDM attestation.
- Validate. The TD checks the attestation and the report through the TDX module (TDG.TDI.VALIDATE).
- Accept. If the TD accepts the device into its trusted computing base, it enables the private MMIO and DMA mappings.
- Start. The TD asks for the RUN state (TDG.TDI.START), and the host relays the request (TDH.TDI.START), which sends START_INTERFACE_REQUEST to the device.
The host keeps the last word on availability. In Intel’s words, “the host VMM is in full control and can unbind any TDI from a TD and disconnect TDISP device.”
Where Intel’s documents stand: the architecture specification (354629-003US) is dated June 2025 and the TEE-IO device guide May 2025. The TDX Connect ABI reference specification, listed for community review in September 2026, is version 2.1 v0.66 and marked “Work in progress.” A host learns whether its TDX module supports TDX Connect from bit 6 of the TDX_FEATURES field.
What changes for a confidential GPU
| Today, without TDISP | With TDISP and TDX Connect | |
|---|---|---|
| Where the GPU reads and writes | Shared memory (bounce buffers) | The TD’s private memory |
| Who encrypts | The NVIDIA driver and the GPU, transfer by transfer | PCIe IDE, on the link |
| Copies | Into and out of the shared buffers | None for that data |
| How the GPU is checked | NVIDIA attestation, separate from the TDX quote | SPDM evidence and TDISP report, checked by the TD before it accepts the device |
| What joins the trusted computing base | The GPU, in CC mode | The whole device, once accepted |
| PCIe switches | Carry ciphertext | Must pass IDE through; outside the trust boundary |
| NVLink between GPUs | Unencrypted in Hopper Protected PCIe; encrypted in Blackwell multi-GPU CC | Not covered by TDISP, a PCIe protocol |
| Host can stop the VM or detach the GPU | Yes | Yes |
NVIDIA expects the inline path to be faster, since it “eliminates the need for the shared memory space and copying of data into it and from it” (white paper). For the bounce-buffer path on Hopper, NVIDIA’s 2023 figure was a CPU-to-GPU bandwidth “limited by CPU encryption performance” at “roughly 4 GBytes/sec,” with GPU compute and memory bandwidth unchanged. We have not measured either path on our VMs.
Nothing in the documents we read changes the rest of the picture. In NVIDIA’s threat model for Hopper and Blackwell, GPU memory is protected by access controls, not by encryption, and invasive probing of the GPU package and fault injection are out of scope; CPU side channels follow Intel’s model; and the host still controls availability.
Where support stands on 27 October 2026
NVIDIA. The Blackwell architecture page describes Blackwell as a “TEE-I/O capable GPU” with “inline protection over NVIDIA NVLink.” The white paper presents TDISP/IDE as an alternative to bounce buffers in the single-GPU and Blackwell multi-GPU modes, “when coupled with a compatible CPU, Blackwell GPU, and supported firmware and driver releases,” and calls inline encryption with “Blackwell B100/B200 GPUs and TDISP/IDE-compatible CPUs” a future option. For Hopper GPUs, such as H100 and H200, it describes bounce buffers only. NVIDIA’s confidential VM documentation, as we read it on 27 October 2026, covers three GPU modes: CC with one GPU (Hopper and Blackwell), CC with several GPUs (Blackwell) and Protected PCIe with several GPUs (Hopper). Its supported platforms list no TDISP mode.
Linux. The host side of TDISP arrived in Linux 6.19, tagged on 8 February 2026, as a PCI “TSM” core (drivers/pci/tsm.c). You can check when the file appeared, and read the help text of its build option:
for t in v6.18 v6.19; do printf '%s drivers/pci/tsm.c: HTTP ' "$t"; curl -s -o /dev/null -w '%{http_code}\n' "https://raw.githubusercontent.com/torvalds/linux/$t/drivers/pci/tsm.c"; done
curl -s https://raw.githubusercontent.com/torvalds/linux/v6.19/drivers/pci/Kconfig | sed -n '/^config PCI_TSM/,/Enable a platform TSM driver/p'v6.18 drivers/pci/tsm.c: HTTP 404 v6.19 drivers/pci/tsm.c: HTTP 200 config PCI_TSM bool "PCI TSM: Device security protocol support" select PCI_IDE select PCI_DOE select TSM help The TEE (Trusted Execution Environment) Device Interface Security Protocol (TDISP) defines a "TSM" as a platform agent that manages device authentication, link encryption, link integrity protection, and assignment of PCI device functions (virtual or physical) to confidential computing VMs that can access (DMA) guest private memory. Enable a platform TSM driver to use this capability.
The sysfs documentation lists what the host can do with a device: tsm/connect sets up “an SPDM (DMTF Security Protocols and Data Models) session over PCIe DOE (Data Object Exchange)” and “may also include PCIe IDE (Integrity and Data Encryption) establishment”; tsm/bound names the TSM when the device is in a TDISP operational state (“LOCKED, RUN, or ERROR”), after a bind started by VFIO/IOMMUFD. The kernel’s TSM interface also passes a confidential VM’s TDISP state-change requests to the TSM. In the mainline tree we read on 27 October 2026 (commit d135ab453a74), the one platform driver we found that implements this interface is AMD’s, described in its source as the “Interface to CCP/SEV-TIO for generic PCIe TDISP module.” We found no Intel TDX Connect driver there, and the kernel’s list of TDX module features (asm/tdx.h) had no TDX Connect bit.
PCI-SIG and Intel. The dates are above: the TDISP ECN in 2022, its XT extensions in 2025, the TDX Connect architecture in June 2025 and an ABI specification still marked work in progress.
Where our Confidential VMs stand
All our Confidential VM tiers run the model without TDISP described in the first section: the GPU is passed through to an Intel TDX guest, data reach it through encrypted bounce buffers, and you generate two separate proofs, a TDX quote and an NVIDIA attestation, which our open-source verifier ties to one challenge of yours. What we have published, tier by tier:
RTX PRO 6000 Blackwell, one GPU (9 October 2026)
The only Blackwell GPU we rent in a Confidential VM. Its guest read this (conf-compute.txt):
==============NVSMI CONF-COMPUTE LOG==============
CC State : ON
Multi-GPU Mode : None
CPU CC Capabilities : INTEL TDX
GPU CC Capabilities : CC Capable
CC GPUs Ready State : Ready
GPU 0: NVIDIA RTX PRO 6000 Blackwell Server Edition (UUID: GPU-bfc8c5a7-1b18-5fe4-b326-aaaa928b330a)
Protected memory size: 99463296 KiB
Unprotected memory size: 0 KiBand printed its kernel version, the TDX guest device and the virtualization type (kernel.txt):
6.8.0-110-generic crw------- 1 root root 10, 262 Oct 9 21:53 /dev/tdx_guest kvm
CC State ON with Multi-GPU Mode None is NVIDIA’s single-GPU CC mode, which NVIDIA describes with bounce buffers and, on Blackwell, TDISP as an alternative. The guest kernel, 6.8.0-110-generic, is older than Linux 6.19, the first release with the TDISP code above. The same bundle holds a TDX quote and two NRAS tokens bound to one manifest, verified offline in verify.txt; we ran that check again on 27 October 2026 in How Confidential Computing Works on a GPU.
H100 and H200, one GPU
Hopper GPUs, so bounce buffers in NVIDIA’s description. The H200 VM was attested on 4 September 2026: a TDX quote and an NRAS token, from two separate rounds with different nonces (README). The H100 VM was attested on 16 September 2026; we have not published its files.
8x H100 node, Protected PCIe (10 September 2026)
The guest of an h100-xlarge VM read this (node-state.txt, excerpt):
==============NVSMI CONF-COMPUTE LOG==============
CC State : OFF
Multi-GPU Mode : Protected PCIe
CPU CC Capabilities : INTEL TDX
GPU CC Capabilities : CC Capable
CC GPUs Ready State : ReadyCC State OFF is how Protected PCIe mode reports; the Multi-GPU Mode line is the one to read. NVIDIA’s attestation service returned a successful result for all eight GPUs, from evidence generated inside the VM on the tenant’s nonce (README). The NVSwitch fabric is not verified: our runs of 19 September 2026 got past the NSCQ session and failed at certificate validation, during the online revocation check (README, and our NVSwitch article). In this mode, by NVIDIA’s description, NVLink traffic between the GPUs is not encrypted. The 8x H200 node reads the same mode; its attestation has not been run.
What TDISP would change for you
No bounce buffers, and a device check that is part of assigning the device instead of a second proof that you bind yourself. None of our published evidence contains a TDISP report or a device certificate checked by the guest. We will only claim TDISP for a tier once a published evidence file shows it.
What this article shows, and what it does not
Shown:
- What PCI-SIG, Intel, NVIDIA and the Linux kernel publish about TDISP and TDX Connect, as read on 27 October 2026, with a link for each claim.
- That the PCI TSM code of Linux first appears in 6.19 (the command above, run on 27 October 2026).
- What our published files show about the GPU mode, the guest kernel and the attestations of our Confidential VMs.
Not shown:
- That TDISP or TDX Connect works on any machine. We have run neither; everything about them here comes from the vendors’ documents.
- Any performance figure. The 4 GB/s figure is NVIDIA’s, from 2023, on Hopper. We have no measurement of either path.
- How NVIDIA’s attestation fits the TDISP flow on Blackwell. The documents we read do not describe it.
- Dates. None of the documents gives a date for general availability, and we give none.
- The NVSwitch fabric of our 8-GPU nodes, which is not verified.
- That the vendors’ documents are final. The TDX Connect ABI specification is a work in progress, and NVIDIA’s confidential VM documentation is the version marked Dev.
Sources
- PCI-SIG, public summaries of the ECNs: TEE Device Interface Security Protocol (TDISP), 11 August 2022; Integrity and Data Encryption (IDE), 2 December 2020; TDISP eXtended TEE (XT) Extensions, 22 April 2025.
- Intel: TDX Connect Architecture Specification, 354629-003US, June 2025; TDX Connect TEE-IO Device Guide, May 2025; TDX Connect ABI Reference Specification 2.1 v0.66; TDX documentation page.
- NVIDIA: NVIDIA Secure AI with Blackwell and Hopper GPUs, WP-12554-001 v1.3, August 2025; Confidential VMs, Trust and Threat Model; Supported Platforms; Confidential Computing on NVIDIA H100 GPUs, August 2023; Blackwell architecture.
- Linux: drivers/pci/tsm.c (v6.19), PCI TSM documentation, sysfs-bus-pci ABI, drivers/crypto/ccp/sev-dev-tsm.c, asm/tdx.h.