Messages in this thread | | | Subject | Re: [RFC v2 08/32] x86/traps: Add #VE support for TDX guest | From | Dave Hansen <> | Date | Thu, 13 May 2021 13:14:11 -0700 |
| |
On 5/13/21 12:47 PM, Andi Kleen wrote: > I don't see what could be added. If you have concrete suggestions please > just propose something.
Oh, boy, I love writing changelogs! I was hoping that the TDX folks would chip in to write their own changelogs, but oh well. You made my day!
--
Virtualization Exceptions (#VE) are delivered to TDX guests due to specific guest actions which may happen in either userspace or the kernel:
* Specific instructions (WBINVD, for example) * Specific MSR accesses * Specific CPUID leaf accesses * Access to TD-shared memory, which includes MMIO
#VE exceptions are never generated on accesses to normal, TD-private memory.
The entry paths do not access TD-shared memory or use those specific MSRs, instructions, CPUID leaves. In addition, all interrupts including NMIs are blocked by the hardware starting with #VE delivery until TDGETVEINFO is called. This eliminates the chance of a #VE during the syscall gap or paranoid entry paths and simplifies #VE handling.
If a guest kernel action which would normally cause a #VE occurs in the interrupt-disabled region before TDGETVEINFO, a #DF is delivered to the guest.
Add basic infrastructure to handle any #VE which occurs in the kernel or userspace. Later patches will add handling for specific #VE scenarios.
Convert unhandled #VE's (everything, until later in this series) so that they appear just like a #GP by calling do_general_protection() directly.
--
Did I miss anything?
| |