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:   Thu, 31 Mar 2022 00:03:15 +0000
From:   Sean Christopherson <seanjc@google.com>
To:     Isaku Yamahata <isaku.yamahata@gmail.com>
Cc:     Paolo Bonzini <pbonzini@redhat.com>, isaku.yamahata@intel.com,
        kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
        Jim Mattson <jmattson@google.com>, erdemaktas@google.com,
        Connor Kuehl <ckuehl@redhat.com>
Subject: Re: [RFC PATCH v5 008/104] KVM: TDX: Add a function to initialize
 TDX module
Message-ID: <YkTvw5OXTTFf7j4y@google.com>
References: <cover.1646422845.git.isaku.yamahata@intel.com>
 <b92217283fa96b85e9a683ca3fcf1b368cf8d1c4.1646422845.git.isaku.yamahata@intel.com>
 <05aecc5a-e8d2-b357-3bf1-3d0cb247c28d@redhat.com>
 <20220314194513.GD1964605@ls.amr.corp.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220314194513.GD1964605@ls.amr.corp.intel.com>
Precedence: bulk

On Mon, Mar 14, 2022, Isaku Yamahata wrote:
> On Sun, Mar 13, 2022 at 03:03:40PM +0100,
> Paolo Bonzini <pbonzini@redhat.com> wrote:
> 
> > On 3/4/22 20:48, isaku.yamahata@intel.com wrote:
> > > +
> > > +	if (!tdx_module_initialized) {
> > > +		if (enable_tdx) {
> > > +			ret = __tdx_module_setup();
> > > +			if (ret)
> > > +				enable_tdx = false;
> > 
> > "enable_tdx = false" isn't great to do only when a VM is created.  Does it
> > make sense to anticipate this to the point when the kvm_intel.ko module is
> > loaded?
> 
> It's possible.  I have the following two reasons to chose to defer TDX module
> initialization until creating first TD.  Given those reasons, do you still want
> the initialization at loading kvm_intel.ko module?  If yes, I'll change it.

Yes, TDX module setup needs to be done at load time.  The loss of memory is
unfortunate, e.g. if the host is part of a pool that _might_ run TDX guests, but
the alternatives are worse.  If TDX fails to initialize, e.g. due to low mem,
then the host will be unable to run TDX guests despite saying "I support TDX".
Or this gem :-)

	/*
	 * TDH.SYS.KEY.CONFIG may fail with entropy error (which is
	 * a recoverable error).  Assume this is exceedingly rare and
	 * just return error if encountered instead of retrying.
	 */

The CPU overhead of initializing the TDX module is also non-trivial, and it
doesn't affect just this CPU, e.g. all CPUs need to do certain SEAMCALLs and at
least one WBINVD.  The can cause noisy neighbor problems.

> - memory over head: The initialization of TDX module requires to allocate
> physically contiguous memory whose size is about 0.43% of the system memory.
> If user don't use TD, it will be wasted.
> 
> - VMXON on all pCPUs: The TDX module initialization requires to enable VMX
> (VMXON) on all present pCPUs.  vmx_hardware_enable() which is called on creating
> guest does it.  It naturally fits with the TDX module initialization at creating
> first TD.  I wanted to avoid code to enable VMXON on loading the kvm_intel.ko.

That's a solvable problem, though making it work without exporting hardware_enable_all()
could get messy.