qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* Question about "QEMU Internals: Event loops"
@ 2021-08-04  7:14 Jing Zhang
  0 siblings, 0 replies; only message in thread
From: Jing Zhang @ 2021-08-04  7:14 UTC (permalink / raw)
  To: qemu-devel; +Cc: stefanha

[-- Attachment #1: Type: text/plain, Size: 2638 bytes --]

Hi Stefan,

I have read your article “QEMU Internals: Event loops” in your blog, which helps me a lot to understand how QEMU’s thread model works. However, I still have a few questions here.

Firstly, I have done some research in QEMU’s thread model and I know that QEMU use glib GMainContext and AioContext to achieve event loop, which is responsible for IO event and other events like timer or BH. Also, I know QEMU use vCPU thread to emulate real CPU which do the calculation. Our guest OS works on these vCPU thread. If there’s no IO or other event, vCPU will keep doing its job and guest OS runs as a host OS.

But when I am trying to figure out how these things connects, problems occurred. As far as I am concerned, once guest OS start to work, vCPU thread will act as a real CPU controlled by kvm and if there’s a IO event happens, we should exit guest mode and back to user mode(i.e. QEMU). When this happen, we back to vCPU thread and handle different event by checking run->exit_reason. For examples, if guest OS sends a disk request(like store a file into disk), kvm exit, vCPU thread handles it and dispatch the write request to a MemoryRegion. This procedure is reasonable but it do not use event loop. That means event loop do nothing in this procedure.

Therefore, what I am confused is, when and how vCPU thread dispatch these IO event to main-loop or IO thread? In detail, what kinds of function in QEMU changes the fd that main-loops(in detail, system call select/poll/epoll) are listening?

In the article, I see “Some devices perform the guest device register access in the main loop thread or an IOThread thanks to ioeventfd”, so I learn about the knowledge about eventfd. After that, I successfully detected a behavior that QEMU uses this mechanism to change fds(event_notifier_set()) and main-loop runs this IO event while virtio is used. In other situation, for instance, if we don’t use virtio (use a pure emulation of hardware), what’s the way(in detail, what’s the function) that change the fd and how(in detail, what’s the function backtrace)?

I cares about this because I think if IO event happen, if vm exit, vCPU thread must take the responsibility to determine what kinds of IO event can be done by blocking IO(i.e. doing IO in vCPU thread) and what kinds of IO event should dispatch to an event loop.  But in fact, in the code, I can’t find this logic except ioeventfd(and it should use virtio as well). Hence, this question sounds like asking how CPU communicate with hardware, although all of them aren’t real.

I am looking forward to your reply! Thanks.


[-- Attachment #2: Type: text/html, Size: 6288 bytes --]

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2021-08-04 13:32 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-04  7:14 Question about "QEMU Internals: Event loops" Jing Zhang

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).