aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux/kvm_host.h
diff options
context:
space:
mode:
authorGregory Haskins <ghaskins@novell.com>2009-07-07 17:08:49 -0400
committerAvi Kivity <avi@redhat.com>2009-09-10 01:33:12 -0400
commitd34e6b175e61821026893ec5298cc8e7558df43a (patch)
tree8f2934bb0df05d18372509f9ac59aecee5884997 /include/linux/kvm_host.h
parent090b7aff27120cdae76a346a70db394844fea598 (diff)
KVM: add ioeventfd support
ioeventfd is a mechanism to register PIO/MMIO regions to trigger an eventfd signal when written to by a guest. Host userspace can register any arbitrary IO address with a corresponding eventfd and then pass the eventfd to a specific end-point of interest for handling. Normal IO requires a blocking round-trip since the operation may cause side-effects in the emulated model or may return data to the caller. Therefore, an IO in KVM traps from the guest to the host, causes a VMX/SVM "heavy-weight" exit back to userspace, and is ultimately serviced by qemu's device model synchronously before returning control back to the vcpu. However, there is a subclass of IO which acts purely as a trigger for other IO (such as to kick off an out-of-band DMA request, etc). For these patterns, the synchronous call is particularly expensive since we really only want to simply get our notification transmitted asychronously and return as quickly as possible. All the sychronous infrastructure to ensure proper data-dependencies are met in the normal IO case are just unecessary overhead for signalling. This adds additional computational load on the system, as well as latency to the signalling path. Therefore, we provide a mechanism for registration of an in-kernel trigger point that allows the VCPU to only require a very brief, lightweight exit just long enough to signal an eventfd. This also means that any clients compatible with the eventfd interface (which includes userspace and kernelspace equally well) can now register to be notified. The end result should be a more flexible and higher performance notification API for the backend KVM hypervisor and perhipheral components. To test this theory, we built a test-harness called "doorbell". This module has a function called "doorbell_ring()" which simply increments a counter for each time the doorbell is signaled. It supports signalling from either an eventfd, or an ioctl(). We then wired up two paths to the doorbell: One via QEMU via a registered io region and through the doorbell ioctl(). The other is direct via ioeventfd. You can download this test harness here: ftp://ftp.novell.com/dev/ghaskins/doorbell.tar.bz2 The measured results are as follows: qemu-mmio: 110000 iops, 9.09us rtt ioeventfd-mmio: 200100 iops, 5.00us rtt ioeventfd-pio: 367300 iops, 2.72us rtt I didn't measure qemu-pio, because I have to figure out how to register a PIO region with qemu's device model, and I got lazy. However, for now we can extrapolate based on the data from the NULLIO runs of +2.56us for MMIO, and -350ns for HC, we get: qemu-pio: 153139 iops, 6.53us rtt ioeventfd-hc: 412585 iops, 2.37us rtt these are just for fun, for now, until I can gather more data. Here is a graph for your convenience: http://developer.novell.com/wiki/images/7/76/Iofd-chart.png The conclusion to draw is that we save about 4us by skipping the userspace hop. -------------------- Signed-off-by: Gregory Haskins <ghaskins@novell.com> Acked-by: Michael S. Tsirkin <mst@redhat.com> Signed-off-by: Avi Kivity <avi@redhat.com>
Diffstat (limited to 'include/linux/kvm_host.h')
-rw-r--r--include/linux/kvm_host.h10
1 files changed, 8 insertions, 2 deletions
diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
index 983b0bdeb3ff..6ec9fc56a49e 100644
--- a/include/linux/kvm_host.h
+++ b/include/linux/kvm_host.h
@@ -155,6 +155,7 @@ struct kvm {
155 spinlock_t lock; 155 spinlock_t lock;
156 struct list_head items; 156 struct list_head items;
157 } irqfds; 157 } irqfds;
158 struct list_head ioeventfds;
158#endif 159#endif
159 struct kvm_vm_stat stat; 160 struct kvm_vm_stat stat;
160 struct kvm_arch arch; 161 struct kvm_arch arch;
@@ -528,19 +529,24 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {}
528 529
529#ifdef CONFIG_HAVE_KVM_EVENTFD 530#ifdef CONFIG_HAVE_KVM_EVENTFD
530 531
531void kvm_irqfd_init(struct kvm *kvm); 532void kvm_eventfd_init(struct kvm *kvm);
532int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags); 533int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags);
533void kvm_irqfd_release(struct kvm *kvm); 534void kvm_irqfd_release(struct kvm *kvm);
535int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args);
534 536
535#else 537#else
536 538
537static inline void kvm_irqfd_init(struct kvm *kvm) {} 539static inline void kvm_eventfd_init(struct kvm *kvm) {}
538static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags) 540static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags)
539{ 541{
540 return -EINVAL; 542 return -EINVAL;
541} 543}
542 544
543static inline void kvm_irqfd_release(struct kvm *kvm) {} 545static inline void kvm_irqfd_release(struct kvm *kvm) {}
546static inline int kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
547{
548 return -ENOSYS;
549}
544 550
545#endif /* CONFIG_HAVE_KVM_EVENTFD */ 551#endif /* CONFIG_HAVE_KVM_EVENTFD */
546 552