Intel TDX support for libvirt driver

https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support

This spec proposes the required changes to extend nova’s libvirt driver to be able to launch Intel Trust Domain Extensions (TDX) encrypted virtual machines. TDX provides hardware-enforced isolation for virtual machines, protecting guest memory and CPU state from the hypervisor and other privileged software, similar to AMD’s SEV-SNP technology but for Intel processors.

Problem description

Intel Trust Domain Extensions (TDX) is a confidential computing technology that provides hardware-based isolation for virtual machines. Currently, OpenStack Nova supports AMD SEV and SEV-ES for confidential VMs, but lacks support for Intel’s equivalent technology. This limits users with Intel hardware from leveraging confidential computing capabilities in OpenStack.

TDX creates Trust Domains (TDs) which are hardware-isolated VMs with encrypted memory and CPU state, protected from the Virtual Machine Monitor (VMM), hypervisor, and other non-TD software. While confidential computing has growing applications in edge and IoT environments, this is particularly important for cloud environments where tenants need strong guarantees about data confidentiality and integrity from software-based attacks. OpenStack Nova primarily serves multi-tenant cloud infrastructure where the separation of responsibilities between cloud operators and tenants makes confidential computing especially valuable.

Use Cases

  • As a cloud user with sensitive workloads, I want to be able to launch VMs with confidential computing enabled to ensure my data and applications are protected from unauthorized access by the hypervisor or other tenants.

  • As a cloud operator running Intel 5th Generation Xeon Scalable Processors (Emerald Rapids) or later, I want to offer TDX-based confidential computing as a service to my tenants.

  • As a cloud user in a regulated industry, I want to use TDX to reduce the trust I need to place in the cloud provider’s software stack while still benefiting from cloud infrastructure, understanding that physical security remains the responsibility of the cloud provider.

Proposed change

This spec proposes extending the existing memory encryption support in Nova’s libvirt driver to support Intel TDX, building on the existing SEV/SEV-ES implementation. It leverages the generalization introduced by generalize-sev-code blueprint and the functionality of libvirt-firmware-auto-selection.

The required changes for other confidential computing implementations, like AMD SEV-SNP and ARM CCA, will likely be similar to these since they share similarities with Intel TDX.

  1. Detection of TDX host capabilities:

Extend the libvirt driver to detect support for Intel TDX on the host through libvirt host and dom capabilities, as well as kernel kvm parameters. This is very similar to current capabilities checks for AMD SEV/SEV-ES.

  • Libvirt dom capabilities:

<domainCapabilities>
  ...
  <features>
    ...
    <tdx supported='yes'/>
  </features>
</domainCapabilities>

  • kvm_intel parameter (should be set to Y): /sys/module/kvm_intel/parameters/tdx

TDX requires libvirt.cpu_mode to be host-passthrough. This will be checked along with the above and disable TDX if it is not configured, logged accordingly.

  1. Add TDX to Intel OS traits:

Introduce HW_CPU_X86_INTEL_TDX trait to the os-traits library for scheduling TDX-capable instances to appropriate hosts, following the pattern of existing HW_CPU_X86_AMD_SEV and HW_CPU_X86_AMD_SEV_ES traits.

  1. Resource tracking:

Intel TDX needs a hardware key (TDX key) per TDX enabled VM. The maximum number is configured in BIOS and dependent on hardware. To track this, a new child resource provider for TDX is introduced. This will be parallel to the existing SEV and SEV-ES ones but will be called TDX RP with traits:HW_CPU_X86_INTEL_TDX and resources:MEM_ENCRYPTION_CONTEXT.

+------------+     +--------------------------------+
| compute RP +--+--+ SEV RP                         |
+------------+  |  | trait:HW_CPU_X86_AMD_SEV       |
                |  +----------------------------+---+
                |  | MEM_ENCRYPTION_CONTEXT     | N |
                |  +----------------------------+---+
                |
                |  +--------------------------------+
                +--+ TDX RP                         |
                   | trait:HW_CPU_X86_INTEL_TDX     |
                   +----------------------------+---+
                   | MEM_ENCRYPTION_CONTEXT     | N |
                   +----------------------------+---+

For AMD SEV the maximum number of possible guests is extracted from Libvirt dom capabilities. TDX does not have an entry there and instead utilizes the misc cgroup controller in the kernel. This can be read directly and without elevated privileges.

  • /sys/fs/cgroup/misc.capacity — the total number of TDX KeyIDs (Trust Domain keys) available on the host, set at boot time from the TDX module and BIOS configuration. Example content:

    tdx 63

The total in the resource provider then corresponds to misc.capacity. It excludes the key used by TDX module and thus that number directly corresponds to the maximum number of TDX enabled VMs.

  1. Image and flavor:

Use the existing hw:mem_encryption=True flavor extra spec and hw_mem_encryption=true image property, and introduce hw:mem_encryption_model=intel-tdx to specify TDX encryption, following the pattern used for SEV (amd-sev, amd-sev-es).

Internally these properties will be translated into resources:MEM_ENCRYPTION_CONTEXT=1 and trait:HW_CPU_X86_INTEL_TDX=required. Conflicting requests between flavor and image will be rejected.

The current implementation defaults to trait:HW_CPU_X86_AMD_SEV=required if no hw:mem_encryption_model is configured but hw:mem_encryption=True is. This could potentially be a problem if only Intel TDX is the supported memory encryption technology in the deployment (and thus no AMD SEV). The simple solution is to document that hw:mem_encryption_model needs to be set to use Intel TDX. This spec will not change anything regarding the default logic.

  1. XML generation:

Extend the libvirt driver to support the generation of the launch security object needed for TDX (LibvirtConfigGuestTDXLaunchSecurity). This is similar to SEV/SEV-ES, although it includes other options. Outtake from Libvirt documentation:

<launchSecurity type='tdx'>
     <policy>0x10000001</policy>
     <mrConfigId>xxx</mrConfigId>
     <mrOwner>xxx</mrOwner>
     <mrOwnerConfig>xxx</mrOwnerConfig>
     <quoteGenerationSocket path="/var/run/tdx-qgs/qgs.socket"/>
</launchSecurity>

The current implementation of SEV/SEV-ES does not expose any configuration of the options. Therefore, for an initial implementation of TDX the following is proposed:

  • Hardcode policy to 0x10000000, which disables debugging, but keeps SEPT_VE_DISABLE. This is the default policy with debugging disabled.

  • quoteGenerationSocket is optional, but needed for attestation. By default (if path is omitted) it will include the default socket path: /var/run/tdx-qgs/qgs.socket. This default should not conflict with other sockets and will integrate directly with the Quote Generation Service (QGS) for attestation.

  • Remaining fields are meant for user configuration and will be left as default (empty).

The resulting launchSecurity:

<launchSecurity type='tdx'>
     <policy>0x10000000</policy>
     <quoteGenerationSocket/>
</launchSecurity>

The firmware will be selected automatically following the changes in libvirt-firmware-auto-selection. Thus, no additional XML needs to be generated to specify TDX firmware.

  1. Verify flavor/image:

Introduce MemEncryptionConfigTdx (based on MemEncryptionConfig) to verify instance flavor and image configuration. Intel TDX requires machine_type q35 and UEFI firmware, this aligns with existing checks for SEV. Stateless firmware is also required, which is configured on the image with hw_firmware_stateless=True.

Using an SCSI boot drive is not supported as TDX firmware does not include the necessary drivers. This applies to both legacy SCSI and virtio-scsi, therefore the instance should be rejected if any of the following fields are configured:

  • hw_disk_bus=scsi

  • hw_scsi_model=virtio-scsi, this can be expanded to ensure that it is not set at all since all values will imply SCSI, currently there is only one value though.

Block device mappings configuration with hw_disk_bus=scsi also needs to be rejected. Only needed if the block device is intended to be booted from.

TDX also does not support suspend. Live-migration support is ongoing, but not yet there. A reject function like reject_sev_instances will therefore be needed to reject these operations.

Alternatives

The generalization of the SEV implementation makes the approach for TDX clear, but below are some alternative approaches for when TDX differs from the current implementation of SEV.

  1. Detection of TDX host capabilities:

TDX also exposes values in MSR that indicates if it is enabled on the host, it essentially just reports what is configured in BIOS. Using MSR requires elevated privileges and is thus not preferred. Kernel logs also contains some information.

