> > > 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? The UEFI loads both ACM and TDX module before booting into kernel by using UEFI tool. The runtime update is pushed out for future support. One goal of this is to reduce the code size so that it can be reviewed more easily and quickly. And yes kernel will initialize the TDX module. The direction we are heading is to allow to defer TDX module initialization when TDX is truly needed, i.e. When KVM is loaded with TDX support, or first TD is created. The code will basically still reside in host kernel, provided as functions, etc. And at first stage, KVM will call those functions to initialize TDX when needed. The advantage of this approach is it provides more flexibility: the TDX module initialization code can be reused by future TDX runtime update, etc. And with only initializing TDX in KVM, the host kernel doesn't need to handle entering VMX operation, etc. It can be introduced later when needed. > > 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. I think theoretically loading/initializing module should be quite independent from KVM series, but yes in practice the APIs matter, but I also don't expect this will reduce the ability to review KVM series a lot as RFC. Anyway sending out host kernel patches is our top priority now and we are trying to do asap.
