Messages in this thread | | | Date | Sun, 27 Feb 2022 00:35:28 +0300 | From | "Kirill A. Shutemov" <> | Subject | Re: [PATCHv4 09/30] x86/tdx: Add MSR support for TDX guests |
| |
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
| |