Lines Matching full:ve
15 implemented using a Virtualization Exception (#VE) that is handled by the
16 guest kernel. A #VE is handled entirely inside the guest kernel, but some
27 #VE or #GP exceptions.
32 Instruction-based #VE
60 - #VE generated
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.
91 A #VE is generated for CPUID leaves and sub-leaves that the TDX module does
95 #VE on Memory Accesses
109 #VE on Shared Memory
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
116 #VE handler before it reads the #VE info structure (TDG.VP.VEINFO.GET).
127 handle a #VE.
129 #VE on Private Pages
132 An access to private mappings can also cause a #VE. Since all kernel
134 handle a #VE on arbitrary kernel memory accesses. This is not feasible, so
140 being subjected to a #VE.
144 #VE. It will, instead, cause a "TD Exit" where the hypervisor is required
147 Linux #VE handler
150 Just like page faults or #GP's, #VE exceptions can be either handled or be
151 fatal. Typically, an unhandled userspace #VE results in a SIGSEGV.
152 An unhandled kernel #VE results in an oops.
154 Handling nested exceptions on x86 is typically nasty business. A #VE
155 could be interrupted by an NMI which triggers another #VE and hilarity
156 ensues. The TDX #VE architecture anticipated this scenario and includes a
159 During #VE handling, the TDX module ensures that all interrupts (including
162 or a new #VE can be delivered.
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)
178 In TDX, MMIO regions typically trigger a #VE exception in the guest. The
179 guest #VE handler then emulates the MMIO instruction inside the guest and