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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
