* Re: [Qemu-devel] Fwd: Understanding Qemu Block
2016-07-27 12:19 ` [Qemu-devel] Fwd: Understanding Qemu Block Gadre Nayan
@ 2016-08-08 15:04 ` Stefan Hajnoczi
0 siblings, 0 replies; 2+ messages in thread
From: Stefan Hajnoczi @ 2016-08-08 15:04 UTC (permalink / raw)
To: Gadre Nayan; +Cc: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 3292 bytes --]
On Wed, Jul 27, 2016 at 05:49:48PM +0530, Gadre Nayan wrote:
> I have recently started working on QEMU and it seems a daunting task
> to say the least, hence I wanted some head-start. I have browsed the
> source but I still need to bring closer some dots so I can start
> working on some experimental changes. I will have to ask further
> questions based on my new improved understanding, I think my questions
> could be compiled into a single FAQ list :)
>
> I wanted to understand AIOContext in Block, Coroutines in Block. How
> are they related to IOThreads and vCPU threads.
>
> Currently My understanding is as follows (kindly validate as well)
>
> 1. There is 1 vCPU thread per CPU core that I specify in the command arguments.
vcpu threads are also used for hyperthreads, not just cores. Basically
each logical CPU that guest code runs on is a vcpu thread.
> so eg: ./qemu-system-x86_64 -smp 4
> should create 4 vCPU threads ?
Yes
> These vCPU threads are going to run the Guest Code, They may also handle the
> exit conditions and dispatch the MMIO request.
>
> So, who handles the MMIO request and its Completion, is it the IOThreads ?
IOThread is a thread that runs an epoll(2) event loop. That means it
can process file descriptor activity and timers.
Many hardware register accesses are handled in the vcpu thread - that
vcpu is unable to execute guest code during this time.
The ioeventfd mechanism is used by some virtio devices, however, to
handle virtqueue notifies in the IOThread. This allows the vcpu can
continue executing guest code while an IOThread performs device
emulation.
So the answer is that device emulation mostly happens in vcpu thread
context but also in QEMU main loop or IOThread context.
(The QEMU main loop is similar to IOThread but there is always one QEMU
main loop thread. It doesn't use the IOThread code and isn't considered
an IOThread, mainly for historical reasons.)
> 2. Lets say the Guest Code has decided to write something on a disk file on the
> Host, the guest Should then dispatch the write operation and some
> IOThread will
> do the IO. How does the IO thread report back the completion of
> this operation.
Typically by raising an interrupt. The kvm.ko kernel module can inject
the interrupt into a running vcpu.
> And how do the AIOcontext and Coroutines play a role in this operation.
IOThread is the thread. AIOContext is the event loop code (epoll()
loop, file descriptor monitoring, etc). Coroutines are just a
convenience to avoid callback hell and making code easier to read, but
they don't change the event-driven architecture of QEMU.
> I know the use of co-routines but I would like to understand
> through some code
> snippets how they interact with the block layer.
There are plently of examples in block.c and block/*. Basically the
device emulation code calls blk_aio_preadv()/blk_aio_pwritev()/etc.
Because the block layer code is complex and would involve many many
callbacks, block.c executes the I/O request in a coroutine. This allows
async I/O to appear like a regular blocking I/O operation (in
preadv()/pwritev() style) without spaghetti code (aka callback hell).
Stefan
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread