From 9ac3788b0be368e2826a8e9adadc1ada87d89273 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= Date: Thu, 6 Dec 2018 00:37:33 +0400 Subject: char: add a QEMU_CHAR_FEATURE_GCONTEXT flag MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit QEMU_CHAR_FEATURE_GCONTEXT declares the character device can switch GMainContext. Assert we don't switch context when the character device doesn't provide this feature. Character device users must not violate this restriction. In particular, user configurations that violate them must be rejected. Existing frontend that rely on context switching would now assert() if the backend doesn't allow it (instead of silently producing undesired events in the default context). Following patches improve the situation by reporting an error earlier instead, on the frontend side. Signed-off-by: Marc-André Lureau Message-Id: <20181205203737.9011-4-marcandre.lureau@redhat.com> Signed-off-by: Markus Armbruster --- include/chardev/char.h | 3 +++ 1 file changed, 3 insertions(+) (limited to 'include') diff --git a/include/chardev/char.h b/include/chardev/char.h index 7becd8c..014566c 100644 --- a/include/chardev/char.h +++ b/include/chardev/char.h @@ -47,6 +47,9 @@ typedef enum { QEMU_CHAR_FEATURE_FD_PASS, /* Whether replay or record mode is enabled */ QEMU_CHAR_FEATURE_REPLAY, + /* Whether the gcontext can be changed after calling + * qemu_chr_be_update_read_handlers() */ + QEMU_CHAR_FEATURE_GCONTEXT, QEMU_CHAR_FEATURE_LAST, } ChardevFeature; -- cgit v1.1 From 9ab84470ffc2781df3acd4607bc6d2ae64d6d7e3 Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Tue, 9 Oct 2018 14:27:13 +0800 Subject: monitor: Suspend monitor instead dropping commands MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit When a QMP client sends in-band commands more quickly that we can process them, we can either queue them without limit (QUEUE), drop commands when the queue is full (DROP), or suspend receiving commands when the queue is full (SUSPEND). None of them is ideal: * QUEUE lets a misbehaving client make QEMU eat memory without bounds. Not such a hot idea. * With DROP, the client has to cope with dropped in-band commands. To inform the client, we send a COMMAND_DROPPED event then. The event is flawed by design in two ways: it's ambiguous (see commit d621cfe0a17), and it brings back the "eat memory without bounds" problem. * With SUSPEND, the client has to manage the flow of in-band commands to keep the monitor available for out-of-band commands. We currently DROP. Switch to SUSPEND. Managing the flow of in-band commands to keep the monitor available for out-of-band commands isn't really hard: just count the number of "outstanding" in-band commands (commands sent minus replies received), and if it exceeds the limit, hold back additional ones until it drops below the limit again. Note that we need to be careful pairing the suspend with a resume, or else the monitor will hang, possibly forever. And here since we need to make sure both: (1) popping request from the req queue, and (2) reading length of the req queue will be in the same critical section, we let the pop function take the corresponding queue lock when there is a request, then we release the lock from the caller. Reviewed-by: Marc-André Lureau Signed-off-by: Peter Xu Message-Id: <20181009062718.1914-2-peterx@redhat.com> Signed-off-by: Markus Armbruster --- include/monitor/monitor.h | 2 ++ 1 file changed, 2 insertions(+) (limited to 'include') diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h index 6fd2c53..0c0a37d 100644 --- a/include/monitor/monitor.h +++ b/include/monitor/monitor.h @@ -15,6 +15,8 @@ extern __thread Monitor *cur_mon; #define MONITOR_USE_PRETTY 0x08 #define MONITOR_USE_OOB 0x10 +#define QMP_REQ_QUEUE_LEN_MAX 8 + bool monitor_cur_is_qmp(void); void monitor_init_globals(void); -- cgit v1.1 From 8258292e18c39480b64eba9f3551ab772ce29b5d Mon Sep 17 00:00:00 2001 From: Peter Xu Date: Tue, 9 Oct 2018 14:27:15 +0800 Subject: monitor: Remove "x-oob", offer capability "oob" unconditionally MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Out-of-band command execution was introduced in commit cf869d53172. Unfortunately, we ran into a regression, and had to turn it into an experimental option for 2.12 (commit be933ffc23). http://lists.gnu.org/archive/html/qemu-devel/2018-03/msg06231.html The regression has since been fixed (commit 951702f39c7 "monitor: bind dispatch bh to iohandler context"). A thorough re-review of OOB commands led to a few more issues, which have also been addressed. This patch partly reverts be933ffc23 (monitor: new parameter "x-oob"), and makes QMP monitors again offer capability "oob" whenever they can provide it, i.e. when the monitor's character device is capable of running in an I/O thread. Some trivial touch-up in the test code is required to make sure qmp-test won't break. Reviewed-by: Markus Armbruster Reviewed-by: Marc-André Lureau Signed-off-by: Peter Xu Message-Id: <20181009062718.1914-4-peterx@redhat.com> [Conflict with "monitor: check if chardev can switch gcontext for OOB" resolved, commit message updated] Signed-off-by: Markus Armbruster --- include/monitor/monitor.h | 1 - 1 file changed, 1 deletion(-) (limited to 'include') diff --git a/include/monitor/monitor.h b/include/monitor/monitor.h index 0c0a37d..c1b40a9 100644 --- a/include/monitor/monitor.h +++ b/include/monitor/monitor.h @@ -13,7 +13,6 @@ extern __thread Monitor *cur_mon; #define MONITOR_USE_READLINE 0x02 #define MONITOR_USE_CONTROL 0x04 #define MONITOR_USE_PRETTY 0x08 -#define MONITOR_USE_OOB 0x10 #define QMP_REQ_QUEUE_LEN_MAX 8 -- cgit v1.1