arch/x86/tdx.rst

7 Intel's Trust Domain Extensions (TDX) protect confidential guest VMs from
8 the host and physical attacks by isolating the guest register state and by
9 encrypting the guest memory. In TDX, a special module running in a special
10 mode sits between the host and the guest and manages the guest/host
196 TDX Guest Support
198 Since the host cannot directly access guest registers or memory, much
199 normal functionality of a hypervisor must be moved into the guest. This is
201 guest kernel. A #VE is handled entirely inside the guest kernel, but some
205 guest to the hypervisor or the TDX module.
249 indicates a bug in the guest.  The guest may try to handle the #GP with a
255 The "just works" MSRs do not need any special guest handling.  They might
264 return values (in guest EAX/EBX/ECX/EDX) are configurable by the
268 - Bit fields for which the hypervisor controls the value seen by the guest
272   guest TD either sees their native value or a value of 0.  For these bit
277 not know how to handle. The guest kernel may ask the hypervisor for the
286 shared between guest and hypervisor and does not receive full TDX
289 A TD guest is in control of whether its memory accesses are treated as
291 entries.  This helps ensure that a guest does not place sensitive
298 controls whether a shared memory access causes a #VE, so the guest must be
300 instance, the guest should be careful not to access shared memory in the
303 Shared mapping content is entirely controlled by the hypervisor. The guest
310 MMIO for virtual devices is implemented as shared memory.  The guest must
320 TDX guests ensure that all guest memory has been "accepted" before memory
345 NMIs) are blocked.  The block remains in place until the guest makes a
346 TDG.VP.VEINFO.GET TDCALL.  This allows the guest to control when interrupts
349 However, the guest kernel must still be careful to avoid potential
357 In non-TDX VMs, MMIO is usually implemented by giving a guest access to a
363 In TDX, MMIO regions typically trigger a #VE exception in the guest.  The
364 guest #VE handler then emulates the MMIO instruction inside the guest and
366 guest state to the host.
379 All TDX guest memory starts out as private at boot.  This memory can not
401 Attestation is used to verify the TDX guest trustworthiness to other
402 entities before provisioning secrets to the guest. For example, a key
403 server may want to use attestation to verify that the guest is the
407 The TDX module records the state of the TDX guest in various stages of
408 the guest boot process using the build time measurement register (MRTD)
410 guest initial configuration and firmware image are recorded in the MRTD
415 At TDX guest runtime, the attestation process is used to attest to these
421 TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT)
423 the TDX module which contains guest-specific information (such as build