Hi, For certain kinds of tasks we might need a quiescent state to perform an operation safely. Quiescent state means no CPU thread executing, and probably BQL held as well. The tasks could include: - Translation buffer flush (user and system-mode) - Cross-CPU TLB flush (system-mode) - Exclusive operation emulation (user-mode)
If we use a single shared translation buffer which is not managed by RCU and simply flushed when full, we'll need a quiescent state to flush it safely. In multi-threaded TCG, cross-CPU TLB flush from TCG helpers could probably be made with async_run_on_cpu(). I suppose it is always the guest system that needs to synchronise this operation properly. And as soon as we request the target CPU to exit its execution loop for serving the asynchronous work, we should probably be okay to continue execution on the CPU requested the operation while the target CPU executing till the end of its current TB before it actually flushed its TLB. As of slow-path LL/SC emulation in multi-threaded TCG, cross-CPU TLB flushes (actually TLB flushes on all CPUs) must me done synchronously and thus might require quiescent state. Exclusive operation emulation in user-mode is currently implemented in this manner, see for start_exclusive(). It might change to some generic mechanism of atomic/exclusive instruction emulation for system and user-mode. It looks like we need to implement a common mechanism to perform safe work in a quiescent state which could work in both system and user-mode, at least for safe translation bufferflush in user-mode and MTTCG. I'm going to implement such a mechanism. I would appreciate any suggestions, comments and remarks. Thanks, Sergey
