On Fri, 2023-06-30 at 11:25 +0200, Peter Zijlstra wrote: > On Thu, Jun 29, 2023 at 12:00:44AM +0000, Huang, Kai wrote: > > > The spec says it doesn't have a latency requirement, so theoretically it could > > be long. SEAMCALL is a VMEXIT so it would at least cost thousands of cycles. > > :-( > > > If raw_spinlock isn't desired, I think I can introduce another function to do > > this and let the caller to call it before calling tdx_cpu_enable(). E.g., we > > can have below functions: > > > > 1) tdx_global_init() -> TDH_SYS_INIT > > 2) tdx_cpu_init() -> TDH_SYS_LP_INIT > > 3) tdx_enable() -> actual module initialization > > > > How does this sound? > > Ah, wait, I hadn't had enough wake-up juice, it's tdx_global_init() that > did the raw_spinlock_t, but that isn't the IPI thing. > > Then perhaps just use a mutex to serialize things? > In the current code yes TDH_SYS_INIT is protected by raw_spinlock_t, because it is done in tdx_cpu_enable(). I thought this makes the caller (KVM)'s life easier as it doesn't have to call an additional tdx_global_init(). If we put TDH_SYS_INIT to an additional tdx_global_init(), then we are essentially asking the caller to guarantee it must be called before calling any tdx_cpu_enable() (or tdx_cpu_init() for better naming). But in this case we don't need the raw_spinlock anymore because it's caller's responsibility now. They both are not protected by the TDX module initialization mutex, only tdx_enable() is. The caller (KVM) is supposed to call tdx_cpu_enable() for all online cpus via IPI function call before calling tdx_enable(). So if using raw_spinlock_t around TDH_SYS_INIT is a concern, then we can go with the dedicated tdx_global_init() function option. Hope I've explained this clearly.
