AMD Releases SEV-TIO Linux Patches for EPYC Venice

AMD is accelerating efforts to bring confidential computing features for 6th-generation EPYC to the Linux kernel. On September 16, 2026, 17 new patches related to SEV-TIO and TDISP were published. The target is the new EPYC 9006 “Venice” and environments with PCI Express 6.0 and later. According to reporting by Michael Larabel of Phoronix, the aim is to strengthen upstream support.

for enabling SEV-TIO TDISP that is supported with PCI Express 6.0 and beyond

This article is based on Phoronix (All Rights Reserved) and relies on fair quotation under Article 32 of the Japanese Copyright Act. These patches provide a mechanism to protect the assignment of direct I/O devices. They handle trust establishment and communication protection when virtual machines exclusively occupy devices.

17 Patches for EPYC Venice

AMD posted 17 patches to the Linux kernel mailing list. The purpose is to enable SEV-TIO support on EPYC 9006 “Venice.” SEV-TIO stands for Secure Encrypted Virtualization Trusted I/O. It is intended to protect confidential virtual machines when they directly use PCIe devices.

The relevant specification is TDISP. Formally called TEE Device Interface Security Protocol. It is a device security procedure defined for PCI Express 6.0 and later. It includes device attestation and encryption, as well as interaction via private memory.

This submission is an initial version, published for review and discussion. The implementation focuses on trust-establishment processing on the guest side. It establishes the procedures for when devices comply with the TDISP specification. It lays the foundation for interaction using private memory.

Upstream support for EPYC is progressing in stages. Previously, enhanced SMT protection measures for SEV-SNP guests were posted. This refers to the series of work on Enhanced SMT Protection. This SEV-TIO work is part of the subsequent security enhancements.

Around the kernel, improvements continue on both performance and security. Expansion of Linux Cache Aware Scheduling, up to 360% faster MySQL also reported upstream optimizations. This work focuses not on performance but on trustworthiness and isolation. The area of use extends to both shared infrastructure and self-operated infrastructure.

Protecting Device Assignment with TDISP

The aim of TDISP is to ensure trust at device assignment time. Confidential virtual machines become more efficient when they directly control devices. On the other hand, if the device is untrusted, memory contents could leak. Therefore, the legitimacy of the device must be verified before connection.

At the core of verification are device attestation and key exchange. It cryptographically verifies whether the device is in the expected configuration. After verification, encryption of PCIe transfers is enabled. A closed path is formed between the guest and the device.

The use of private memory is also an important element. Information is exchanged with the device via a region accessible only to the guest. Observation from the host side or other guests is blocked. It is designed to improve isolation while preserving the benefits of direct assignment.

SEV-SNP has traditionally provided memory encryption and integrity protection. SEV-TIO extends that protection scope to I/O devices. It extends the chain of trust beyond the processor itself to device cooperation. It assumes both high-speed transfers and security in the PCIe 6.0 generation.

In terms of operations, device-side support is a prerequisite. TDISP-compliant controllers and accelerators are required. On the infrastructure side, updates to the kernel and virtualization layer are required. Gradual adoption is seen as the realistic path.

Common TSM Development Trends Across CPU Vendors

This work includes development of a common foundation. It is the development of a common layer called TEE Security Manager. It aims to commonize TDISP processing, PCIe encryption, and device attestation. It aims for a framework independent of specific manufacturers.

Development is proceeding in collaboration with multiple companies. Cooperation with Intel, Arm, and the RISC-V camp has been disclosed. It consolidates processing common to each company’s confidential computing implementations. It is seen as aiming to avoid duplicated development and improve the quality of verification.

The benefit of commonization lies in expanding the ecosystem. Device manufacturers need only support a single procedure. Implementations on the virtualization infrastructure and guest side are also simplified. Ensuring interoperability holds the key to widespread adoption.

On the other hand, coordination may take time. Each company’s security design and key management philosophy are not identical. Setting the boundary between the common layer and vendor-specific layers will be an issue. Review on the mailing list will determine the validity of the design.

Upstream inclusion is expected to proceed cautiously. The initial submission is at the stage where the validity of the design and split is questioned. Revised versions will be issued in response to feedback. The timing of adoption will depend on review progress.

Impact on Confidential Computing

Infrastructure and Future Challenges

Confidential computing has expanded on the premise of use on shared infrastructure. Demand in finance, healthcare, and the public sector is behind this. Direct device assignment is important for AI processing and high-speed communications. TDISP supports such use from a security perspective.

In the PCIe 6.0 and later generations, transfer speeds increase significantly. With higher speeds, opportunities for observation and tampering also increase. Standardization of encryption and attestation becomes an essential foundation. Early support in the Venice generation is a move looking ahead to market introduction.

For infrastructure operators, the challenge lies in verification and update operations. Procurement of compliant devices and configuration management will be necessary. Creation of guest images and management of key expiration will also increase. Development of automation and monitoring will determine operational load.

For developers, support in the virtualization layer will be the focus. Guest-side driver layers and device-side implementations need to be aligned. Troubleshooting procedures in case of failure will also become more complex than before. Documentation and accumulation of case studies will be required.

Remaining issues are the impact on performance and clarification of scope. Actual measurement of latency and processing load due to encryption will be necessary. It will also be necessary to decide whether it should be applied to all devices. Details of the design will become clear in future revisions.

Editorial Opinion

On short-term impact. We view this submission as the start of review. We expect the next 3-6 months to focus on revisions and verification. Along with early support for Venice, we expect evaluation by platform manufacturers and large-scale operators to proceed.

On the long-term perspective. In the PCIe 6.0 generation, we expect protection of device cooperation to become a standard requirement. Development of the common TSM is expected to lower the burden of supporting multiple manufacturers. We expect the application area of confidential computing to expand to accelerator use.

Questions from the editors. How should operators define the operational design for device attestation? How should they limit the impact on guests when keys are updated or revoked? By what metrics should the balance between performance and security be judged?

References

• “AMD Sends Out Linux Patches For Enabling SEV-TIO TDISP With PCIe 6.0”, by Michael Larabel — Phoronix, 2026-09-16T13:02:52.000Z (ARR)
• Source URL: https://www.phoronix.com/news/AMD-SEV-TIO-TDISP-Linux-Patches