Introduction to QEMU event handling mechanism

The Qmeu uses an event-driven architecture in which all events are processed in an event loop, and the default event loop in the system is the main loop in main-loop.c (main loop). We can also create an event loop ourselves using –object iothread,id=my-iothread.

The event architecture in QEMU comes from glib, in fact, QEMU itself is based on glib, there are a lot of concepts in qemu from glib, so before you learn QEMU glib can help you understand qemu faster. The following first describes the event mechanism in glib.

Event Handling in Glib

In glib, a main event loop is responsible for handling all event sources (source), including file descriptors (pure files, pipes, or sockets) and timeouts. The new event source can be added by G_source_attach (). To enable the processing of multiple, independent event sources in different threads, each event source is associated with a primary context gmaincontext data structure. A Gmaincontex can only be run in one thread, but event sources in different threads may be added or removed from each other. The event source in Gmaincontext is checked and sent (dispatch) in the main event loop associated with the Gmaincontext.

The new event source type can be created by including the Gsource struct body. The Gsource struct in the new event source type must be the first member, and the other members will be followed. To create a new instance of the event source type, you can call the G_source_new () function, pass in the new event source type size, and a variable of type Gsourcefuncs, which determines how the new event source type is controlled.

The new event source interacts with the main context in two ways. The first is that the prepare function in Gsourcefuncs can set a time-out to determine the time-out for polling in the main event loop, and the second is to add a file descriptor through the G_source_add_poll () function.

A loop of the main context consists of four steps, each implemented by four functions: G_main_context_prepare (), G_main_context_query (), G_main_context_check (), and G_main_ Context_dispatch (), whose state transition diagram is as follows:

Here's a brief description of the four functions:

1. G_main_context_prepare (): For a SOURCE that does not have the G_source_ready flag set, the Source->source_funcs->prepare function is called, and if True is returned, The g_source_ready of the SOURCE is set, when the prepare function is called, a time-out is returned by the parameter, and a minimum time-out is assigned to Context->timeout.
2. G_main_context_query (): Returns the specified number of FD from Context->poll_records, returning Context->timeout,context->poll_ Changed set to False.
3. G_main_context_check (): Returns False if Context->poll_changed is true, otherwise copies the revents of the incoming FDS to the corresponding Context->poll_ Records->fd->revents; Iterates over all the source, calls its check function on a source that does not have the G_source_ready flag set, and adds a source that has the G_source_ready flag set to the In Context->pending_dispatches;
4. G_main_context_dispatch (): Clears the G_source_ready flag of source in Context->pending_dispatches and calls its dispatch function;

This is the process of handling the entire event, and all we need to do is add the new source to the process, and glib will handle the various event sources registered on the source. There are two add functions in glib that implement the ability to add source to Gmaincontext and add FD to source, respectively:

1. G_source_attach (): Adds a file descriptor in Source->poll_fds to context->poll_records; Source is added to the context's source list;
2. G_source_add_poll (): Add FD to Source->poll_fds and then add to Context->poll_records, set context->poll_changed to TRUE .

Event Handling in Qemu

Here's how QEMU uses this set of event-handling processes. QEMU is based on glib development, inherits a lot of glib concept, struct Aiocontext is a new event source type that is created according to the glib source creation principle, used to handle the signal, interrupt and other events, the contents are as follows:

struct Aiocontext {

Gsource source;

Rfifolock lock;

Qlist_head (, Aiohandler) aio_handlers;

int walking_handlers;

uint32_t Notify_me;

Qemumutex Bh_lock;

struct Qemubh *first_bh;

int walking_bh;

BOOL notified;

Eventnotifier notifier;

Qemubh *notify_dummy_bh;

struct ThreadPool *thread_pool;

Qemutimerlistgroup TLG;

int external_disable_cnt;

int EPOLLFD;

BOOL epoll_enabled;

BOOL epoll_available;

};

Aiocontext expands the function of source in glib, not only supports FD, time-out polling, but also simulates the bottom half mechanism of the kernel to realize the asynchronous notification function of the event, in which the notification function is based on EVENTFD implementation.

Aiocontext is essentially a source, as we mentioned above, source has a very important member of Gsourcefuncs, which controls how source is controlled in the main context. The GSOURCEFUNCS definition of Aiocontext is as follows:

Static Gsourcefuncs Aio_source_funcs = {

Aio_ctx_prepare,

Aio_ctx_check,

Aio_ctx_dispatch,

Aio_ctx_finalize

};

These functions are called in G_main_context_prepare (), G_main_context_check (), and G_main_context_dispatch () respectively. Here are some of the main functions of these functions:

1. Aio_ctx_prepare calls Aio_compute_timeout to calculate the required time-out, which is used during the polling process and is determined by the properties of the BH registered in Aiocontext when Aiocontext Returns a valid timeout when all BH that is registered in is idle, and returns 0 when at least one BH is not idle, guaranteeing that BH will be executed as soon as possible.

struct Qemubh {

Aiocontext *ctx;

Qemubhfunc *CB;

void *opaque;

Qemubh *next;

BOOL scheduled;

BOOL Idle;

BOOL deleted;

};

2. Aio_ctx_check is used to check if BH, FD, or timer is present, return true to call G_main_context_dispatch ()

3. Aio_ctx_dispatch calls Aio_dispatch, executes the ready BH, FD, and timer sequentially, and completes the main loop in turn.

QEMU registers Aio_source_funcs to aiocontext with the G_source_new function during initialization.

The common Aiocontext instances in QEMU are four, Qemu_aio_context, Aiocontext in Iohandler->ctx,iothread, which describes the blockdriverstate of disk mirroring Aiocontext. The events they dealt with were:

• QEMU_AIO_CONTEXT:VNC,QMP command
• IOHANDLER->CTX: Responsible for monitoring signal, interruption, event notification, socket, etc.
• IOTHREAD->CTX: Mainly responsible for monitoring the IO aspect;
• BS->CTX: Responsible for the monitoring of blockjob and other related tasks

QEMU uses the G_source_attach function to add qemu_aio_context and Iohandler->ctx to the main loop during initialization.

New QEMU Event Processing loop

The above is the main loop implemented by QEMU to emulate glib, but there are some flaws in the main loop, such as limited scalability when the host is using multiple CPUs, and the master loop using the QEMU global mutex, resulting in lock contention between the Vcpus thread and the main loop, resulting in degraded performance. To solve this problem, QEMU introduced the Iothread event loop, assigning some IO operations to iothread, which improves IO performance.

Iothread is created by passing in the –object iothread,id=my-iothread parameter when QEMU starts. Looping through the aio_poll in the iothread thread, this function simplifies the glib event loop and executes Aio_dispatch as long as there is a ready FD, which executes the ready BH, FD, and timer.

Reference:

1. Qemu/docs/multiple-iothreads.txt
2. Https://developer.gnome.org/glib/2.46/glib-The-Main-Event-Loop.html

Introduction to QEMU event handling mechanism