The minimum required Libvirt, QEMU and kernel versions could also be included in these capabilities checks. However, these are implicitly checked already with the other checks and potentially can be misleading due to backporting and for example the Canonical TDX preview for Ubuntu 24.04. Where this becomes necessary is when Nova starts using functionality which these checks don’t cover. This is not yet the case in this spec.

  1. Resource tracking:

Another file is also exposed to track the current number of TDX keys in use.

  • /sys/fs/cgroup/misc.current — the number of TDX KeyIDs currently allocated across all processes and VMs on the host, maintained in real time by the kernel. Example content:

    tdx 3

This will not be leveraged since Nova will handle the tracking.

  1. Image and flavor:

This spec could also address the problem with the default by making it configurable or providing a generic trigger so that Nova is able to identify the most fitting hw:mem_encryption_model. These solutions make it better for the users, but ideally there would be no default since the different technologies imply vastly different integrity and confidentiality. AMD SEV would for instance not satisfy a lot of what Intel TDX or AMD SEV-SNP brings. This is thus considered out of scope for this spec since Intel TDX with proper documentation should work correctly without changing the default logic.

  1. XML generation:

Several different approaches were considered for the configuration of the launchSecurity object:

  • Expose policy as a host configuration. This field is a concern for the end user, and it complicates attestations if different hosts have different policies.

  • Other value for the default policy. For example enable bit 63 for performance monitoring.

  • Expose quoteGenerationSocket path as a host config (nova.conf). This would allow operators to define the socket path per host. This is only needed to support fine-grain control of the setup and there is little value added by having this be configurable on the host, more value is added by a user defined configuration.

  • Expose quoteGenerationSocket path as user configuration via the API. This would match the implementation in Libvirt. An end-user could want to decide which Quote Generation Service to use and thus select the associated path.

  • Expose policy, mrConfigId, mrOwner and mrOwnerConfig as user configuration via the API. Ideally something like this is needed, but it also introduces a lot of unwanted complexity, especially since Nova currently exposes a confidential computing agnostic api. Intel TDX is also functional without user configuration of these fields.

  • A generic interface for all user provided configuration with all confidential computing implementations. Deemed out of scope. Once support for AMD SEV-SNP and ARM CCA is in a generic interface can be made.

  • Wait for generic interface. Hold all of Intel TDX support until a generic interface for user provided options for confidential computing is implemented in Nova. TDX will function without the user provided data and getting partial TDX support is considered better than none.

Data model impact

None

REST API impact

None

Security impact

None

Notifications impact

None

Other end user impact

Users that want to use Intel TDX will need to:

Ensure their images support UEFI boot and are configured with hw_firmware_type=uefi (image property) or use flavors with hw:firmware_type=uefi (flavor extra spec).

Ensure images use Q35 machine type (hw_machine_type=q35 image property) or use flavors with hw:machine_type=q35 (flavor extra spec), or rely on host-configured defaults via libvirt.hw_machine_type in nova.conf.

Ensure the guest OS includes TDX support.

Set appropriate image properties or flavor extra specs to request TDX.

There are some limitations with using Intel TDX. Reboot and live migration is as of now not supported. Libvirt fakes reboots with a shutdown and power on sequence for Intel TDX. Many of the limitations with AMD SEV are also present in Intel TDX:

https://docs.openstack.org/nova/latest/admin/sev.html#limitations

Notable differences:

  • memlocked is not required for TDX

Other limitations:

  • Hugepages (hw:mem_page_size) support is ongoing but not merged, see patches:

https://lore.kernel.org/kvm/20260106101646.24809-1-yan.y.zhao@intel.com/

hugepages will not prevent the VM from booting. Larger pages (2MB or 1GB) will be demoted to the standard page size.

  • host cpu type (host-passthrough) is required.

Note

host-passthrough can be more limiting for live-migration, as described at https://docs.openstack.org/nova/latest/admin/cpu-models.html#host-passthrough. These limitations still apply to Intel TDX, but since live-migration is not supported it is not yet a concern. Non-TDX instances on a TDX node will, however, have these limitations since host-passthrough is a node-wide configuration and a prerequisite for Intel TDX.

  • The firmware (TDVF) for TDX purposefully excludes some drivers. This includes the SCSI driver and thus SCSI storage types cannot be used for the boot device. See patch:

