Lines Matching +full:shared +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"
76 --------------
78 For some CPUID leaves and sub-leaves, the virtualized bit fields of CPUID
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
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
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 --------------------
112 Access to shared mappings can cause a #VE. The hypervisor ultimately
113 controls whether a shared memory access causes a #VE, so the guest must be
114 careful to only reference shared pages it can safely handle a #VE. For
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
119 should only use shared mappings for communicating with the hypervisor.
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
165 #VE-triggering actions (discussed above) while this block is in place.
172 In non-TDX VMs, MMIO is usually implemented by giving a guest access to a
184 theoretically be accessed with any instruction that accesses memory.
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:
200 * set_memory_decrypted() converts a range of pages to shared.
201 * set_memory_encrypted() converts memory back to private.
203 Device drivers are the primary user of shared memory, but there's no need
208 converted to shared on boot.
218 https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.…