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

[Kuppuswamy, Sathyanarayanan]

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