arch/x86/tdx.rst

199 normal functionality of a hypervisor must be moved into the guest. This is
202 require the hypervisor to be consulted.
205 guest to the hypervisor or the TDX module.
252 The #VE MSRs are typically able to be handled by the hypervisor.  Guests
253 can make a hypercall to the hypervisor to handle the #VE.
265 hypervisor. For such cases, the Intel TDX module architecture defines two
268 - Bit fields for which the hypervisor controls the value seen by the guest
271 - Bit fields for which the hypervisor configures the value such that the
273   fields, the hypervisor can mask off the native values, but it can not
277 not know how to handle. The guest kernel may ask the hypervisor for the
285 against access from the hypervisor.  Shared memory is expected to be
286 shared between guest and hypervisor and does not receive full TDX
292 information in shared memory, exposing it to the untrusted hypervisor.
297 Access to shared mappings can cause a #VE.  The hypervisor ultimately
303 Shared mapping content is entirely controlled by the hypervisor. The guest
304 should only use shared mappings for communicating with the hypervisor.
306 stacks.  A good rule of thumb is that hypervisor-shared memory should be
307 treated the same as memory mapped to userspace.  Both the hypervisor and
327 The hypervisor is permitted to unilaterally move accepted pages to a
329 #VE.  It will, instead, cause a "TD Exit" where the hypervisor is required
358 mapping which will cause a VMEXIT on access, and then the hypervisor
380 be accessed by the hypervisor.  However, some kernel users like device
381 drivers might have a need to share data with the hypervisor.  To do this,