Lines Matching +full:dma +full:- +full:shared +full:- +full:all
1 .. SPDX-License-Identifier: GPL-2.0
19 TDX includes new hypercall-like mechanisms for communicating from the
25 TDX guests behave differently from bare-metal and traditional VMX guests.
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
98 There are essentially two classes of TDX memory: private and shared.
100 against access from the hypervisor. Shared memory is expected to be
101 shared between guest and hypervisor and does not receive full TDX
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
125 MMIO for virtual devices is implemented as shared memory. The guest must
130 --------------------
132 An access to private mappings can also cause a #VE. Since all kernel
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
159 During #VE handling, the TDX module ensures that all interrupts (including
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
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
200 * set_memory_decrypted() converts a range of pages to shared.
203 Device drivers are the primary user of shared memory, but there's no need
204 to touch every driver. DMA buffers and ioremap() do the conversions
207 TDX uses SWIOTLB for most DMA allocations. The SWIOTLB buffer is
208 converted to shared on boot.
210 For coherent DMA allocation, the DMA buffer gets converted on the
237 from the TDX module. TDREPORT is a fixed-size data structure generated by
238 the TDX module which contains guest-specific information (such as build
240 the integrity of the TDREPORT. A user-provided 64-Byte REPORTDATA is used
261 https://www.intel.com/content/www/us/en/developer/articles/technical/intel-trust-domain-extensions.…