Re: [PATCH v5 07/12] x86/traps: Add #VE support for TDX guest

Kuppuswamy, Sathyanarayanan
2021-09-02T15:25:11Z

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