| Message ID | 20200528153742.274164-7-kwolf@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | monitor: Optionally run handlers in coroutines | expand |
On 5/28/20 10:37 AM, Kevin Wolf wrote: > This way, a monitor command handler will still be able to access the > current monitor, but when it yields, all other code code will correctly > get NULL from monitor_cur(). > > Outside of coroutine context, qemu_coroutine_self() returns the leader > coroutine of the current thread. > > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > --- Reviewed-by: Eric Blake <eblake@redhat.com>
Kevin Wolf <kwolf@redhat.com> writes: > This way, a monitor command handler will still be able to access the > current monitor, but when it yields, all other code code will correctly > get NULL from monitor_cur(). > > Outside of coroutine context, qemu_coroutine_self() returns the leader > coroutine of the current thread. Unsaid: you use it as a hash table key to map from coroutine to monitor, and for that you need it to return a value unique to the coroutine in coroutine context, and a value unique to the thread outside coroutine context. Which qemu_coroutine_self() does. Correct? The hash table works, but I hate it just as much as I hate pthread_getspecific() / pthread_setspecific(). What we have here is a need for coroutine-local data. Feels like a perfectly natural concept to me. Are we going to create another hash table whenever we need another piece of coroutine-local data? Or shall we reuse the hash table, suitably renamed and moved to another file? Why not simply associate an opaque pointer with each coroutine? All it takes is one more member of struct Coroutine. Whatever creates the coroutine decides what to use it for. The monitor coroutine would use it to point to the monitor. At least, discuss the design alternatives in the commit message. > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > --- > include/monitor/monitor.h | 2 +- > monitor/hmp.c | 4 ++-- > monitor/monitor.c | 27 +++++++++++++++++++++------ > qapi/qmp-dispatch.c | 4 ++-- > stubs/monitor-core.c | 2 +- > 5 files changed, 27 insertions(+), 12 deletions(-) > > diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h > index 43cc746078..16072e325c 100644 > --- a/include/monitor/monitor.h > +++ b/include/monitor/monitor.h > @@ -13,7 +13,7 @@ typedef struct MonitorOptions MonitorOptions; > extern QemuOptsList qemu_mon_opts; > > Monitor *monitor_cur(void); > -void monitor_set_cur(Monitor *mon); > +void monitor_set_cur(Coroutine *co, Monitor *mon); > bool monitor_cur_is_qmp(void); > > void monitor_init_globals(void); > diff --git a/monitor/hmp.c b/monitor/hmp.c > index 79be6f26de..3e73a4c3ce 100644 > --- a/monitor/hmp.c > +++ b/monitor/hmp.c > @@ -1082,9 +1082,9 @@ void handle_hmp_command(MonitorHMP *mon, const char *cmdline) > > /* old_mon is non-NULL when called from qmp_human_monitor_command() */ > old_mon = monitor_cur(); > - monitor_set_cur(&mon->common); > + monitor_set_cur(qemu_coroutine_self(), &mon->common); > cmd->cmd(&mon->common, qdict); > - monitor_set_cur(old_mon); > + monitor_set_cur(qemu_coroutine_self(), old_mon); > > qobject_unref(qdict); > } > diff --git a/monitor/monitor.c b/monitor/monitor.c > index 182ba136b4..35003bb486 100644 > --- a/monitor/monitor.c > +++ b/monitor/monitor.c > @@ -58,24 +58,38 @@ IOThread *mon_iothread; > /* Bottom half to dispatch the requests received from I/O thread */ > QEMUBH *qmp_dispatcher_bh; > > -/* Protects mon_list, monitor_qapi_event_state, monitor_destroyed. */ > +/* > + * Protects mon_list, monitor_qapi_event_state, coroutine_mon, > + * monitor_destroyed. > + */ > QemuMutex monitor_lock; > static GHashTable *monitor_qapi_event_state; > +static GHashTable *coroutine_mon; /* Maps Coroutine* to Monitor* */ > > MonitorList mon_list; > int mon_refcount; > static bool monitor_destroyed; > > -static __thread Monitor *cur_monitor; > - > Monitor *monitor_cur(void) > { > - return cur_monitor; > + Monitor *mon; > + > + qemu_mutex_lock(&monitor_lock); > + mon = g_hash_table_lookup(coroutine_mon, qemu_coroutine_self()); > + qemu_mutex_unlock(&monitor_lock); > + > + return mon; > } > > -void monitor_set_cur(Monitor *mon) > +void monitor_set_cur(Coroutine *co, Monitor *mon) > { > - cur_monitor = mon; > + qemu_mutex_lock(&monitor_lock); > + if (mon) { > + g_hash_table_replace(coroutine_mon, co, mon); > + } else { > + g_hash_table_remove(coroutine_mon, co); > + } > + qemu_mutex_unlock(&monitor_lock); > } You really need a contract now: any call to monitor_set_cur() with a non-null @mon must be followed by a call with a null @mon. > > /** > @@ -613,6 +627,7 @@ void monitor_init_globals_core(void) > { > monitor_qapi_event_init(); > qemu_mutex_init(&monitor_lock); > + coroutine_mon = g_hash_table_new(NULL, NULL); > > /* > * The dispatcher BH must run in the main loop thread, since we > diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c > index 2fdbc0fba4..5677ba92ca 100644 > --- a/qapi/qmp-dispatch.c > +++ b/qapi/qmp-dispatch.c > @@ -154,11 +154,11 @@ QDict *qmp_dispatch(const QmpCommandList *cmds, QObject *request, > } > > assert(monitor_cur() == NULL); > - monitor_set_cur(cur_mon); > + monitor_set_cur(qemu_coroutine_self(), cur_mon); > > cmd->fn(args, &ret, &err); > > - monitor_set_cur(NULL); > + monitor_set_cur(qemu_coroutine_self(), NULL); > qobject_unref(args); > if (err) { > /* or assert(!ret) after reviewing all handlers: */ > diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c > index e493df1027..635e37a6ba 100644 > --- a/stubs/monitor-core.c > +++ b/stubs/monitor-core.c > @@ -8,7 +8,7 @@ Monitor *monitor_cur(void) > return NULL; > } > > -void monitor_set_cur(Monitor *mon) > +void monitor_set_cur(Coroutine *co, Monitor *mon) > { > }
Am 04.08.2020 um 15:50 hat Markus Armbruster geschrieben: > Kevin Wolf <kwolf@redhat.com> writes: > > > This way, a monitor command handler will still be able to access the > > current monitor, but when it yields, all other code code will correctly > > get NULL from monitor_cur(). > > > > Outside of coroutine context, qemu_coroutine_self() returns the leader > > coroutine of the current thread. > > Unsaid: you use it as a hash table key to map from coroutine to monitor, > and for that you need it to return a value unique to the coroutine in > coroutine context, and a value unique to the thread outside coroutine > context. Which qemu_coroutine_self() does. Correct? Correct. > The hash table works, but I hate it just as much as I hate > pthread_getspecific() / pthread_setspecific(). > > What we have here is a need for coroutine-local data. Feels like a > perfectly natural concept to me. If you have a good concept how to implement this in a generic way that doesn't impact the I/O fast path, feel free to implement it and I'll happily use it. But the hash table is simple and works for this use case, so I see little reason to invest a lot of time in something that we haven't ever had another user for. > Are we going to create another hash table whenever we need another piece > of coroutine-local data? Or shall we reuse the hash table, suitably > renamed and moved to another file? I think I would vote for separate hash tables rather than having a hash table containing a struct that mixes values from all subsystems, but this can be discussed when (if) the need arises. > Why not simply associate an opaque pointer with each coroutine? All it > takes is one more member of struct Coroutine. Whatever creates the > coroutine decides what to use it for. The monitor coroutine would use > it to point to the monitor. This doesn't work. error_report() is called from all kinds of coroutines, not just from coroutines created from the monitor, and it wants to know the current monitor. > At least, discuss the design alternatives in the commit message. *sigh* Fine. Tell me which set of alternatives to discuss. > > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > > --- > > include/monitor/monitor.h | 2 +- > > monitor/hmp.c | 4 ++-- > > monitor/monitor.c | 27 +++++++++++++++++++++------ > > qapi/qmp-dispatch.c | 4 ++-- > > stubs/monitor-core.c | 2 +- > > 5 files changed, 27 insertions(+), 12 deletions(-) > > > > diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h > > index 43cc746078..16072e325c 100644 > > --- a/include/monitor/monitor.h > > +++ b/include/monitor/monitor.h > > @@ -13,7 +13,7 @@ typedef struct MonitorOptions MonitorOptions; > > extern QemuOptsList qemu_mon_opts; > > > > Monitor *monitor_cur(void); > > -void monitor_set_cur(Monitor *mon); > > +void monitor_set_cur(Coroutine *co, Monitor *mon); > > bool monitor_cur_is_qmp(void); > > > > void monitor_init_globals(void); > > diff --git a/monitor/hmp.c b/monitor/hmp.c > > index 79be6f26de..3e73a4c3ce 100644 > > --- a/monitor/hmp.c > > +++ b/monitor/hmp.c > > @@ -1082,9 +1082,9 @@ void handle_hmp_command(MonitorHMP *mon, const char *cmdline) > > > > /* old_mon is non-NULL when called from qmp_human_monitor_command() */ > > old_mon = monitor_cur(); > > - monitor_set_cur(&mon->common); > > + monitor_set_cur(qemu_coroutine_self(), &mon->common); > > cmd->cmd(&mon->common, qdict); > > - monitor_set_cur(old_mon); > > + monitor_set_cur(qemu_coroutine_self(), old_mon); > > > > qobject_unref(qdict); > > } > > diff --git a/monitor/monitor.c b/monitor/monitor.c > > index 182ba136b4..35003bb486 100644 > > --- a/monitor/monitor.c > > +++ b/monitor/monitor.c > > @@ -58,24 +58,38 @@ IOThread *mon_iothread; > > /* Bottom half to dispatch the requests received from I/O thread */ > > QEMUBH *qmp_dispatcher_bh; > > > > -/* Protects mon_list, monitor_qapi_event_state, monitor_destroyed. */ > > +/* > > + * Protects mon_list, monitor_qapi_event_state, coroutine_mon, > > + * monitor_destroyed. > > + */ > > QemuMutex monitor_lock; > > static GHashTable *monitor_qapi_event_state; > > +static GHashTable *coroutine_mon; /* Maps Coroutine* to Monitor* */ > > > > MonitorList mon_list; > > int mon_refcount; > > static bool monitor_destroyed; > > > > -static __thread Monitor *cur_monitor; > > - > > Monitor *monitor_cur(void) > > { > > - return cur_monitor; > > + Monitor *mon; > > + > > + qemu_mutex_lock(&monitor_lock); > > + mon = g_hash_table_lookup(coroutine_mon, qemu_coroutine_self()); > > + qemu_mutex_unlock(&monitor_lock); > > + > > + return mon; > > } > > > > -void monitor_set_cur(Monitor *mon) > > +void monitor_set_cur(Coroutine *co, Monitor *mon) > > { > > - cur_monitor = mon; > > + qemu_mutex_lock(&monitor_lock); > > + if (mon) { > > + g_hash_table_replace(coroutine_mon, co, mon); > > + } else { > > + g_hash_table_remove(coroutine_mon, co); > > + } > > + qemu_mutex_unlock(&monitor_lock); > > } > > You really need a contract now: any call to monitor_set_cur() with a > non-null @mon must be followed by a call with a null @mon. Why? g_hash_table_replace() removes the old value and replaces it with the new one. Kevin
On Tue, Aug 04, 2020 at 03:50:54PM +0200, Markus Armbruster wrote: > Kevin Wolf <kwolf@redhat.com> writes: > > > This way, a monitor command handler will still be able to access the > > current monitor, but when it yields, all other code code will correctly > > get NULL from monitor_cur(). > > > > Outside of coroutine context, qemu_coroutine_self() returns the leader > > coroutine of the current thread. > > Unsaid: you use it as a hash table key to map from coroutine to monitor, > and for that you need it to return a value unique to the coroutine in > coroutine context, and a value unique to the thread outside coroutine > context. Which qemu_coroutine_self() does. Correct? > > The hash table works, but I hate it just as much as I hate > pthread_getspecific() / pthread_setspecific(). > > What we have here is a need for coroutine-local data. Feels like a > perfectly natural concept to me. > > Are we going to create another hash table whenever we need another piece > of coroutine-local data? Or shall we reuse the hash table, suitably > renamed and moved to another file? > > Why not simply associate an opaque pointer with each coroutine? All it > takes is one more member of struct Coroutine. Whatever creates the > coroutine decides what to use it for. The monitor coroutine would use > it to point to the monitor. Possible benefit of having the coroutine-local data stored in the coroutine stack is that we can probably make it lock-less. Using the hash table in monitor.c results in a serialization of across all coroutines & threads. Also, by providing a GDestroyNotify against the coroutine-local data we can easily guarantee cleanup with the coroutine is freed. Since we'll have a limited number of data items, we could make do with a simple array in the coroutine struct, instead of a hashtable. eg enum CoroutineLocalKeys { CO_LOCAL_CUR_MONITOR = 0, CO_LOCAL_LAST, }; struct Coroutine { ... gpointer localData[CO_LOCAL_LAST]; GDestroyNotify localDataFree[CO_LOCAL_LAST]; }; Regards, Daniel
Kevin Wolf <kwolf@redhat.com> writes: > Am 04.08.2020 um 15:50 hat Markus Armbruster geschrieben: >> Kevin Wolf <kwolf@redhat.com> writes: >> >> > This way, a monitor command handler will still be able to access the >> > current monitor, but when it yields, all other code code will correctly >> > get NULL from monitor_cur(). >> > >> > Outside of coroutine context, qemu_coroutine_self() returns the leader >> > coroutine of the current thread. >> >> Unsaid: you use it as a hash table key to map from coroutine to monitor, >> and for that you need it to return a value unique to the coroutine in >> coroutine context, and a value unique to the thread outside coroutine >> context. Which qemu_coroutine_self() does. Correct? > > Correct. > >> The hash table works, but I hate it just as much as I hate >> pthread_getspecific() / pthread_setspecific(). >> >> What we have here is a need for coroutine-local data. Feels like a >> perfectly natural concept to me. > > If you have a good concept how to implement this in a generic way that > doesn't impact the I/O fast path, feel free to implement it and I'll > happily use it. Fair enough; I'll give it a shot. > But the hash table is simple and works for this use case, so I see > little reason to invest a lot of time in something that we haven't ever > had another user for. > >> Are we going to create another hash table whenever we need another piece >> of coroutine-local data? Or shall we reuse the hash table, suitably >> renamed and moved to another file? > > I think I would vote for separate hash tables rather than having a hash > table containing a struct that mixes values from all subsystems, but > this can be discussed when (if) the need arises. > >> Why not simply associate an opaque pointer with each coroutine? All it >> takes is one more member of struct Coroutine. Whatever creates the >> coroutine decides what to use it for. The monitor coroutine would use >> it to point to the monitor. > > This doesn't work. error_report() is called from all kinds of > coroutines, not just from coroutines created from the monitor, and it > wants to know the current monitor. Yup, monitor_cur() and monitor_set_cur() need to work both in coroutine context and outside coroutine context. >> At least, discuss the design alternatives in the commit message. > > *sigh* Fine. Tell me which set of alternatives to discuss. Let me first play with the alternative I suggested. >> > Signed-off-by: Kevin Wolf <kwolf@redhat.com> >> > --- >> > include/monitor/monitor.h | 2 +- >> > monitor/hmp.c | 4 ++-- >> > monitor/monitor.c | 27 +++++++++++++++++++++------ >> > qapi/qmp-dispatch.c | 4 ++-- >> > stubs/monitor-core.c | 2 +- >> > 5 files changed, 27 insertions(+), 12 deletions(-) >> > >> > diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h >> > index 43cc746078..16072e325c 100644 >> > --- a/include/monitor/monitor.h >> > +++ b/include/monitor/monitor.h >> > @@ -13,7 +13,7 @@ typedef struct MonitorOptions MonitorOptions; >> > extern QemuOptsList qemu_mon_opts; >> > >> > Monitor *monitor_cur(void); >> > -void monitor_set_cur(Monitor *mon); >> > +void monitor_set_cur(Coroutine *co, Monitor *mon); >> > bool monitor_cur_is_qmp(void); >> > >> > void monitor_init_globals(void); >> > diff --git a/monitor/hmp.c b/monitor/hmp.c >> > index 79be6f26de..3e73a4c3ce 100644 >> > --- a/monitor/hmp.c >> > +++ b/monitor/hmp.c >> > @@ -1082,9 +1082,9 @@ void handle_hmp_command(MonitorHMP *mon, const char *cmdline) >> > >> > /* old_mon is non-NULL when called from qmp_human_monitor_command() */ >> > old_mon = monitor_cur(); >> > - monitor_set_cur(&mon->common); >> > + monitor_set_cur(qemu_coroutine_self(), &mon->common); >> > cmd->cmd(&mon->common, qdict); >> > - monitor_set_cur(old_mon); >> > + monitor_set_cur(qemu_coroutine_self(), old_mon); >> > >> > qobject_unref(qdict); >> > } >> > diff --git a/monitor/monitor.c b/monitor/monitor.c >> > index 182ba136b4..35003bb486 100644 >> > --- a/monitor/monitor.c >> > +++ b/monitor/monitor.c >> > @@ -58,24 +58,38 @@ IOThread *mon_iothread; >> > /* Bottom half to dispatch the requests received from I/O thread */ >> > QEMUBH *qmp_dispatcher_bh; >> > >> > -/* Protects mon_list, monitor_qapi_event_state, monitor_destroyed. */ >> > +/* >> > + * Protects mon_list, monitor_qapi_event_state, coroutine_mon, >> > + * monitor_destroyed. >> > + */ >> > QemuMutex monitor_lock; >> > static GHashTable *monitor_qapi_event_state; >> > +static GHashTable *coroutine_mon; /* Maps Coroutine* to Monitor* */ >> > >> > MonitorList mon_list; >> > int mon_refcount; >> > static bool monitor_destroyed; >> > >> > -static __thread Monitor *cur_monitor; >> > - >> > Monitor *monitor_cur(void) >> > { >> > - return cur_monitor; >> > + Monitor *mon; >> > + >> > + qemu_mutex_lock(&monitor_lock); >> > + mon = g_hash_table_lookup(coroutine_mon, qemu_coroutine_self()); >> > + qemu_mutex_unlock(&monitor_lock); >> > + >> > + return mon; >> > } >> > >> > -void monitor_set_cur(Monitor *mon) >> > +void monitor_set_cur(Coroutine *co, Monitor *mon) >> > { >> > - cur_monitor = mon; >> > + qemu_mutex_lock(&monitor_lock); >> > + if (mon) { >> > + g_hash_table_replace(coroutine_mon, co, mon); >> > + } else { >> > + g_hash_table_remove(coroutine_mon, co); >> > + } >> > + qemu_mutex_unlock(&monitor_lock); >> > } >> >> You really need a contract now: any call to monitor_set_cur() with a >> non-null @mon must be followed by a call with a null @mon. > > Why? g_hash_table_replace() removes the old value and replaces it with > the new one. If you monitor_set_cur(NULL) is forgotten or bypassed somehow, the hash table entry stays even when the coroutine dies. Minor memory leak. If another coroutine gets created at the same address, it "inherits" the current monitor. Not good. If the monitor has died meanwhile, dangling pointer. Fortunately, monitors die only during shutdown, except for the dummy in qmp_human_monitor_command().
Am 05.08.2020 um 09:28 hat Markus Armbruster geschrieben: > Kevin Wolf <kwolf@redhat.com> writes: > > > Am 04.08.2020 um 15:50 hat Markus Armbruster geschrieben: > >> Kevin Wolf <kwolf@redhat.com> writes: > >> > >> > This way, a monitor command handler will still be able to access the > >> > current monitor, but when it yields, all other code code will correctly > >> > get NULL from monitor_cur(). > >> > > >> > Outside of coroutine context, qemu_coroutine_self() returns the leader > >> > coroutine of the current thread. > >> > >> Unsaid: you use it as a hash table key to map from coroutine to monitor, > >> and for that you need it to return a value unique to the coroutine in > >> coroutine context, and a value unique to the thread outside coroutine > >> context. Which qemu_coroutine_self() does. Correct? > > > > Correct. > > > >> The hash table works, but I hate it just as much as I hate > >> pthread_getspecific() / pthread_setspecific(). > >> > >> What we have here is a need for coroutine-local data. Feels like a > >> perfectly natural concept to me. > > > > If you have a good concept how to implement this in a generic way that > > doesn't impact the I/O fast path, feel free to implement it and I'll > > happily use it. > > Fair enough; I'll give it a shot. > > > But the hash table is simple and works for this use case, so I see > > little reason to invest a lot of time in something that we haven't ever > > had another user for. > > > >> Are we going to create another hash table whenever we need another piece > >> of coroutine-local data? Or shall we reuse the hash table, suitably > >> renamed and moved to another file? > > > > I think I would vote for separate hash tables rather than having a hash > > table containing a struct that mixes values from all subsystems, but > > this can be discussed when (if) the need arises. > > > >> Why not simply associate an opaque pointer with each coroutine? All it > >> takes is one more member of struct Coroutine. Whatever creates the > >> coroutine decides what to use it for. The monitor coroutine would use > >> it to point to the monitor. > > > > This doesn't work. error_report() is called from all kinds of > > coroutines, not just from coroutines created from the monitor, and it > > wants to know the current monitor. > > Yup, monitor_cur() and monitor_set_cur() need to work both in coroutine > context and outside coroutine context. And in coroutine contexts, but in coroutine created by someone else than the monitor. > >> At least, discuss the design alternatives in the commit message. > > > > *sigh* Fine. Tell me which set of alternatives to discuss. > > Let me first play with the alternative I suggested. > > >> > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > >> > --- > >> > include/monitor/monitor.h | 2 +- > >> > monitor/hmp.c | 4 ++-- > >> > monitor/monitor.c | 27 +++++++++++++++++++++------ > >> > qapi/qmp-dispatch.c | 4 ++-- > >> > stubs/monitor-core.c | 2 +- > >> > 5 files changed, 27 insertions(+), 12 deletions(-) > >> > > >> > diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h > >> > index 43cc746078..16072e325c 100644 > >> > --- a/include/monitor/monitor.h > >> > +++ b/include/monitor/monitor.h > >> > @@ -13,7 +13,7 @@ typedef struct MonitorOptions MonitorOptions; > >> > extern QemuOptsList qemu_mon_opts; > >> > > >> > Monitor *monitor_cur(void); > >> > -void monitor_set_cur(Monitor *mon); > >> > +void monitor_set_cur(Coroutine *co, Monitor *mon); > >> > bool monitor_cur_is_qmp(void); > >> > > >> > void monitor_init_globals(void); > >> > diff --git a/monitor/hmp.c b/monitor/hmp.c > >> > index 79be6f26de..3e73a4c3ce 100644 > >> > --- a/monitor/hmp.c > >> > +++ b/monitor/hmp.c > >> > @@ -1082,9 +1082,9 @@ void handle_hmp_command(MonitorHMP *mon, const char *cmdline) > >> > > >> > /* old_mon is non-NULL when called from qmp_human_monitor_command() */ > >> > old_mon = monitor_cur(); > >> > - monitor_set_cur(&mon->common); > >> > + monitor_set_cur(qemu_coroutine_self(), &mon->common); > >> > cmd->cmd(&mon->common, qdict); > >> > - monitor_set_cur(old_mon); > >> > + monitor_set_cur(qemu_coroutine_self(), old_mon); > >> > > >> > qobject_unref(qdict); > >> > } > >> > diff --git a/monitor/monitor.c b/monitor/monitor.c > >> > index 182ba136b4..35003bb486 100644 > >> > --- a/monitor/monitor.c > >> > +++ b/monitor/monitor.c > >> > @@ -58,24 +58,38 @@ IOThread *mon_iothread; > >> > /* Bottom half to dispatch the requests received from I/O thread */ > >> > QEMUBH *qmp_dispatcher_bh; > >> > > >> > -/* Protects mon_list, monitor_qapi_event_state, monitor_destroyed. */ > >> > +/* > >> > + * Protects mon_list, monitor_qapi_event_state, coroutine_mon, > >> > + * monitor_destroyed. > >> > + */ > >> > QemuMutex monitor_lock; > >> > static GHashTable *monitor_qapi_event_state; > >> > +static GHashTable *coroutine_mon; /* Maps Coroutine* to Monitor* */ > >> > > >> > MonitorList mon_list; > >> > int mon_refcount; > >> > static bool monitor_destroyed; > >> > > >> > -static __thread Monitor *cur_monitor; > >> > - > >> > Monitor *monitor_cur(void) > >> > { > >> > - return cur_monitor; > >> > + Monitor *mon; > >> > + > >> > + qemu_mutex_lock(&monitor_lock); > >> > + mon = g_hash_table_lookup(coroutine_mon, qemu_coroutine_self()); > >> > + qemu_mutex_unlock(&monitor_lock); > >> > + > >> > + return mon; > >> > } > >> > > >> > -void monitor_set_cur(Monitor *mon) > >> > +void monitor_set_cur(Coroutine *co, Monitor *mon) > >> > { > >> > - cur_monitor = mon; > >> > + qemu_mutex_lock(&monitor_lock); > >> > + if (mon) { > >> > + g_hash_table_replace(coroutine_mon, co, mon); > >> > + } else { > >> > + g_hash_table_remove(coroutine_mon, co); > >> > + } > >> > + qemu_mutex_unlock(&monitor_lock); > >> > } > >> > >> You really need a contract now: any call to monitor_set_cur() with a > >> non-null @mon must be followed by a call with a null @mon. > > > > Why? g_hash_table_replace() removes the old value and replaces it with > > the new one. > > If you monitor_set_cur(NULL) is forgotten or bypassed somehow, the hash > table entry stays even when the coroutine dies. Minor memory leak. If > another coroutine gets created at the same address, it "inherits" the > current monitor. Not good. If the monitor has died meanwhile, dangling > pointer. Fortunately, monitors die only during shutdown, except for the > dummy in qmp_human_monitor_command(). Ah, yes, fair. I can document this. In practice not a problem because the QMP dispatcher coroutine and HMP command handler coroutines are the only places that set (and reset) it. In fact, HMP needs to be fixed to reset to NULL before the coroutine terminates. Kevin
I called for a discussion of design alternatives, because I dislike the
one I got. Here we go.
= Context: the "current monitor" =
Output of HMP commands needs to go to the HMP monitor executing the
command. Trivial in HMP command handlers: the handler function takes a
monitor argument. Not so trivial in code used both by HMP command
handlers and other users, such as CLI. In particular, passing the
monitor through multiple layers that don't want to know anything about
monitors to the point that reports an error just so we can make the
error report go where it needs to go would be impractical. We made
error_report() & friends do the right thing without such help.
To let them do that, we maintain a "current monitor".
Invariant: while executing a monitor command, thread-local variable
@cur_mon points to the monitor executing the command. When the
thread is not executing a monitor command, @cur_mon is null.
Now error_report() can do the right thing easily: print to @cur_mon if
non-null, else to stderr.
We also use @cur_mon for getting file descriptors stored in the monitor.
Could perhaps do without @cur_mon, but since it's there anyway...
= Problem at hand: "current monitor" for coroutine-enabled commands =
We want to be able to run monitor commands in a coroutine, so they can
yield instead of blocking the main loop.
Simply yielding in a monitor command violates the invariant: we're no
longer executing a monitor command[*], but @cur_mon is still non-null.
This is because the current monitor is no longer a property of the
thread, but a property of the coroutine. Thread-local variable @cur_mon
doesn't fit the bill anymore.
= Solution 1: A separate map coroutine -> current monitor =
Kevin implemented this, using a hash table.
PRO:
* Stays off the coroutine switch hot path (by staying off coroutine code
entirely).
CON
* It's a one-off (but at least it's confined to monitor.c)
* It's slow, and uses locks (but that's probably okay for this use; see
also one-off).
* We get to worry about consistency between coroutines and the hash
table.
While this looks servicable, I wonder whether we can we come up with
something a bit more elegant.
= Solution 2: Put the map into struct Coroutine =
The hash table can be replaced by putting a @cur_mon member right into
struct Coroutine, together with a setter and a getter function.
PRO
* Stays off the coroutine switch hot path.
CON
* It's a one off.
* HMP bleeds into the coroutine subsystem, which really doesn't want to
know anything about monitors.
Thanks, but no thanks.
= Solution 3: Put abstract maps into struct Coroutine =
Daniel's proposal: instead of putting a Monitor * member into struct
Coroutine, put an array of void * there, indexed by well-known data
keys. Initially, there is just one data key, for the current monitor.
This is basically pthread_setspecific(), pthread_getspecific() for
coroutines, with pthread_key_create() dumbed down to a static set of
well-known keys.
PRO
* Stays off the coroutine switch hot path.
* Similar to how thread-local storage works with traditional pthreads.
CON
* Similar to how thread-local storage works with traditional pthreads.
= Solution 4: Fixed coroutine-local storage =
Whereas solution 3 is like traditional pthreads, this solution works
more like __thread does under the hood: we allocate memory for
coroutine-local storage on coroutine creation, maintain a global pointer
on thread switch, and free the memory on destruction.
We can keep the global pointer in struct Coroutine, and have a getter
return it.
If accessing coroutine-local storage ever becomes a performance
bottleneck, we can either open-code the getter, or store the pointer in
thread-local storage (but then we need to update it in the coroutine
switch hot path). No need to worry about all that now.
Since we don't have compiler and linker support, we have to collect the
coroutine-local variables in a struct manually.
PRO
* Stays off the coroutine switch hot path.
* Access could be made quite fast if need be.
CON
* The struct of coroutine-local variable crosses subsystem boundaries.
= Solution 5: Optional coroutine-specific storage =
When creating a coroutine, you can optionally ask for a certain amount
of coroutine-specific memory. It's malloced, stored in struct
Coroutine, and freed when on deletion.
A getter returns the coroutine-specific memory. To actually use it, you
have to know the coroutine's coroutine-specific memory layout.
PRO
* Stays off the coroutine switch hot path.
* Access could be made quite fast if need be.
CON
* Having to know the coroutine's coroutine-specifc memory layout could
turn out to be impractical for some applications of "property of a
coroutine".
This is the solution I had in mind from the start. I have prototype
code that passes basic testing.
= Solution 6: Exploit there is just two coroutines involved =
A simpler solution is possible, but to understand it, you first have to
understand how the threads and coroutines work together. Let me
recapitulate.
In old QEMU, all monitors run in the main thread's main loop, and
together execute one command after the other. @cur_mon was a global
variable, to be accessed only by the main thread.
Commit 62aa1d887f "monitor: Fix unsafe sharing of @cur_mon among
threads" (v3.0.0) made @cur_mon thread-local. "Fix" was a bit of an
overstatement; no unsafe access was known.
The OOB work moved a part of the QMP monitor work from the main loop
into @mon_iothread. @mon_iothread sends commands to the main thread for
execution, except for commands executed "out-of-band".
This series moves the main thread's QMP command dispatch into coroutine
@qmp_dispatcher_co. Commands that aren't coroutine-capable get
dispatched to a one-shot bottom half, also in the main thread.
The series modifies the main thread's HMP command dispatch to wrap
execution of each coroutine-capable command in a newly created
coroutine.
We have:
* OOB commands running in @mon_iothread, outside coroutine context
* Coroutine-incapable QMP commands running in the main thread, outside
coroutine context (detail: in a bottom half)
* Coroutine-incapable HMP commands running in the main thread, outside
coroutine-incapable context
* Coroutine-capable QMP commands running in the main thread, in
coroutine @qmp_dispatcher_co
* Coroutine-capable HMP commands runnning in the main thread, in a
coroutine created just for the command
* At most one non-OOB command is executing at any time.
Let's ignore HMP for now. Observe:
* As long as there is just one @qmp_dispatcher_co, there is just one
current monitor for coroutine-capable QMP commands at any time. It
can therefore be stored in a simple global variable
@qmp_dispatcher_co_mon.
* For the coroutine-incapable commands, thread-local variable @cur_mon
suffices.
* If qemu_coroutine_self() == qmp_dispatcher_co, the current monitor is
@qmp_dispatcher_co_mon. Else it's @cur_mon.
To extend this to HMP, we have to make the handle_hmp_command()'s local
variable @co a global one.
PRO:
* Stays off the coroutine switch hot path (by staying off coroutine code
entirely).
* Simple code.
CON
* It's a one-off (but at least it's confined to monitor.c).
* The argument behind the code is less than simple (see above).
* Should our monitor coroutines multiply, say because we pull off
executing (some) in-band commands in monitor I/O thread(s), the
solution falls apart.
I have prototype code that passes basic testing.
Opinions?
I'll post my two prototypes shortly.
[*] In theory, we could yield to a coroutine that is executing another
monitor's monitor command. In practice, we haven't implemented that.
diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h index 43cc746078..16072e325c 100644 --- a/include/monitor/monitor.h +++ b/include/monitor/monitor.h @@ -13,7 +13,7 @@ typedef struct MonitorOptions MonitorOptions; extern QemuOptsList qemu_mon_opts; Monitor *monitor_cur(void); -void monitor_set_cur(Monitor *mon); +void monitor_set_cur(Coroutine *co, Monitor *mon); bool monitor_cur_is_qmp(void); void monitor_init_globals(void); diff --git a/monitor/hmp.c b/monitor/hmp.c index 79be6f26de..3e73a4c3ce 100644 --- a/monitor/hmp.c +++ b/monitor/hmp.c @@ -1082,9 +1082,9 @@ void handle_hmp_command(MonitorHMP *mon, const char *cmdline) /* old_mon is non-NULL when called from qmp_human_monitor_command() */ old_mon = monitor_cur(); - monitor_set_cur(&mon->common); + monitor_set_cur(qemu_coroutine_self(), &mon->common); cmd->cmd(&mon->common, qdict); - monitor_set_cur(old_mon); + monitor_set_cur(qemu_coroutine_self(), old_mon); qobject_unref(qdict); } diff --git a/monitor/monitor.c b/monitor/monitor.c index 182ba136b4..35003bb486 100644 --- a/monitor/monitor.c +++ b/monitor/monitor.c @@ -58,24 +58,38 @@ IOThread *mon_iothread; /* Bottom half to dispatch the requests received from I/O thread */ QEMUBH *qmp_dispatcher_bh; -/* Protects mon_list, monitor_qapi_event_state, monitor_destroyed. */ +/* + * Protects mon_list, monitor_qapi_event_state, coroutine_mon, + * monitor_destroyed. + */ QemuMutex monitor_lock; static GHashTable *monitor_qapi_event_state; +static GHashTable *coroutine_mon; /* Maps Coroutine* to Monitor* */ MonitorList mon_list; int mon_refcount; static bool monitor_destroyed; -static __thread Monitor *cur_monitor; - Monitor *monitor_cur(void) { - return cur_monitor; + Monitor *mon; + + qemu_mutex_lock(&monitor_lock); + mon = g_hash_table_lookup(coroutine_mon, qemu_coroutine_self()); + qemu_mutex_unlock(&monitor_lock); + + return mon; } -void monitor_set_cur(Monitor *mon) +void monitor_set_cur(Coroutine *co, Monitor *mon) { - cur_monitor = mon; + qemu_mutex_lock(&monitor_lock); + if (mon) { + g_hash_table_replace(coroutine_mon, co, mon); + } else { + g_hash_table_remove(coroutine_mon, co); + } + qemu_mutex_unlock(&monitor_lock); } /** @@ -613,6 +627,7 @@ void monitor_init_globals_core(void) { monitor_qapi_event_init(); qemu_mutex_init(&monitor_lock); + coroutine_mon = g_hash_table_new(NULL, NULL); /* * The dispatcher BH must run in the main loop thread, since we diff --git a/qapi/qmp-dispatch.c b/qapi/qmp-dispatch.c index 2fdbc0fba4..5677ba92ca 100644 --- a/qapi/qmp-dispatch.c +++ b/qapi/qmp-dispatch.c @@ -154,11 +154,11 @@ QDict *qmp_dispatch(const QmpCommandList *cmds, QObject *request, } assert(monitor_cur() == NULL); - monitor_set_cur(cur_mon); + monitor_set_cur(qemu_coroutine_self(), cur_mon); cmd->fn(args, &ret, &err); - monitor_set_cur(NULL); + monitor_set_cur(qemu_coroutine_self(), NULL); qobject_unref(args); if (err) { /* or assert(!ret) after reviewing all handlers: */ diff --git a/stubs/monitor-core.c b/stubs/monitor-core.c index e493df1027..635e37a6ba 100644 --- a/stubs/monitor-core.c +++ b/stubs/monitor-core.c @@ -8,7 +8,7 @@ Monitor *monitor_cur(void) return NULL; } -void monitor_set_cur(Monitor *mon) +void monitor_set_cur(Coroutine *co, Monitor *mon) { }
This way, a monitor command handler will still be able to access the current monitor, but when it yields, all other code code will correctly get NULL from monitor_cur(). Outside of coroutine context, qemu_coroutine_self() returns the leader coroutine of the current thread. Signed-off-by: Kevin Wolf <kwolf@redhat.com> --- include/monitor/monitor.h | 2 +- monitor/hmp.c | 4 ++-- monitor/monitor.c | 27 +++++++++++++++++++++------ qapi/qmp-dispatch.c | 4 ++-- stubs/monitor-core.c | 2 +- 5 files changed, 27 insertions(+), 12 deletions(-)