Re: [PATCHv4 09/30] x86/tdx: Add MSR support for TDX guests

["Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>]

On Thu, Feb 24, 2022 at 10:52:23AM -0800, Dave Hansen wrote:
> On 2/24/22 07:56, Kirill A. Shutemov wrote:
> > Use hypercall to emulate MSR read/write for the TDX platform.
> > 
> > There are two viable approaches for doing MSRs in a TD guest:
> > 
> > 1. Execute the RDMSR/WRMSR instructions like most VMs and bare metal
> >    do. Some will succeed, others will cause a #VE. All of those that
> >    cause a #VE will be handled with a TDCALL.
> > 2. Use paravirt infrastructure.  The paravirt hook has to keep a list
> >    of which MSRs would cause a #VE and use a TDCALL.  All other MSRs
> >    execute RDMSR/WRMSR instructions directly.
> > 
> > The second option can be ruled out because the list of MSRs was
> > challenging to maintain. That leaves option #1 as the only viable
> > solution for the minimal TDX support.
> > 
> > For performance-critical MSR writes (like TSC_DEADLINE), future patches
> > will replace the WRMSR/#VE sequence with the direct TDCALL.
> 
> This will still leave us with a list of non-#VE-inducing MSRs.  That's
> not great.

Em. No. TSC_DEADLINE is #VE-inducing MSR. So we will only maintain a list
of performance-critical MSR writes that do trigger #VE.

Here's how we do it now:

https://github.com/intel/tdx/commit/2cea8becaa5a287c93266c01fc7f2a4ed53c509d

The idea is if MSR is in the list, go for direct TDVMCALL. Otherwise go for
native WRMSR that may or may not trigger #VE.

> But, if we miss an MSR in the performance-critical list, the
> result is a slow WRMSR->#VE.  If we miss an MSR in the paravirt
> approach, we induce a fatal #VE.
> 
> Please add something to that effect if you revise this patch.

I'm not sure explaining mechanism of a future patch is a good idea.
It may change before it gets implemented.

-- 
 Kirill A. Shutemov