On Wed, 2023-10-18 at 12:14 +0300, Nikolay Borisov wrote: > > On 17.10.23 г. 13:14 ч., Kai Huang wrote: > > To enable TDX the kernel needs to initialize TDX from two perspectives: > > 1) Do a set of SEAMCALLs to initialize the TDX module to make it ready > > to create and run TDX guests; 2) Do the per-cpu initialization SEAMCALL > > on one logical cpu before the kernel wants to make any other SEAMCALLs > > on that cpu (including those involved during module initialization and > > running TDX guests). > > > > The TDX module can be initialized only once in its lifetime. Instead > > of always initializing it at boot time, this implementation chooses an > > "on demand" approach to initialize TDX until there is a real need (e.g > > when requested by KVM). This approach has below pros: > > > > 1) It avoids consuming the memory that must be allocated by kernel and > > given to the TDX module as metadata (~1/256th of the TDX-usable memory), > > and also saves the CPU cycles of initializing the TDX module (and the > > metadata) when TDX is not used at all. > > > > 2) The TDX module design allows it to be updated while the system is > > running. The update procedure shares quite a few steps with this "on > > demand" initialization mechanism. The hope is that much of "on demand" > > mechanism can be shared with a future "update" mechanism. A boot-time > > TDX module implementation would not be able to share much code with the > > update mechanism. > > > > 3) Making SEAMCALL requires VMX to be enabled. Currently, only the KVM > > code mucks with VMX enabling. If the TDX module were to be initialized > > separately from KVM (like at boot), the boot code would need to be > > taught how to muck with VMX enabling and KVM would need to be taught how > > to cope with that. Making KVM itself responsible for TDX initialization > > lets the rest of the kernel stay blissfully unaware of VMX. > > > > Similar to module initialization, also make the per-cpu initialization > > "on demand" as it also depends on VMX being enabled. > > > > Add two functions, tdx_enable() and tdx_cpu_enable(), to enable the TDX > > module and enable TDX on local cpu respectively. For now tdx_enable() > > is a placeholder. The TODO list will be pared down as functionality is > > added. > > > > Export both tdx_cpu_enable() and tdx_enable() for KVM use. > > > > In tdx_enable() use a state machine protected by mutex to make sure the > > initialization will only be done once, as tdx_enable() can be called > > multiple times (i.e. KVM module can be reloaded) and may be called > > concurrently by other kernel components in the future. > > > > The per-cpu initialization on each cpu can only be done once during the > > module's life time. Use a per-cpu variable to track its status to make > > sure it is only done once in tdx_cpu_enable(). > > > > Also, a SEAMCALL to do TDX module global initialization must be done > > once on any logical cpu before any per-cpu initialization SEAMCALL. Do > > it inside tdx_cpu_enable() too (if hasn't been done). > > > > tdx_enable() can potentially invoke SEAMCALLs on any online cpus. The > > per-cpu initialization must be done before those SEAMCALLs are invoked > > on some cpu. To keep things simple, in tdx_cpu_enable(), always do the > > per-cpu initialization regardless of whether the TDX module has been > > initialized or not. And in tdx_enable(), don't call tdx_cpu_enable() > > but assume the caller has disabled CPU hotplug, done VMXON and > > tdx_cpu_enable() on all online cpus before calling tdx_enable(). > > > > Signed-off-by: Kai Huang <kai.huang@xxxxxxxxx> > > Reviewed-by: Kirill A. Shutemov <kirill.shutemov@xxxxxxxxxxxxxxx> > > > With the latest explanation from Kai : > > Reviewed-by: Nikolay Borisov <nik.borisov@xxxxxxxx> Thanks!
