Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Date:   Sun, 27 Feb 2022 00:35:28 +0300
From:   "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
To:     Dave Hansen <dave.hansen@intel.com>
Cc:     tglx@linutronix.de, mingo@redhat.com, bp@alien8.de,
        luto@kernel.org, peterz@infradead.org,
        sathyanarayanan.kuppuswamy@linux.intel.com, aarcange@redhat.com,
        ak@linux.intel.com, dan.j.williams@intel.com, david@redhat.com,
        hpa@zytor.com, jgross@suse.com, jmattson@google.com,
        joro@8bytes.org, jpoimboe@redhat.com, knsathya@kernel.org,
        pbonzini@redhat.com, sdeep@vmware.com, seanjc@google.com,
        tony.luck@intel.com, vkuznets@redhat.com, wanpengli@tencent.com,
        thomas.lendacky@amd.com, brijesh.singh@amd.com, x86@kernel.org,
        linux-kernel@vger.kernel.org
Subject: Re: [PATCHv4 09/30] x86/tdx: Add MSR support for TDX guests
Message-ID: <20220226213528.tt5uchvmvo67w4tb@black.fi.intel.com>
References: <20220224155630.52734-1-kirill.shutemov@linux.intel.com>
 <20220224155630.52734-10-kirill.shutemov@linux.intel.com>
 <67dfdb0c-c483-ec3c-4fb8-57086ffde9bf@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <67dfdb0c-c483-ec3c-4fb8-57086ffde9bf@intel.com>
Precedence: bulk

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