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

[Stefan Hajnoczi]

On Wed, Jul 27, 2016 at 2:20 PM, Charls D. Chap <address@hidden> wrote:
> On Wed, Jul 27, 2016 at 3:52 PM, Stefan Hajnoczi <address@hidden> wrote:
>>
>> 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"?
>
> An I/O , that is associated with a device opened with O_SYNC, O_DIRECT flags,
> so that we are sure that it's going all the path down, until the
> actual write of the data to the physical device.
> That's why, i can't understand, how vcpu can continue execution,
> without waiting on a condition or sleeping.
> If vcpu is not sleeping, then it means, that vcpu didn't execute the
> kick in the guest kernel?

Review how blocking write(2) is implemented on physical hardware:

The thread inside the write(2) system call blocks.  This means the
thread scheduler knows this thread cannot make progress and instead it
runs another thread in the meantime.  Eventually the I/O request is
completed and the write(2) thread becomes runnable again.  At this
point write(2) returns.

Virtualization changes nothing about this scenario.  The virtio-blk
virtqueue notification is equivalent to writing to a hardware register
on a phyiscal storage controller (SATA, SCSI HBA, etc).  In both cases
the CPU continues executing instructions while the I/O request is
being processed.

> iothread is in control and this is the thread that will follow the
> common kernel path for the I/O submit and completion. I mean, that
> iothread, will be waiting in Host kernel, I/O wait queue,
> after the submission of I/O.

No.  Please read block/raw-posix.c to understand how I/O requests are
submitted/completed in QEMU.  Either a thread pool is used so worker
threads do the blocking preadv(2)/pwritev(2)/fdatasync(2) or Linux AIO
with eventfd is used.  In both cases IOThread or the QEMU main loop
thread are event loops that wait in ppoll(2)/epoll(2) until the
eventfd is signalled.

> In the meantime, kvm does a VM_ENTRY to where?

Read the ioeventfd code in the Linux kernel: virt/kvm/eventfd.c.

> Since, the interrupt is not completed, the return point couldn't be the
> guest interrupt handler...

...

Sorry, I don't have time to reply to all your questions and it would
require me to look up the code too.  The level of detail you are
asking for is at the code level.  In other words, you're asking people
to read the code for you.

Please read the code and think about it before sending more questions.

Stefan