Messages in this thread | | | From | "Huang, Kai" <> | Subject | Re: [PATCH v12 07/22] x86/virt/tdx: Add skeleton to enable TDX on demand | Date | Fri, 30 Jun 2023 09:48:23 +0000 |
| |
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.
| |