On Mon, 2024-08-19 at 18:09 +0300, Nikolay Borisov wrote: > > +/* > > + * Some SEAMCALLs acquire the TDX module globally, and can fail with > > + * TDX_OPERAND_BUSY. Use a global mutex to serialize these SEAMCALLs. > > + */ > > +static DEFINE_MUTEX(tdx_lock); > > The way this lock is used is very ugly. So it essentially mimics a lock > which already lives in the tdx module. So why not simply gracefully > handle the TDX_OPERAND_BUSY return value or change the interface of the > module (yeah, it's probably late for this now) so expose the lock. This > lock breaks one of the main rules of locking - "Lock data and not code" Hmm, we would have to make SEAMCALLs to spin on that lock, where as mutexes can sleep. I suspect that is where it came from. But we are trying to make the code simple and obviously correct and add optimizations later. This might fit that pattern, especially since it is just used during VM creation and teardown.
