Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 15 Mar 2022 14:03:50 -0700
From:   Isaku Yamahata <isaku.yamahata@gmail.com>
To:     Kai Huang <kai.huang@intel.com>
Cc:     isaku.yamahata@intel.com, kvm@vger.kernel.org,
        linux-kernel@vger.kernel.org, isaku.yamahata@gmail.com,
        Paolo Bonzini <pbonzini@redhat.com>,
        Jim Mattson <jmattson@google.com>, erdemaktas@google.com,
        Connor Kuehl <ckuehl@redhat.com>,
        Sean Christopherson <seanjc@google.com>
Subject: Re: [RFC PATCH v5 010/104] KVM: TDX: Make TDX VM type supported
Message-ID: <20220315210350.GE1964605@ls.amr.corp.intel.com>
References: <cover.1646422845.git.isaku.yamahata@intel.com>
 <0596db2913da40660e87d5005167c623cee14765.1646422845.git.isaku.yamahata@intel.com>
 <18a150fd2e0316b4bae283d244f856494e0dfefd.camel@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <18a150fd2e0316b4bae283d244f856494e0dfefd.camel@intel.com>
Precedence: bulk

On Mon, Mar 14, 2022 at 12:08:59PM +1300,
Kai Huang <kai.huang@intel.com> wrote:

> On Fri, 2022-03-04 at 11:48 -0800, isaku.yamahata@intel.com wrote:
> > From: Isaku Yamahata <isaku.yamahata@intel.com>
> > 
> > As first step TDX VM support, return that TDX VM type supported to device
> > model, e.g. qemu.  The callback to create guest TD is vm_init callback for
> > KVM_CREATE_VM.  Add a place holder function and call a function to
> > initialize TDX module on demand because in that callback VMX is enabled by
> > hardware_enable callback (vmx_hardware_enable).
> 
> Should we put this patch at the end of series until all changes required to run
> TD are introduced?  This patch essentially tells userspace KVM is ready to
> support a TD but actually it's not ready.  And this might also cause bisect
> issue I suppose?

The intention is that developers can exercise the new code step-by-step even if
the TDX KVM isn't complete.
How about introducing new config and remove it at the last of the patch series?

diff --git a/arch/x86/kvm/Kconfig b/arch/x86/kvm/Kconfig
index 2b1548da00eb..a3287440aa9e 100644
--- a/arch/x86/kvm/Kconfig
+++ b/arch/x86/kvm/Kconfig
@@ -98,6 +98,20 @@ config X86_SGX_KVM
 
          If unsure, say N.
 
+config X86_TDX_KVM_EXPERIMENTAL
+       bool "EXPERIMENTAL Trust Domian Extensions (TDX) KVM support"
+       default n
+       depends on INTEL_TDX_HOST
+       depends on KVM_INTEL
+       help
+         Enable experimental TDX KVM support.  TDX KVM needs many patches and
+         the patches will be merged step by step, not at once. Even if TDX KVM
+         support is incomplete, enable TDX KVM support so that developper can
+         exercise TDX KVM code.  TODO: Remove this configuration once the
+         (first step of) TDX KVM support is complete.
+
+         If unsure, say N.
+
 config KVM_AMD
        tristate "KVM for AMD processors support"
        depends on KVM
diff --git a/arch/x86/kvm/vmx/tdx.c b/arch/x86/kvm/vmx/tdx.c
index b16e2ed3b204..e31d6902e49c 100644
--- a/arch/x86/kvm/vmx/tdx.c
+++ b/arch/x86/kvm/vmx/tdx.c
@@ -170,7 +170,11 @@ int tdx_module_setup(void)
 
 bool tdx_is_vm_type_supported(unsigned long type)
 {
+#ifdef CONFIG_X86_TDX_KVM_EXPERIMENTAL
        return type == KVM_X86_TDX_VM && READ_ONCE(enable_tdx);
+#else
+       return false;
+#endif
 }
 
 static int __init __tdx_hardware_setup(struct kvm_x86_ops *x86_ops)


-- 
Isaku Yamahata <isaku.yamahata@gmail.com>