Messages in this thread | | | Subject | Re: [PATCH v5 07/12] x86/traps: Add #VE support for TDX guest | From | "Kuppuswamy, Sathyanarayanan" <> | Date | Thu, 2 Sep 2021 08:24:53 -0700 |
| |
On 8/24/21 10:46 AM, Borislav Petkov wrote: > On Tue, Aug 24, 2021 at 10:32:13AM -0700, Kuppuswamy, Sathyanarayanan wrote: >> Mainly chose it avoid future name conflicts with KVM (tdx) calls. But > > What name conflicts with KVM calls? Please explain.
Currently there are no name conflicts. But in our initial submissions (RFC v?) we had some conflicts in functions like (tdx_get_tdreport() and tdx_get_quote()).
Since it is no longer true and "tdg" is not a favorite prefix, I will rename tdg -> tdx in next submission.
> >> It is required to handle #VE exceptions raised by unhandled MSR >> read/writes. > > Example? Please elaborate.
If MSR read/write failed in tdx_handle_virtualization_exception(), it will return non zero return value which in turn will trigger ve_raise_fault().
If we don't call fixup_exception() for such case, it will trigger oops and eventually panic in TDX. For MSR read/write failures we don't want to panic.
#VE MSR read/write -> exc_virtualization_exception() -> tdx_handle_virtualization_exception() ->tdx_write_msr_safe() -> ve_raise_fault -> fixup_exception()
> >> Ok. I can check it. But there is only one statement after this call. >> So it may not be very helpful. > > Looking at die_addr(), that calls the die notifier too. So do you > even *have* to call it here with VEFSTR? As yo say, there's only one > statement after that call and box is dead in the water after that so why > even bother...
Reason for calling die_addr() is to trigger oops for failed #VE handling, which is desirable for TDX. Also sending die notification may be useful for debuggers.
This sequence of calls are similar to exc_general_protection().
>
-- Sathyanarayanan Kuppuswamy Linux Kernel Developer
| |