QEMU uses IO handlers to run select() in the main loop.
The handlers list is managed by qemu_set_fd_handler() helper
which works fine when called from the main thread as it is
called when select() is not waiting.
However IO handlers list can be changed in the thread other than
the main one doing os_host_main_loop_wait(), for example, as a result
of a hypercall which changes PCI config space (VFIO on POWER is the case)
and enables/disabled MSI/MSIX which closes/creates eventfd handles.
As the main loop should be waiting on the newly created eventfds,
it has to be restarted.
The patch adds the qemu_notify_event() call to interrupt select()
to make main_loop() restart select() with the updated IO handlers
list.
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Using bool reduces the size of the structure and improves readability.
Two holes in the structure were removed.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
As spotted by Aneesh, some users pass a NULL opaque so we need to be more
aggressive in checking whether a user means to unregister.
Also fix a double free caused by tag not being reset to zero after delete.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
This patch changes qemu_set_fd_handler to be implemented in terms of
g_io_add_watch(). The semantics are a bit different so some glue is required.
qemu_set_fd_handler2 is much harder to convert because of its use of polling.
The glib main loop has the major of advantage of having a proven thread safe
architecture. By using the glib main loop instead of our own, it will allow us
to eventually introduce multiple I/O threads.
I'm pretty sure that this will work on Win32, but I would appreciate some help
testing. I think the semantics of g_io_channel_unix_new() are really just tied
to the notion of a "unix fd" and not necessarily unix itself.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
SLIRP -smb support wants to fork a process and forget about reaping it.
To please it, add a generic service to register a process id and let
QEMU reap it. In the future it could be enhanced to pass a status,
but this would be unused.
With this in place, the SIGCHLD signal handler would not stomp on pclose
anymore.
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
Alexey Kardashevskiy