2011-09-13 16:30:52 +08:00
|
|
|
/*
|
|
|
|
* QEMU System Emulator
|
|
|
|
*
|
|
|
|
* Copyright (c) 2003-2008 Fabrice Bellard
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
|
|
* of this software and associated documentation files (the "Software"), to deal
|
|
|
|
* in the Software without restriction, including without limitation the rights
|
|
|
|
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
|
|
* copies of the Software, and to permit persons to whom the Software is
|
|
|
|
* furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice shall be included in
|
|
|
|
* all copies or substantial portions of the Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
|
|
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
|
|
|
|
* THE SOFTWARE.
|
|
|
|
*/
|
|
|
|
|
2016-01-30 01:50:05 +08:00
|
|
|
#include "qemu/osdep.h"
|
include/qemu/osdep.h: Don't include qapi/error.h
Commit 57cb38b included qapi/error.h into qemu/osdep.h to get the
Error typedef. Since then, we've moved to include qemu/osdep.h
everywhere. Its file comment explains: "To avoid getting into
possible circular include dependencies, this file should not include
any other QEMU headers, with the exceptions of config-host.h,
compiler.h, os-posix.h and os-win32.h, all of which are doing a
similar job to this file and are under similar constraints."
qapi/error.h doesn't do a similar job, and it doesn't adhere to
similar constraints: it includes qapi-types.h. That's in excess of
100KiB of crap most .c files don't actually need.
Add the typedef to qemu/typedefs.h, and include that instead of
qapi/error.h. Include qapi/error.h in .c files that need it and don't
get it now. Include qapi-types.h in qom/object.h for uint16List.
Update scripts/clean-includes accordingly. Update it further to match
reality: replace config.h by config-target.h, add sysemu/os-posix.h,
sysemu/os-win32.h. Update the list of includes in the qemu/osdep.h
comment quoted above similarly.
This reduces the number of objects depending on qapi/error.h from "all
of them" to less than a third. Unfortunately, the number depending on
qapi-types.h shrinks only a little. More work is needed for that one.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
[Fix compilation without the spice devel packages. - Paolo]
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2016-03-14 16:01:28 +08:00
|
|
|
#include "qapi/error.h"
|
2016-03-21 01:16:19 +08:00
|
|
|
#include "qemu/cutils.h"
|
2012-12-18 01:20:00 +08:00
|
|
|
#include "qemu/timer.h"
|
2013-06-12 20:31:44 +08:00
|
|
|
#include "qemu/sockets.h" // struct in_addr needed for libslirp.h
|
2014-03-13 22:17:29 +08:00
|
|
|
#include "sysemu/qtest.h"
|
2017-03-03 19:01:16 +08:00
|
|
|
#include "sysemu/cpus.h"
|
2013-06-12 20:31:44 +08:00
|
|
|
#include "slirp/libslirp.h"
|
2012-12-18 01:20:00 +08:00
|
|
|
#include "qemu/main-loop.h"
|
2012-12-18 01:19:44 +08:00
|
|
|
#include "block/aio.h"
|
2011-09-13 16:30:52 +08:00
|
|
|
|
|
|
|
#ifndef _WIN32
|
|
|
|
|
|
|
|
/* If we have signalfd, we mask out the signals we want to handle and then
|
|
|
|
* use signalfd to listen for them. We rely on whatever the current signal
|
|
|
|
* handler is to dispatch the signals when we receive them.
|
|
|
|
*/
|
|
|
|
static void sigfd_handler(void *opaque)
|
|
|
|
{
|
|
|
|
int fd = (intptr_t)opaque;
|
|
|
|
struct qemu_signalfd_siginfo info;
|
|
|
|
struct sigaction action;
|
|
|
|
ssize_t len;
|
|
|
|
|
|
|
|
while (1) {
|
|
|
|
do {
|
|
|
|
len = read(fd, &info, sizeof(info));
|
|
|
|
} while (len == -1 && errno == EINTR);
|
|
|
|
|
|
|
|
if (len == -1 && errno == EAGAIN) {
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (len != sizeof(info)) {
|
|
|
|
printf("read from sigfd returned %zd: %m\n", len);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
sigaction(info.ssi_signo, NULL, &action);
|
|
|
|
if ((action.sa_flags & SA_SIGINFO) && action.sa_sigaction) {
|
2017-02-08 20:22:12 +08:00
|
|
|
sigaction_invoke(&action, &info);
|
2011-09-13 16:30:52 +08:00
|
|
|
} else if (action.sa_handler) {
|
|
|
|
action.sa_handler(info.ssi_signo);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static int qemu_signal_init(void)
|
|
|
|
{
|
|
|
|
int sigfd;
|
|
|
|
sigset_t set;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SIG_IPI must be blocked in the main thread and must not be caught
|
|
|
|
* by sigwait() in the signal thread. Otherwise, the cpu thread will
|
|
|
|
* not catch it reliably.
|
|
|
|
*/
|
|
|
|
sigemptyset(&set);
|
|
|
|
sigaddset(&set, SIG_IPI);
|
|
|
|
sigaddset(&set, SIGIO);
|
|
|
|
sigaddset(&set, SIGALRM);
|
|
|
|
sigaddset(&set, SIGBUS);
|
2014-10-27 22:13:02 +08:00
|
|
|
/* SIGINT cannot be handled via signalfd, so that ^C can be used
|
|
|
|
* to interrupt QEMU when it is being run under gdb. SIGHUP and
|
|
|
|
* SIGTERM are also handled asynchronously, even though it is not
|
|
|
|
* strictly necessary, because they use the same handler as SIGINT.
|
|
|
|
*/
|
2011-09-13 16:30:52 +08:00
|
|
|
pthread_sigmask(SIG_BLOCK, &set, NULL);
|
|
|
|
|
2012-01-12 17:05:35 +08:00
|
|
|
sigdelset(&set, SIG_IPI);
|
2011-09-13 16:30:52 +08:00
|
|
|
sigfd = qemu_signalfd(&set);
|
|
|
|
if (sigfd == -1) {
|
|
|
|
fprintf(stderr, "failed to create signalfd\n");
|
|
|
|
return -errno;
|
|
|
|
}
|
|
|
|
|
|
|
|
fcntl_setfl(sigfd, O_NONBLOCK);
|
|
|
|
|
Change qemu_set_fd_handler2(..., NULL, ...) to qemu_set_fd_handler
Done with following Coccinelle semantic patch, plus manual cosmetic changes in
net/*.c.
@@
expression E1, E2, E3, E4;
@@
- qemu_set_fd_handler2(E1, NULL, E2, E3, E4);
+ qemu_set_fd_handler(E1, E2, E3, E4);
Signed-off-by: Fam Zheng <famz@redhat.com>
Message-id: 1433400324-7358-8-git-send-email-famz@redhat.com
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
2015-06-04 14:45:18 +08:00
|
|
|
qemu_set_fd_handler(sigfd, sigfd_handler, NULL, (void *)(intptr_t)sigfd);
|
2011-09-13 16:30:52 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
#else /* _WIN32 */
|
|
|
|
|
2010-05-24 23:27:14 +08:00
|
|
|
static int qemu_signal_init(void)
|
2011-09-13 16:30:52 +08:00
|
|
|
{
|
|
|
|
return 0;
|
|
|
|
}
|
2010-05-24 23:27:14 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
static AioContext *qemu_aio_context;
|
2015-07-24 19:42:55 +08:00
|
|
|
static QEMUBH *qemu_notify_bh;
|
|
|
|
|
|
|
|
static void notify_event_cb(void *opaque)
|
|
|
|
{
|
|
|
|
/* No need to do anything; this bottom half is only used to
|
|
|
|
* kick the kernel out of ppoll/poll/WaitForMultipleObjects.
|
|
|
|
*/
|
|
|
|
}
|
2011-09-13 16:30:52 +08:00
|
|
|
|
2013-03-07 20:41:44 +08:00
|
|
|
AioContext *qemu_get_aio_context(void)
|
|
|
|
{
|
|
|
|
return qemu_aio_context;
|
|
|
|
}
|
|
|
|
|
2011-09-13 16:30:52 +08:00
|
|
|
void qemu_notify_event(void)
|
|
|
|
{
|
2010-05-24 23:27:14 +08:00
|
|
|
if (!qemu_aio_context) {
|
2012-01-21 09:08:27 +08:00
|
|
|
return;
|
|
|
|
}
|
2015-07-24 19:42:55 +08:00
|
|
|
qemu_bh_schedule(qemu_notify_bh);
|
2011-09-13 16:30:52 +08:00
|
|
|
}
|
|
|
|
|
2013-02-20 18:28:25 +08:00
|
|
|
static GArray *gpollfds;
|
|
|
|
|
2014-09-18 19:30:49 +08:00
|
|
|
int qemu_init_main_loop(Error **errp)
|
2011-09-13 16:30:52 +08:00
|
|
|
{
|
|
|
|
int ret;
|
2012-09-24 21:07:08 +08:00
|
|
|
GSource *src;
|
2014-09-18 19:30:49 +08:00
|
|
|
Error *local_error = NULL;
|
2011-09-13 16:30:52 +08:00
|
|
|
|
2017-03-03 18:50:29 +08:00
|
|
|
init_clocks(qemu_timer_notify_cb);
|
2012-10-29 22:28:36 +08:00
|
|
|
|
2011-09-13 16:30:52 +08:00
|
|
|
ret = qemu_signal_init();
|
|
|
|
if (ret) {
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2014-09-18 19:30:49 +08:00
|
|
|
qemu_aio_context = aio_context_new(&local_error);
|
|
|
|
if (!qemu_aio_context) {
|
|
|
|
error_propagate(errp, local_error);
|
|
|
|
return -EMFILE;
|
|
|
|
}
|
2016-07-06 18:08:59 +08:00
|
|
|
qemu_notify_bh = qemu_bh_new(notify_event_cb, NULL);
|
2013-02-20 18:28:25 +08:00
|
|
|
gpollfds = g_array_new(FALSE, FALSE, sizeof(GPollFD));
|
2012-09-24 21:07:08 +08:00
|
|
|
src = aio_get_g_source(qemu_aio_context);
|
2016-09-30 22:34:24 +08:00
|
|
|
g_source_set_name(src, "aio-context");
|
2012-09-24 21:07:08 +08:00
|
|
|
g_source_attach(src, NULL);
|
|
|
|
g_source_unref(src);
|
2015-09-07 11:28:58 +08:00
|
|
|
src = iohandler_get_g_source();
|
2016-09-30 22:34:24 +08:00
|
|
|
g_source_set_name(src, "io-handler");
|
2015-09-07 11:28:58 +08:00
|
|
|
g_source_attach(src, NULL);
|
|
|
|
g_source_unref(src);
|
2011-09-13 16:30:52 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int max_priority;
|
|
|
|
|
2012-03-20 17:49:21 +08:00
|
|
|
#ifndef _WIN32
|
2013-02-20 18:28:26 +08:00
|
|
|
static int glib_pollfds_idx;
|
|
|
|
static int glib_n_poll_fds;
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
static void glib_pollfds_fill(int64_t *cur_timeout)
|
2011-09-13 16:30:52 +08:00
|
|
|
{
|
|
|
|
GMainContext *context = g_main_context_default();
|
2012-03-20 17:49:17 +08:00
|
|
|
int timeout = 0;
|
2013-08-21 23:02:54 +08:00
|
|
|
int64_t timeout_ns;
|
2013-02-20 18:28:26 +08:00
|
|
|
int n;
|
2011-09-13 16:30:52 +08:00
|
|
|
|
|
|
|
g_main_context_prepare(context, &max_priority);
|
|
|
|
|
2013-02-20 18:28:26 +08:00
|
|
|
glib_pollfds_idx = gpollfds->len;
|
|
|
|
n = glib_n_poll_fds;
|
|
|
|
do {
|
|
|
|
GPollFD *pfds;
|
|
|
|
glib_n_poll_fds = n;
|
|
|
|
g_array_set_size(gpollfds, glib_pollfds_idx + glib_n_poll_fds);
|
|
|
|
pfds = &g_array_index(gpollfds, GPollFD, glib_pollfds_idx);
|
|
|
|
n = g_main_context_query(context, max_priority, &timeout, pfds,
|
|
|
|
glib_n_poll_fds);
|
|
|
|
} while (n != glib_n_poll_fds);
|
2011-09-13 16:30:52 +08:00
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
if (timeout < 0) {
|
|
|
|
timeout_ns = -1;
|
|
|
|
} else {
|
|
|
|
timeout_ns = (int64_t)timeout * (int64_t)SCALE_MS;
|
2011-09-13 16:30:52 +08:00
|
|
|
}
|
2013-08-21 23:02:54 +08:00
|
|
|
|
|
|
|
*cur_timeout = qemu_soonest_timeout(timeout_ns, *cur_timeout);
|
2011-09-13 16:30:52 +08:00
|
|
|
}
|
|
|
|
|
2013-02-20 18:28:26 +08:00
|
|
|
static void glib_pollfds_poll(void)
|
2011-09-13 16:30:52 +08:00
|
|
|
{
|
|
|
|
GMainContext *context = g_main_context_default();
|
2013-02-20 18:28:26 +08:00
|
|
|
GPollFD *pfds = &g_array_index(gpollfds, GPollFD, glib_pollfds_idx);
|
2011-09-13 16:30:52 +08:00
|
|
|
|
2013-02-20 18:28:26 +08:00
|
|
|
if (g_main_context_check(context, max_priority, pfds, glib_n_poll_fds)) {
|
2011-09-13 16:30:52 +08:00
|
|
|
g_main_context_dispatch(context);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-04-05 21:46:00 +08:00
|
|
|
#define MAX_MAIN_LOOP_SPIN (1000)
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
static int os_host_main_loop_wait(int64_t timeout)
|
2012-03-20 17:49:18 +08:00
|
|
|
{
|
main-loop: Acquire main_context lock around os_host_main_loop_wait.
When running virt-rescue the serial console hangs from time to time.
Virt-rescue runs an ordinary Linux kernel "appliance", but there is
only a single idle process running inside, so the qemu main loop is
largely idle. With virt-rescue >= 1.37 you may be able to observe the
hang by doing:
$ virt-rescue -e ^] --scratch
><rescue> while true; do ls -l /usr/bin; done
The hang in virt-rescue can be resolved by pressing a key on the
serial console.
Possibly with the same root cause, we also observed hangs during very
early boot of regular Linux VMs with a serial console. Those hangs
are extremely rare, but you may be able to observe them by running
this command on baremetal for a sufficiently long time:
$ while libguestfs-test-tool -t 60 >& /tmp/log ; do echo -n . ; done
(Check in /tmp/log that the failure was caused by a hang during early
boot, and not some other reason)
During investigation of this bug, Paolo Bonzini wrote:
> glib is expecting QEMU to use g_main_context_acquire around accesses to
> GMainContext. However QEMU is not doing that, instead it is taking its
> own mutex. So we should add g_main_context_acquire and
> g_main_context_release in the two implementations of
> os_host_main_loop_wait; these should undo the effect of Frediano's
> glib patch.
This patch exactly implements Paolo's suggestion in that paragraph.
This fixes the serial console hang in my testing, across 3 different
physical machines (AMD, Intel Core i7 and Intel Xeon), over many hours
of automated testing. I wasn't able to reproduce the early boot hangs
(but as noted above, these are extremely rare in any case).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1435432
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20170331205133.23906-1-rjones@redhat.com>
[Paolo: this is actually a glib bug: recent glib versions are also
expecting g_main_context_acquire around g_poll---but that is not
documented and probably not even intended].
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-01 04:51:33 +08:00
|
|
|
GMainContext *context = g_main_context_default();
|
2012-03-20 17:49:18 +08:00
|
|
|
int ret;
|
2013-04-05 21:46:00 +08:00
|
|
|
static int spin_counter;
|
2012-03-20 17:49:18 +08:00
|
|
|
|
main-loop: Acquire main_context lock around os_host_main_loop_wait.
When running virt-rescue the serial console hangs from time to time.
Virt-rescue runs an ordinary Linux kernel "appliance", but there is
only a single idle process running inside, so the qemu main loop is
largely idle. With virt-rescue >= 1.37 you may be able to observe the
hang by doing:
$ virt-rescue -e ^] --scratch
><rescue> while true; do ls -l /usr/bin; done
The hang in virt-rescue can be resolved by pressing a key on the
serial console.
Possibly with the same root cause, we also observed hangs during very
early boot of regular Linux VMs with a serial console. Those hangs
are extremely rare, but you may be able to observe them by running
this command on baremetal for a sufficiently long time:
$ while libguestfs-test-tool -t 60 >& /tmp/log ; do echo -n . ; done
(Check in /tmp/log that the failure was caused by a hang during early
boot, and not some other reason)
During investigation of this bug, Paolo Bonzini wrote:
> glib is expecting QEMU to use g_main_context_acquire around accesses to
> GMainContext. However QEMU is not doing that, instead it is taking its
> own mutex. So we should add g_main_context_acquire and
> g_main_context_release in the two implementations of
> os_host_main_loop_wait; these should undo the effect of Frediano's
> glib patch.
This patch exactly implements Paolo's suggestion in that paragraph.
This fixes the serial console hang in my testing, across 3 different
physical machines (AMD, Intel Core i7 and Intel Xeon), over many hours
of automated testing. I wasn't able to reproduce the early boot hangs
(but as noted above, these are extremely rare in any case).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1435432
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20170331205133.23906-1-rjones@redhat.com>
[Paolo: this is actually a glib bug: recent glib versions are also
expecting g_main_context_acquire around g_poll---but that is not
documented and probably not even intended].
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-01 04:51:33 +08:00
|
|
|
g_main_context_acquire(context);
|
|
|
|
|
2013-02-20 18:28:26 +08:00
|
|
|
glib_pollfds_fill(&timeout);
|
2012-03-20 17:49:18 +08:00
|
|
|
|
2013-04-05 21:46:00 +08:00
|
|
|
/* If the I/O thread is very busy or we are incorrectly busy waiting in
|
|
|
|
* the I/O thread, this can lead to starvation of the BQL such that the
|
|
|
|
* VCPU threads never run. To make sure we can detect the later case,
|
|
|
|
* print a message to the screen. If we run into this condition, create
|
|
|
|
* a fake timeout in order to give the VCPU threads a chance to run.
|
|
|
|
*/
|
2013-08-21 23:02:54 +08:00
|
|
|
if (!timeout && (spin_counter > MAX_MAIN_LOOP_SPIN)) {
|
2013-04-05 21:46:00 +08:00
|
|
|
static bool notified;
|
|
|
|
|
2016-10-18 02:09:39 +08:00
|
|
|
if (!notified && !qtest_enabled() && !qtest_driver()) {
|
2013-04-05 21:46:00 +08:00
|
|
|
fprintf(stderr,
|
|
|
|
"main-loop: WARNING: I/O thread spun for %d iterations\n",
|
|
|
|
MAX_MAIN_LOOP_SPIN);
|
|
|
|
notified = true;
|
|
|
|
}
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
timeout = SCALE_MS;
|
2013-04-05 21:46:00 +08:00
|
|
|
}
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
if (timeout) {
|
2013-04-05 21:46:00 +08:00
|
|
|
spin_counter = 0;
|
2012-03-20 17:49:18 +08:00
|
|
|
qemu_mutex_unlock_iothread();
|
2013-04-05 21:46:00 +08:00
|
|
|
} else {
|
|
|
|
spin_counter++;
|
2012-03-20 17:49:18 +08:00
|
|
|
}
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
ret = qemu_poll_ns((GPollFD *)gpollfds->data, gpollfds->len, timeout);
|
2013-02-20 18:28:25 +08:00
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
if (timeout) {
|
2012-03-20 17:49:18 +08:00
|
|
|
qemu_mutex_lock_iothread();
|
|
|
|
}
|
|
|
|
|
2013-02-20 18:28:26 +08:00
|
|
|
glib_pollfds_poll();
|
main-loop: Acquire main_context lock around os_host_main_loop_wait.
When running virt-rescue the serial console hangs from time to time.
Virt-rescue runs an ordinary Linux kernel "appliance", but there is
only a single idle process running inside, so the qemu main loop is
largely idle. With virt-rescue >= 1.37 you may be able to observe the
hang by doing:
$ virt-rescue -e ^] --scratch
><rescue> while true; do ls -l /usr/bin; done
The hang in virt-rescue can be resolved by pressing a key on the
serial console.
Possibly with the same root cause, we also observed hangs during very
early boot of regular Linux VMs with a serial console. Those hangs
are extremely rare, but you may be able to observe them by running
this command on baremetal for a sufficiently long time:
$ while libguestfs-test-tool -t 60 >& /tmp/log ; do echo -n . ; done
(Check in /tmp/log that the failure was caused by a hang during early
boot, and not some other reason)
During investigation of this bug, Paolo Bonzini wrote:
> glib is expecting QEMU to use g_main_context_acquire around accesses to
> GMainContext. However QEMU is not doing that, instead it is taking its
> own mutex. So we should add g_main_context_acquire and
> g_main_context_release in the two implementations of
> os_host_main_loop_wait; these should undo the effect of Frediano's
> glib patch.
This patch exactly implements Paolo's suggestion in that paragraph.
This fixes the serial console hang in my testing, across 3 different
physical machines (AMD, Intel Core i7 and Intel Xeon), over many hours
of automated testing. I wasn't able to reproduce the early boot hangs
(but as noted above, these are extremely rare in any case).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1435432
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20170331205133.23906-1-rjones@redhat.com>
[Paolo: this is actually a glib bug: recent glib versions are also
expecting g_main_context_acquire around g_poll---but that is not
documented and probably not even intended].
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-01 04:51:33 +08:00
|
|
|
|
|
|
|
g_main_context_release(context);
|
|
|
|
|
2012-03-20 17:49:18 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
#else
|
2011-09-13 16:30:52 +08:00
|
|
|
/***********************************************************/
|
|
|
|
/* Polling handling */
|
|
|
|
|
|
|
|
typedef struct PollingEntry {
|
|
|
|
PollingFunc *func;
|
|
|
|
void *opaque;
|
|
|
|
struct PollingEntry *next;
|
|
|
|
} PollingEntry;
|
|
|
|
|
|
|
|
static PollingEntry *first_polling_entry;
|
|
|
|
|
|
|
|
int qemu_add_polling_cb(PollingFunc *func, void *opaque)
|
|
|
|
{
|
|
|
|
PollingEntry **ppe, *pe;
|
|
|
|
pe = g_malloc0(sizeof(PollingEntry));
|
|
|
|
pe->func = func;
|
|
|
|
pe->opaque = opaque;
|
|
|
|
for(ppe = &first_polling_entry; *ppe != NULL; ppe = &(*ppe)->next);
|
|
|
|
*ppe = pe;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_del_polling_cb(PollingFunc *func, void *opaque)
|
|
|
|
{
|
|
|
|
PollingEntry **ppe, *pe;
|
|
|
|
for(ppe = &first_polling_entry; *ppe != NULL; ppe = &(*ppe)->next) {
|
|
|
|
pe = *ppe;
|
|
|
|
if (pe->func == func && pe->opaque == opaque) {
|
|
|
|
*ppe = pe->next;
|
|
|
|
g_free(pe);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/***********************************************************/
|
|
|
|
/* Wait objects support */
|
|
|
|
typedef struct WaitObjects {
|
|
|
|
int num;
|
2012-03-20 17:49:20 +08:00
|
|
|
int revents[MAXIMUM_WAIT_OBJECTS + 1];
|
2011-09-13 16:30:52 +08:00
|
|
|
HANDLE events[MAXIMUM_WAIT_OBJECTS + 1];
|
|
|
|
WaitObjectFunc *func[MAXIMUM_WAIT_OBJECTS + 1];
|
|
|
|
void *opaque[MAXIMUM_WAIT_OBJECTS + 1];
|
|
|
|
} WaitObjects;
|
|
|
|
|
|
|
|
static WaitObjects wait_objects = {0};
|
|
|
|
|
|
|
|
int qemu_add_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
|
|
|
|
{
|
|
|
|
WaitObjects *w = &wait_objects;
|
|
|
|
if (w->num >= MAXIMUM_WAIT_OBJECTS) {
|
|
|
|
return -1;
|
|
|
|
}
|
|
|
|
w->events[w->num] = handle;
|
|
|
|
w->func[w->num] = func;
|
|
|
|
w->opaque[w->num] = opaque;
|
2012-03-20 17:49:20 +08:00
|
|
|
w->revents[w->num] = 0;
|
2011-09-13 16:30:52 +08:00
|
|
|
w->num++;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
void qemu_del_wait_object(HANDLE handle, WaitObjectFunc *func, void *opaque)
|
|
|
|
{
|
|
|
|
int i, found;
|
|
|
|
WaitObjects *w = &wait_objects;
|
|
|
|
|
|
|
|
found = 0;
|
|
|
|
for (i = 0; i < w->num; i++) {
|
|
|
|
if (w->events[i] == handle) {
|
|
|
|
found = 1;
|
|
|
|
}
|
|
|
|
if (found) {
|
|
|
|
w->events[i] = w->events[i + 1];
|
|
|
|
w->func[i] = w->func[i + 1];
|
|
|
|
w->opaque[i] = w->opaque[i + 1];
|
2012-03-20 17:49:20 +08:00
|
|
|
w->revents[i] = w->revents[i + 1];
|
2011-09-13 16:30:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
if (found) {
|
|
|
|
w->num--;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-20 17:49:19 +08:00
|
|
|
void qemu_fd_register(int fd)
|
|
|
|
{
|
2010-05-24 23:27:14 +08:00
|
|
|
WSAEventSelect(fd, event_notifier_get_handle(&qemu_aio_context->notifier),
|
|
|
|
FD_READ | FD_ACCEPT | FD_CLOSE |
|
2012-03-20 17:49:19 +08:00
|
|
|
FD_CONNECT | FD_WRITE | FD_OOB);
|
|
|
|
}
|
|
|
|
|
2013-02-20 18:28:25 +08:00
|
|
|
static int pollfds_fill(GArray *pollfds, fd_set *rfds, fd_set *wfds,
|
|
|
|
fd_set *xfds)
|
|
|
|
{
|
|
|
|
int nfds = -1;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < pollfds->len; i++) {
|
|
|
|
GPollFD *pfd = &g_array_index(pollfds, GPollFD, i);
|
|
|
|
int fd = pfd->fd;
|
|
|
|
int events = pfd->events;
|
2013-05-16 23:36:00 +08:00
|
|
|
if (events & G_IO_IN) {
|
2013-02-20 18:28:25 +08:00
|
|
|
FD_SET(fd, rfds);
|
|
|
|
nfds = MAX(nfds, fd);
|
|
|
|
}
|
2013-05-16 23:36:00 +08:00
|
|
|
if (events & G_IO_OUT) {
|
2013-02-20 18:28:25 +08:00
|
|
|
FD_SET(fd, wfds);
|
|
|
|
nfds = MAX(nfds, fd);
|
|
|
|
}
|
|
|
|
if (events & G_IO_PRI) {
|
|
|
|
FD_SET(fd, xfds);
|
|
|
|
nfds = MAX(nfds, fd);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nfds;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void pollfds_poll(GArray *pollfds, int nfds, fd_set *rfds,
|
|
|
|
fd_set *wfds, fd_set *xfds)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < pollfds->len; i++) {
|
|
|
|
GPollFD *pfd = &g_array_index(pollfds, GPollFD, i);
|
|
|
|
int fd = pfd->fd;
|
|
|
|
int revents = 0;
|
|
|
|
|
|
|
|
if (FD_ISSET(fd, rfds)) {
|
2013-05-16 23:36:00 +08:00
|
|
|
revents |= G_IO_IN;
|
2013-02-20 18:28:25 +08:00
|
|
|
}
|
|
|
|
if (FD_ISSET(fd, wfds)) {
|
2013-05-16 23:36:00 +08:00
|
|
|
revents |= G_IO_OUT;
|
2013-02-20 18:28:25 +08:00
|
|
|
}
|
|
|
|
if (FD_ISSET(fd, xfds)) {
|
|
|
|
revents |= G_IO_PRI;
|
|
|
|
}
|
|
|
|
pfd->revents = revents & pfd->events;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
static int os_host_main_loop_wait(int64_t timeout)
|
2011-09-13 16:30:52 +08:00
|
|
|
{
|
2012-03-20 17:49:21 +08:00
|
|
|
GMainContext *context = g_main_context_default();
|
2013-02-20 18:28:26 +08:00
|
|
|
GPollFD poll_fds[1024 * 2]; /* this is probably overkill */
|
2013-02-20 18:28:24 +08:00
|
|
|
int select_ret = 0;
|
2013-02-20 18:28:26 +08:00
|
|
|
int g_poll_ret, ret, i, n_poll_fds;
|
2011-09-13 16:30:52 +08:00
|
|
|
PollingEntry *pe;
|
2012-03-20 17:49:19 +08:00
|
|
|
WaitObjects *w = &wait_objects;
|
2012-04-27 23:02:08 +08:00
|
|
|
gint poll_timeout;
|
2013-08-21 23:02:54 +08:00
|
|
|
int64_t poll_timeout_ns;
|
2012-03-20 17:49:18 +08:00
|
|
|
static struct timeval tv0;
|
2013-02-20 18:28:30 +08:00
|
|
|
fd_set rfds, wfds, xfds;
|
|
|
|
int nfds;
|
2011-09-13 16:30:52 +08:00
|
|
|
|
main-loop: Acquire main_context lock around os_host_main_loop_wait.
When running virt-rescue the serial console hangs from time to time.
Virt-rescue runs an ordinary Linux kernel "appliance", but there is
only a single idle process running inside, so the qemu main loop is
largely idle. With virt-rescue >= 1.37 you may be able to observe the
hang by doing:
$ virt-rescue -e ^] --scratch
><rescue> while true; do ls -l /usr/bin; done
The hang in virt-rescue can be resolved by pressing a key on the
serial console.
Possibly with the same root cause, we also observed hangs during very
early boot of regular Linux VMs with a serial console. Those hangs
are extremely rare, but you may be able to observe them by running
this command on baremetal for a sufficiently long time:
$ while libguestfs-test-tool -t 60 >& /tmp/log ; do echo -n . ; done
(Check in /tmp/log that the failure was caused by a hang during early
boot, and not some other reason)
During investigation of this bug, Paolo Bonzini wrote:
> glib is expecting QEMU to use g_main_context_acquire around accesses to
> GMainContext. However QEMU is not doing that, instead it is taking its
> own mutex. So we should add g_main_context_acquire and
> g_main_context_release in the two implementations of
> os_host_main_loop_wait; these should undo the effect of Frediano's
> glib patch.
This patch exactly implements Paolo's suggestion in that paragraph.
This fixes the serial console hang in my testing, across 3 different
physical machines (AMD, Intel Core i7 and Intel Xeon), over many hours
of automated testing. I wasn't able to reproduce the early boot hangs
(but as noted above, these are extremely rare in any case).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1435432
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20170331205133.23906-1-rjones@redhat.com>
[Paolo: this is actually a glib bug: recent glib versions are also
expecting g_main_context_acquire around g_poll---but that is not
documented and probably not even intended].
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-01 04:51:33 +08:00
|
|
|
g_main_context_acquire(context);
|
|
|
|
|
2011-09-13 16:30:52 +08:00
|
|
|
/* XXX: need to suppress polling by better using win32 events */
|
|
|
|
ret = 0;
|
|
|
|
for (pe = first_polling_entry; pe != NULL; pe = pe->next) {
|
|
|
|
ret |= pe->func(pe->opaque);
|
|
|
|
}
|
2012-03-20 17:49:19 +08:00
|
|
|
if (ret != 0) {
|
main-loop: Acquire main_context lock around os_host_main_loop_wait.
When running virt-rescue the serial console hangs from time to time.
Virt-rescue runs an ordinary Linux kernel "appliance", but there is
only a single idle process running inside, so the qemu main loop is
largely idle. With virt-rescue >= 1.37 you may be able to observe the
hang by doing:
$ virt-rescue -e ^] --scratch
><rescue> while true; do ls -l /usr/bin; done
The hang in virt-rescue can be resolved by pressing a key on the
serial console.
Possibly with the same root cause, we also observed hangs during very
early boot of regular Linux VMs with a serial console. Those hangs
are extremely rare, but you may be able to observe them by running
this command on baremetal for a sufficiently long time:
$ while libguestfs-test-tool -t 60 >& /tmp/log ; do echo -n . ; done
(Check in /tmp/log that the failure was caused by a hang during early
boot, and not some other reason)
During investigation of this bug, Paolo Bonzini wrote:
> glib is expecting QEMU to use g_main_context_acquire around accesses to
> GMainContext. However QEMU is not doing that, instead it is taking its
> own mutex. So we should add g_main_context_acquire and
> g_main_context_release in the two implementations of
> os_host_main_loop_wait; these should undo the effect of Frediano's
> glib patch.
This patch exactly implements Paolo's suggestion in that paragraph.
This fixes the serial console hang in my testing, across 3 different
physical machines (AMD, Intel Core i7 and Intel Xeon), over many hours
of automated testing. I wasn't able to reproduce the early boot hangs
(but as noted above, these are extremely rare in any case).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1435432
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20170331205133.23906-1-rjones@redhat.com>
[Paolo: this is actually a glib bug: recent glib versions are also
expecting g_main_context_acquire around g_poll---but that is not
documented and probably not even intended].
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-01 04:51:33 +08:00
|
|
|
g_main_context_release(context);
|
2012-03-20 17:49:19 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2011-09-13 16:30:52 +08:00
|
|
|
|
2013-05-16 23:36:01 +08:00
|
|
|
FD_ZERO(&rfds);
|
|
|
|
FD_ZERO(&wfds);
|
|
|
|
FD_ZERO(&xfds);
|
|
|
|
nfds = pollfds_fill(gpollfds, &rfds, &wfds, &xfds);
|
|
|
|
if (nfds >= 0) {
|
|
|
|
select_ret = select(nfds + 1, &rfds, &wfds, &xfds, &tv0);
|
|
|
|
if (select_ret != 0) {
|
|
|
|
timeout = 0;
|
|
|
|
}
|
|
|
|
if (select_ret > 0) {
|
|
|
|
pollfds_poll(gpollfds, nfds, &rfds, &wfds, &xfds);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-20 17:49:21 +08:00
|
|
|
g_main_context_prepare(context, &max_priority);
|
2012-04-27 23:02:08 +08:00
|
|
|
n_poll_fds = g_main_context_query(context, max_priority, &poll_timeout,
|
2012-03-20 17:49:21 +08:00
|
|
|
poll_fds, ARRAY_SIZE(poll_fds));
|
|
|
|
g_assert(n_poll_fds <= ARRAY_SIZE(poll_fds));
|
|
|
|
|
2012-03-20 17:49:20 +08:00
|
|
|
for (i = 0; i < w->num; i++) {
|
2012-04-13 02:42:34 +08:00
|
|
|
poll_fds[n_poll_fds + i].fd = (DWORD_PTR)w->events[i];
|
2012-03-20 17:49:21 +08:00
|
|
|
poll_fds[n_poll_fds + i].events = G_IO_IN;
|
2012-03-20 17:49:20 +08:00
|
|
|
}
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
if (poll_timeout < 0) {
|
|
|
|
poll_timeout_ns = -1;
|
|
|
|
} else {
|
|
|
|
poll_timeout_ns = (int64_t)poll_timeout * (int64_t)SCALE_MS;
|
2012-04-30 01:15:02 +08:00
|
|
|
}
|
|
|
|
|
2013-08-21 23:02:54 +08:00
|
|
|
poll_timeout_ns = qemu_soonest_timeout(poll_timeout_ns, timeout);
|
|
|
|
|
2012-03-20 17:49:19 +08:00
|
|
|
qemu_mutex_unlock_iothread();
|
2013-08-21 23:02:54 +08:00
|
|
|
g_poll_ret = qemu_poll_ns(poll_fds, n_poll_fds + w->num, poll_timeout_ns);
|
|
|
|
|
2012-03-20 17:49:19 +08:00
|
|
|
qemu_mutex_lock_iothread();
|
2013-01-08 23:30:56 +08:00
|
|
|
if (g_poll_ret > 0) {
|
2012-03-20 17:49:20 +08:00
|
|
|
for (i = 0; i < w->num; i++) {
|
2012-03-20 17:49:21 +08:00
|
|
|
w->revents[i] = poll_fds[n_poll_fds + i].revents;
|
2012-03-20 17:49:19 +08:00
|
|
|
}
|
2012-03-20 17:49:20 +08:00
|
|
|
for (i = 0; i < w->num; i++) {
|
|
|
|
if (w->revents[i] && w->func[i]) {
|
|
|
|
w->func[i](w->opaque[i]);
|
2011-09-13 16:30:52 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-03-20 17:49:21 +08:00
|
|
|
if (g_main_context_check(context, max_priority, poll_fds, n_poll_fds)) {
|
|
|
|
g_main_context_dispatch(context);
|
|
|
|
}
|
|
|
|
|
main-loop: Acquire main_context lock around os_host_main_loop_wait.
When running virt-rescue the serial console hangs from time to time.
Virt-rescue runs an ordinary Linux kernel "appliance", but there is
only a single idle process running inside, so the qemu main loop is
largely idle. With virt-rescue >= 1.37 you may be able to observe the
hang by doing:
$ virt-rescue -e ^] --scratch
><rescue> while true; do ls -l /usr/bin; done
The hang in virt-rescue can be resolved by pressing a key on the
serial console.
Possibly with the same root cause, we also observed hangs during very
early boot of regular Linux VMs with a serial console. Those hangs
are extremely rare, but you may be able to observe them by running
this command on baremetal for a sufficiently long time:
$ while libguestfs-test-tool -t 60 >& /tmp/log ; do echo -n . ; done
(Check in /tmp/log that the failure was caused by a hang during early
boot, and not some other reason)
During investigation of this bug, Paolo Bonzini wrote:
> glib is expecting QEMU to use g_main_context_acquire around accesses to
> GMainContext. However QEMU is not doing that, instead it is taking its
> own mutex. So we should add g_main_context_acquire and
> g_main_context_release in the two implementations of
> os_host_main_loop_wait; these should undo the effect of Frediano's
> glib patch.
This patch exactly implements Paolo's suggestion in that paragraph.
This fixes the serial console hang in my testing, across 3 different
physical machines (AMD, Intel Core i7 and Intel Xeon), over many hours
of automated testing. I wasn't able to reproduce the early boot hangs
(but as noted above, these are extremely rare in any case).
Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1435432
Reported-by: Richard W.M. Jones <rjones@redhat.com>
Tested-by: Richard W.M. Jones <rjones@redhat.com>
Signed-off-by: Richard W.M. Jones <rjones@redhat.com>
Message-Id: <20170331205133.23906-1-rjones@redhat.com>
[Paolo: this is actually a glib bug: recent glib versions are also
expecting g_main_context_acquire around g_poll---but that is not
documented and probably not even intended].
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2017-04-01 04:51:33 +08:00
|
|
|
g_main_context_release(context);
|
|
|
|
|
2013-01-08 23:30:56 +08:00
|
|
|
return select_ret || g_poll_ret;
|
2011-09-13 16:30:52 +08:00
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2017-06-28 01:32:49 +08:00
|
|
|
void main_loop_wait(int nonblocking)
|
2011-09-13 16:30:52 +08:00
|
|
|
{
|
2012-04-14 02:35:04 +08:00
|
|
|
int ret;
|
|
|
|
uint32_t timeout = UINT32_MAX;
|
2013-08-21 23:02:54 +08:00
|
|
|
int64_t timeout_ns;
|
2011-09-13 16:30:52 +08:00
|
|
|
|
|
|
|
if (nonblocking) {
|
|
|
|
timeout = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* poll any events */
|
2013-02-20 18:28:25 +08:00
|
|
|
g_array_set_size(gpollfds, 0); /* reset for new iteration */
|
2011-09-13 16:30:52 +08:00
|
|
|
/* XXX: separate device handlers from system ones */
|
2013-08-25 10:01:21 +08:00
|
|
|
slirp_pollfds_fill(gpollfds, &timeout);
|
2013-08-21 23:02:54 +08:00
|
|
|
|
|
|
|
if (timeout == UINT32_MAX) {
|
|
|
|
timeout_ns = -1;
|
|
|
|
} else {
|
|
|
|
timeout_ns = (uint64_t)timeout * (int64_t)(SCALE_MS);
|
|
|
|
}
|
|
|
|
|
|
|
|
timeout_ns = qemu_soonest_timeout(timeout_ns,
|
|
|
|
timerlistgroup_deadline_ns(
|
|
|
|
&main_loop_tlg));
|
|
|
|
|
|
|
|
ret = os_host_main_loop_wait(timeout_ns);
|
2013-02-20 18:28:28 +08:00
|
|
|
slirp_pollfds_poll(gpollfds, (ret < 0));
|
2011-09-13 16:30:52 +08:00
|
|
|
|
2015-09-18 00:24:39 +08:00
|
|
|
/* CPU thread can infinitely wait for event after
|
|
|
|
missing the warp */
|
2016-03-10 19:56:09 +08:00
|
|
|
qemu_start_warp_timer();
|
2013-08-21 23:03:02 +08:00
|
|
|
qemu_clock_run_all_timers();
|
2011-09-13 16:30:52 +08:00
|
|
|
}
|
2012-10-30 06:45:23 +08:00
|
|
|
|
|
|
|
/* Functions to operate on the main QEMU AioContext. */
|
|
|
|
|
|
|
|
QEMUBH *qemu_bh_new(QEMUBHFunc *cb, void *opaque)
|
|
|
|
{
|
|
|
|
return aio_bh_new(qemu_aio_context, cb, opaque);
|
|
|
|
}
|