From: Avi Kivity <avi@redhat.com>
To: Anthony Liguori <anthony@codemonkey.ws>
Cc: "Kapadia, Vivek" <Vivek.Kapadia@lsi.com>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>
Subject: Re: Event channels in KVM?
Date: Thu, 30 Apr 2009 12:04:04 +0300 [thread overview]
Message-ID: <49F96984.7040607@redhat.com> (raw)
In-Reply-To: <49F7360C.8000308@codemonkey.ws>
Anthony Liguori wrote:
> Kapadia, Vivek wrote:
>> I came across this thread looking for an efficient event channel
>> mechanism between two guests (running on different cpu cores).
>>
>> While I can use available emulated IO mechanism (guest1->host kernel
>> driver->Qemu1->Qemu2) in conjunction with interrupt mechanism
>> (Qemu2->host kernel driver->guest2) in KVM, this involves several
>> context switches. Xen handles notifications in hypervisor via
>> hypercall and hence is likely more efficient.
>>
>
> They almost certainly aren't more efficient.
>
> An event channel notification involves a hypercall to the hypervisor.
> When using VT, the performance difference between a vmcall exit vs. a
> pio exit is quite small (especially compared to the overhead of the
> exit). We're talking in the order of nanoseconds compared to
> microseconds.
>
> What makes KVM particularly different from Xen is that in KVM, the PIO
> operation results in a direct transition to QEMU. In Xen, typically
> event channel notifications result in a bit being set in a bitmap
> which then results in an interrupt injection depending on the next
> opportunity the hypervisor has to schedule/run the receiving domain.
> This is not deterministic and can potentially be a very long period of
> time.
>
> Event channels are inherently asynchronous whereas PIO notifications
> in KVM are synchronous. Since the scheduler isn't involved and
> control never leaves the CPU, the KVM PIO notifications are actually
> extremely efficient. IMHO, it's one of KVM's best design features.
>
If you make the pio operation wake up another guest, then the operation
becomes asynchronous. There's really no fundamental different between
Xen and kvm here, and both will require the same number of context
switches (one) to transfer control.
Handling a pio that is completely internal to the guest is different
(Xen has to schedule dom0 or the stub domain), but that's not related to
interguest communications.
--
error compiling committee.c: too many arguments to function
next prev parent reply other threads:[~2009-04-30 9:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-28 16:39 Event channels in KVM? Kapadia, Vivek
2009-04-28 16:59 ` Anthony Liguori
2009-04-30 9:04 ` Avi Kivity [this message]
-- strict thread matches above, loose matches on Subject: below --
2008-09-19 17:16 Matt Anger
2008-09-19 18:31 ` Anthony Liguori
2008-09-19 19:10 ` Javier Guerra
2008-09-19 19:14 ` Anthony Liguori
2008-09-22 23:50 ` Matt Anger
2008-09-23 0:30 ` Dong, Eddie
2008-09-23 0:36 ` Matt Anger
2008-09-23 1:36 ` Dong, Eddie
2008-09-23 7:26 ` Avi Kivity
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=49F96984.7040607@redhat.com \
--to=avi@redhat.com \
--cc=Vivek.Kapadia@lsi.com \
--cc=anthony@codemonkey.ws \
--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