Lines Matching +full:in +full:- +full:memory
1 .. SPDX-License-Identifier: GPL-2.0
9 encrypting the guest memory. In TDX, a special module running in a special
13 Since the host cannot directly access guest registers or memory, much
19 TDX includes new hypercall-like mechanisms for communicating from the
25 TDX guests behave differently from bare-metal and traditional VMX guests.
26 In TDX guests, otherwise normal instructions or memory accesses can cause
32 Instruction-based #VE
33 ---------------------
35 - Port I/O (INS, OUTS, IN, OUT)
36 - HLT
37 - MONITOR, MWAIT
38 - WBINVD, INVD
39 - VMCALL
40 - RDMSR*,WRMSR*
41 - CPUID*
43 Instruction-based #GP
44 ---------------------
46 - All VMX instructions: INVEPT, INVVPID, VMCLEAR, VMFUNC, VMLAUNCH,
48 - ENCLS, ENCLU
49 - GETSEC
50 - RSM
51 - ENQCMD
52 - RDMSR*,WRMSR*
55 --------------------
59 - #GP generated
60 - #VE generated
61 - "Just works"
63 In general, the #GP MSRs should not be used in guests. Their use likely
64 indicates a bug in the guest. The guest may try to handle the #GP with a
72 trapping and handling in the TDX module. Other than possibly being slow,
76 --------------
78 For some CPUID leaves and sub-leaves, the virtualized bit fields of CPUID
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
86 - Bit fields for which the hypervisor configures the value such that the
91 A #VE is generated for CPUID leaves and sub-leaves that the TDX module does
95 #VE on Memory Accesses
98 There are essentially two classes of TDX memory: private and shared.
99 Private memory receives full TDX protections. Its content is protected
100 against access from the hypervisor. Shared memory is expected to be
104 A TD guest is in control of whether its memory accesses are treated as
105 private or shared. It selects the behavior with a bit in its page table
107 information in shared memory, exposing it to the untrusted hypervisor.
109 #VE on Shared Memory
110 --------------------
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
120 Shared mappings must never be used for sensitive memory content like kernel
121 stacks. A good rule of thumb is that hypervisor-shared memory should be
122 treated the same as memory mapped to userspace. Both the hypervisor and
125 MMIO for virtual devices is implemented as shared memory. The guest must
130 --------------------
133 memory is also private memory, the kernel might theoretically need to
134 handle a #VE on arbitrary kernel memory accesses. This is not feasible, so
135 TDX guests ensure that all guest memory has been "accepted" before memory
138 A modest amount of memory (typically 512M) is pre-accepted by the firmware
151 fatal. Typically, an unhandled userspace #VE results in a SIGSEGV.
152 An unhandled kernel #VE results in an oops.
160 NMIs) are blocked. The block remains in place until the guest makes a
165 #VE-triggering actions (discussed above) while this block is in place.
166 While the block is in place, any #VE is elevated to a double fault (#DF)
172 In non-TDX VMs, MMIO is usually implemented by giving a guest access to a
174 emulates the access. That is not possible in TDX guests because VMEXIT
178 In TDX, MMIO regions typically trigger a #VE exception in the guest. The
184 theoretically be accessed with any instruction that accesses memory.
188 MMIO access via other means (like structure overlays) may result in an
191 Shared Memory Conversions
194 All TDX guest memory starts out as private at boot. This memory can not
197 memory must be converted between shared and private. This can be
198 accomplished using some existing memory encryption helpers:
201 * set_memory_encrypted() converts memory back to private.
203 Device drivers are the primary user of shared memory, but there's no need
218 https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.…