[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] From virtio_kick until VM-exit?

From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] From virtio_kick until VM-exit?
Date: Wed, 27 Jul 2016 13:52:43 +0100
User-agent: Mutt/1.6.2 (2016-07-01)

On Wed, Jul 27, 2016 at 12:19:52PM +0300, charls chap wrote:
> Hello All,
> I am new with qemu, I am trying to understand the I/O path of a synchronous
> I/O.

What exactly do you mean by "synchronous I/O"?

Most modern devices have asynchronous interfaces (i.e. a ring or list of
requests that complete with an interrupt after the vcpu submits them and
continues execution).

> 1) if i am correct:
> When we run QEMU in emulation mode, WITHOUT kvm. Then we run on TCG runtime
> No vcpus threads?
> qemu_tcg_cpu_thread_fn
> tcg_exec_all();
> No interactions with kvm module. On the other hand, when we have
> virtualization, there are no
> interactions with any part of the tcg implementation.

Yes, it's either TCG or KVM.

> The tb_gen_code in translate-all, and find_slot and find_fast,  its not
> part of the tcg, and there still
> "executed, in the KVM case?
> So if we have
> for (;;)
> c++;
> vcpu thread executes code, using cpu-exec?

In the KVM case the vcpu thread does ioctl(KVM_RUN) to execute guest

> 2)
> What is this pipe, i mean between who?
> when is used?
> int event_notifier_test_and_clear(EventNotifier *e)
> {
>     int value;
>     ssize_t len;
>     char buffer[512];
>     /* Drain the notify pipe.  For eventfd, only 8 bytes will be read.  */
>     value = 0;
>     do {
>         len = read(e->rfd, buffer, sizeof(buffer));
>         value |= (len > 0);
>     } while ((len == -1 && errno == EINTR) || len == sizeof(buffer));
>     return value;
> }

Read eventfd(2) to understand this primitive.  The "pipe" part is a
fallback for systems that don't support eventfd(2).  eventfd is used for
signalling between threads.

The kvm.ko module can signal an ioeventfd when a particular memory or
I/O address is written.  This means that the thread monitoring the
ioeventfd will run when the guest has written to the memory or I/O

This ioeventfd mechanism is an alternative to the "heavyweight exit"
code path (return from ioctl(KVM_RUN) and dispatch the memory or I/O
access in QEMU vcpu thread context before calling ioctl(KVM_RUN) again).
The advantage of ioeventfd is that device emulation can happen in a
separate thread while the vcpu continues executing guest code.

> 3)
> I've tried to trace iothread,
> It seems that the following functions executed once:
> iothread_class_init
> iothread_register_types
> But i have no idea, when static void *iothread_run(void *opaque)
> Acutally when iothread is created?

An IOThread is only created if you put -object iothread,id=iothread0 on
the command-line.  Then you can associate a virtio-blk or virtio-scsi
device with a particular IOThread: -device

When no IOThread is given on the command-line, the ioeventfd processing
happens in the QEMU main loop thread.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]