On Wed, Dec 01, 2021, Isaku Yamahata wrote: > On Thu, Dec 02, 2021 at 02:22:27AM +1300, > Kai Huang <kai.huang@xxxxxxxxx> wrote: > > > On Tue, 30 Nov 2021 18:51:52 +0000 Sean Christopherson wrote: > > > On Wed, Nov 24, 2021, isaku.yamahata@xxxxxxxxx wrote: > > > > - drop load/initialization of TDX module > > > > > > So what's the plan for loading and initializing TDX modules? > > > > Although I don't quite understand what does Isaku mean here (I thought > > loading/initializing TDX module was never part of TDX KVM series), for this part > > we are working internally to improve the quality and finalize the code, but > > currently I don't have ETA of being able to send patches out, but we are trying > > to send out asap. Sorry this is what I can say for now : ( > > v1/v2 has it. No, v1 had support for the old architecture where SEAMLDR was a single ACM, it did not support the new split persistent/non-persistent architcture. v2 didn't have support for either architecture. > Anyway The plan is what Kai said. The code will reside in the x86 common > directory instead of kvm. But what's the plan at a higher level? Will the kernel load the ACM or is that done by firmware? If it's done by firmware, which entity is responsibile for loading the TDX module? If firmware loads the module, what's the plan for upgrading the module without a reboot? When will the kernel initialize the module, regardless of who loads it? All of those unanswered questions make it nigh impossible to review the KVM support because the code organization and APIs provided will differ based on how the kernel handles loading and initializing the TDX module.