Lines Matching refs:guest
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
13 Since the host cannot directly access guest registers or memory, much
14 normal functionality of a hypervisor must be moved into the guest. This is
16 guest kernel. A #VE is handled entirely inside the guest kernel, but some
20 guest to the hypervisor or the TDX module.
64 indicates a bug in the guest. The guest may try to handle the #GP with a
70 The "just works" MSRs do not need any special guest handling. They might
79 return values (in guest EAX/EBX/ECX/EDX) are configurable by the
83 - Bit fields for which the hypervisor controls the value seen by the guest
87 guest TD either sees their native value or a value of 0. For these bit
92 not know how to handle. The guest kernel may ask the hypervisor for the
101 shared between guest and hypervisor and does not receive full TDX
104 A TD guest is in control of whether its memory accesses are treated as
106 entries. This helps ensure that a guest does not place sensitive
113 controls whether a shared memory access causes a #VE, so the guest must be
115 instance, the guest should be careful not to access shared memory in the
118 Shared mapping content is entirely controlled by the hypervisor. The guest
125 MMIO for virtual devices is implemented as shared memory. The guest must
135 TDX guests ensure that all guest memory has been "accepted" before memory
160 NMIs) are blocked. The block remains in place until the guest makes a
161 TDG.VP.VEINFO.GET TDCALL. This allows the guest to control when interrupts
164 However, the guest kernel must still be careful to avoid potential
172 In non-TDX VMs, MMIO is usually implemented by giving a guest access to a
178 In TDX, MMIO regions typically trigger a #VE exception in the guest. The
179 guest #VE handler then emulates the MMIO instruction inside the guest and
181 guest state to the host.
194 All TDX guest memory starts out as private at boot. This memory can not
216 Attestation is used to verify the TDX guest trustworthiness to other
217 entities before provisioning secrets to the guest. For example, a key
218 server may want to use attestation to verify that the guest is the
222 The TDX module records the state of the TDX guest in various stages of
223 the guest boot process using the build time measurement register (MRTD)
225 guest initial configuration and firmware image are recorded in the MRTD
230 At TDX guest runtime, the attestation process is used to attest to these
236 TDX guest uses TDCALL[TDG.MR.REPORT] to get the TDREPORT (TDREPORT_STRUCT)
238 the TDX module which contains guest-specific information (such as build