arch/x86/tdx.rst

14 normal functionality of a hypervisor must be moved into the guest. This is
17 require the hypervisor to be consulted.
20 guest to the hypervisor or the TDX module.
67 The #VE MSRs are typically able to be handled by the hypervisor.  Guests
68 can make a hypercall to the hypervisor to handle the #VE.
80 hypervisor. For such cases, the Intel TDX module architecture defines two
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
88   fields, the hypervisor can mask off the native values, but it can not
92 not know how to handle. The guest kernel may ask the hypervisor for the
100 against access from the hypervisor.  Shared memory is expected to be
101 shared between guest and hypervisor and does not receive full TDX
107 information in shared memory, exposing it to the untrusted hypervisor.
112 Access to shared mappings can cause a #VE.  The hypervisor ultimately
118 Shared mapping content is entirely controlled by the hypervisor. The guest
119 should only use shared mappings for communicating with the hypervisor.
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
142 The hypervisor is permitted to unilaterally move accepted pages to a
144 #VE.  It will, instead, cause a "TD Exit" where the hypervisor is required
173 mapping which will cause a VMEXIT on access, and then the hypervisor
195 be accessed by the hypervisor.  However, some kernel users like device
196 drivers might have a need to share data with the hypervisor.  To do this,