From: Paolo Bonzini <pbonzini@redhat.com>
To: "Charls D. Chap" <chapcharls@gmail.com>
Cc: kvm@vger.kernel.org
Subject: Re: tlb flush after each vm_exit, also virtual interrupts injection
Date: Fri, 5 Aug 2016 07:59:46 -0400 (EDT) [thread overview]
Message-ID: <1622465933.13766546.1470398386460.JavaMail.zimbra@redhat.com> (raw)
In-Reply-To: <CAA6eV_Tv-UJA5SukuPSkPyd6zihqeUbfsxKQ63i4X-Wket2CUw@mail.gmail.com>
> >> So in the case of write I/O using virtio-blk dataplane=off
> >> [...] What is going to happen after the host there is
> >> the real I/O completion, the host complete bh is executed? We go
> >> through iothread to guest, in order to executte the
> >> virtio-blk-complete request?
> >
>
> How did the control transfer to QEMU user space (and which thread is
> running vcpu or worker)
> ->virtio_blk_device_realize
> -> virtio_blk_req_complete
> Was it the "real" interrupt for I/O completion from the device?
>
> Which qemu thread executes the code you mentioned?, vcpu or a
> worker(iothread or main_loop) When did iothread finish its work?
There are two ways:
1) the VCPU thread starts the I/O (control is transferred to QEMU user space
by leaving KVM_RUN). The I/O system call happens in a worker thread. When the
systemc call is finished the worker thread wakes up the I/O thread and the I/O
thread executes virtio_blk_req_complete.
2) the VCPU thread (which is running KVM_RUN) writes to an eventfd, which wakes
up the I/O thread. The I/O thread runs the I/O system call in a worker
thread, same as case 1. Also like case 1, when the I/O is finished the
worker thread wakes up the I/O thread and the I/O thread executes
virtio_blk_req_complete.
> I know that there are many exit reasons, but it's not clear to me
> HOW exactly, transfer the control from the execution of one of these
> instructions
> to VMEXIT point which is "vmx_return: " _ASM_PTR " 2b \n\t"
> Where does this extraction happened and we jumped to this label?
> Is it inside of the corresponding ioctl implementation?
>
> I guess the answer is: "read the manual", which is fine to me, because
> you already helped me a lot :)
This is a more specific question, and thus easier to answer: after a
vmexit the instruction pointer is reset to the VMCS's HOST_RIP field,
and KVM writes the address of vmx_return to that field. :)
Paolo
next prev parent reply other threads:[~2016-08-05 11:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-27 10:19 tlb flush after each vm_exit, also virtual interrupts injection charls chap
2016-07-28 8:20 ` Fwd: " Charls D. Chap
2016-08-02 17:33 ` Paolo Bonzini
2016-08-03 14:43 ` Charls D. Chap
2016-08-03 15:56 ` Paolo Bonzini
2016-08-05 11:29 ` Charls D. Chap
2016-08-05 11:59 ` Paolo Bonzini [this message]
2016-08-25 9:12 ` Wanpeng Li
2016-08-29 9:55 ` Paolo Bonzini
2016-08-29 10:22 ` Wanpeng Li
2016-08-29 16:39 ` Paolo Bonzini
2016-08-30 0:39 ` Wanpeng Li
2016-07-28 13:25 ` Radim Krčmář
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1622465933.13766546.1470398386460.JavaMail.zimbra@redhat.com \
--to=pbonzini@redhat.com \
--cc=chapcharls@gmail.com \
--cc=kvm@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).