[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b90aaac2d55674550d35ce5a4ddd604825423c3.camel@intel.com>
Date: Wed, 16 Mar 2022 10:47:31 +1300
From: Kai Huang <kai.huang@...el.com>
To: Isaku Yamahata <isaku.yamahata@...il.com>
Cc: isaku.yamahata@...el.com, kvm@...r.kernel.org,
linux-kernel@...r.kernel.org, Paolo Bonzini <pbonzini@...hat.com>,
Jim Mattson <jmattson@...gle.com>, erdemaktas@...gle.com,
Connor Kuehl <ckuehl@...hat.com>,
Sean Christopherson <seanjc@...gle.com>
Subject: Re: [RFC PATCH v5 010/104] KVM: TDX: Make TDX VM type supported
On Tue, 2022-03-15 at 14:03 -0700, Isaku Yamahata wrote:
> On Mon, Mar 14, 2022 at 12:08:59PM +1300,
> Kai Huang <kai.huang@...el.com> wrote:
>
> > On Fri, 2022-03-04 at 11:48 -0800, isaku.yamahata@...el.com wrote:
> > > From: Isaku Yamahata <isaku.yamahata@...el.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.
What is the purpose/value to allow developers to exercise the new code step-by-
step? Userspace cannot create TD successfully anyway until all patches are
ready.
--
Thanks,
-Kai
Powered by blists - more mailing lists