https://github.com/tianocore/edk2/commit/c3f4f5a949a9e94bafe081c24dbd4110834b11ea

  • VNC consoles are not supported. Configuring VNC will not stop the VM from starting, but the console will be effectively unusable due to TDX.

Performance Impact

  • Additional host capabilities check.

  • Intel TDX impacts memory performance (3-5%) when enabled. This is expected for confidential computing.

Other deployer impact

Operators deploying Intel TDX support will need to:

  • Deploy TDX-capable hardware:

Intel 5th Gen Xeon Scalable Processors or later with TDX support enabled in BIOS.

  • Install required software stack:

    • Linux kernel >= 6.16 with TDX host support

    • QEMU >= 10.1

    • libvirt >= 11.6.0

    • TDX module firmware

These requirements can be fulfilled with Ubuntu 25.10 and later

Note

Ubuntu 24.04 can be used with a tech preview from Canonical. The versions of QEMU, Libvirt and kernel are significantly older than that of the above requirements, but patched to include TDX support.

More info at: https://github.com/canonical/tdx

  • Quote Generation Service (QGS)

For attestation the Quote Generation Service needs to run on the host. This is distributed by Intel, but has to be setup by the operator.

The platform also needs to be registered with Intel.

Attestation is not required, although it is arguably what makes confidential computing useful. TDX VMs will still boot with memory encryption without these services but cannot be verified.

  • Configure Nova:

    • Set libvirt.hw_machine_type to x86_64=q35.

    • Ensure libvirt.virt_type is set to kvm.

    • Set libvirt.cpu_mode to host-passthrough.

Developer impact

None

Upgrade impact

None

Implementation

Assignee(s)

Primary assignee:

antia3 (Anton Iacobaeus)

Other contributors:

None

Feature Liaison

Liaison Needed

Work Items

  • Add Intel TDX to host capabilities

  • Add OS trait for TDX (os-traits)

  • Add TDX to mem_encryption image and flavor

  • Add XML generation for TDX launchSecurity

  • Add TDX key slot resource tracking

  • Add constraint checks for TDX flavors/images

All work items will also include unit testing.

Dependencies

  • libvirt-firmware-auto-selection

(blueprint in progress for 2026.1): Required for automatic TDVF firmware selection. TDX implementation should use this infrastructure rather than manual firmware configuration.

  • generalize-sev-code:

(blueprint in progress for 2026.1): Required to provide generalized abstractions for memory encryption support. This spec uses the structure provided by this blueprint.

  • Libvirt >= 11.6.0:

Required for TDX support in domain capabilities and XML generation.

  • QEMU >= 10.1:

Required for TDX guest support.

  • Linux Kernel/KVM >= 6.16:

Required for TDX module support in the host.

  • os-traits library:

Needs update to add HW_CPU_X86_INTEL_TDX trait.

  • Hardware:

Development, testing, and CI requires Intel TDX capable hardware.

Testing

The fakelibvirt test driver will need to be extended with Intel TDX capabilities.

Unit testing covers the individual functionality of:

  • Host capabilities

  • XML generation

  • image/flavor constraints

  • Resource tracking for TDX key slots

Tempest and integration tests will require Intel TDX hardware, if made available through third-party CI.

Documentation Impact

Admin Documentation (docs.openstack.org/nova/latest/admin/):

  • New section on Intel TDX setup and configuration (similar to existing AMD SEV section at admin/sev.html)

  • Hardware requirements and BIOS configuration steps

  • Software stack requirements (kernel, QEMU, libvirt, TDX module)

  • Configuration options for nova.conf

  • Limitations and known issues

Intel TDX enabling guide covers a lot of this already and can be referenced.

User Documentation (docs.openstack.org/nova/latest/user/):

  • How to request TDX instances via flavors or image properties

  • Guest OS requirements for TDX

  • default configuration options of launchSecurity object

  • Limitations on operations (live migration, suspend, and so on)

  • Functional limitations (VNC console, huge-pages, and so on)

  • How to verify that TDX is active (on guest)

  • Basic attestation example

Intel TDX enabling guide also covers parts of this.

API Documentation:

  • Update existing flavor extra specs and image properties documentation to include intel-tdx as a valid value for hw_mem_encryption_model

  • Update os-trait documentation to include HW_CPU_X86_INTEL_TDX

References

History

Revisions

Release Name

Description

2026.2 Hibiscus

Introduced