2009-05-20 08:30:49 -06:00
|
|
|
/*
|
|
|
|
* kvm eventfd support - use eventfd objects to signal various KVM events
|
|
|
|
*
|
|
|
|
* Copyright 2009 Novell. All Rights Reserved.
|
2010-05-23 09:37:00 -06:00
|
|
|
* Copyright 2010 Red Hat, Inc. and/or its affiliates.
|
2009-05-20 08:30:49 -06:00
|
|
|
*
|
|
|
|
* Author:
|
|
|
|
* Gregory Haskins <ghaskins@novell.com>
|
|
|
|
*
|
|
|
|
* This file is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of version 2 of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software Foundation,
|
|
|
|
* Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301, USA.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kvm_host.h>
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
#include <linux/kvm.h>
|
2009-05-20 08:30:49 -06:00
|
|
|
#include <linux/workqueue.h>
|
|
|
|
#include <linux/syscalls.h>
|
|
|
|
#include <linux/wait.h>
|
|
|
|
#include <linux/poll.h>
|
|
|
|
#include <linux/file.h>
|
|
|
|
#include <linux/list.h>
|
|
|
|
#include <linux/eventfd.h>
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
#include <linux/kernel.h>
|
2014-01-16 05:44:20 -07:00
|
|
|
#include <linux/srcu.h>
|
include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
percpu.h is included by sched.h and module.h and thus ends up being
included when building most .c files. percpu.h includes slab.h which
in turn includes gfp.h making everything defined by the two files
universally available and complicating inclusion dependencies.
percpu.h -> slab.h dependency is about to be removed. Prepare for
this change by updating users of gfp and slab facilities include those
headers directly instead of assuming availability. As this conversion
needs to touch large number of source files, the following script is
used as the basis of conversion.
http://userweb.kernel.org/~tj/misc/slabh-sweep.py
The script does the followings.
* Scan files for gfp and slab usages and update includes such that
only the necessary includes are there. ie. if only gfp is used,
gfp.h, if slab is used, slab.h.
* When the script inserts a new include, it looks at the include
blocks and try to put the new include such that its order conforms
to its surrounding. It's put in the include block which contains
core kernel includes, in the same order that the rest are ordered -
alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
doesn't seem to be any matching order.
* If the script can't find a place to put a new include (mostly
because the file doesn't have fitting include block), it prints out
an error message indicating which .h file needs to be added to the
file.
The conversion was done in the following steps.
1. The initial automatic conversion of all .c files updated slightly
over 4000 files, deleting around 700 includes and adding ~480 gfp.h
and ~3000 slab.h inclusions. The script emitted errors for ~400
files.
2. Each error was manually checked. Some didn't need the inclusion,
some needed manual addition while adding it to implementation .h or
embedding .c file was more appropriate for others. This step added
inclusions to around 150 files.
3. The script was run again and the output was compared to the edits
from #2 to make sure no file was left behind.
4. Several build tests were done and a couple of problems were fixed.
e.g. lib/decompress_*.c used malloc/free() wrappers around slab
APIs requiring slab.h to be added manually.
5. The script was run on all .h files but without automatically
editing them as sprinkling gfp.h and slab.h inclusions around .h
files could easily lead to inclusion dependency hell. Most gfp.h
inclusion directives were ignored as stuff from gfp.h was usually
wildly available and often used in preprocessor macros. Each
slab.h inclusion directive was examined and added manually as
necessary.
6. percpu.h was updated not to include slab.h.
7. Build test were done on the following configurations and failures
were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
distributed build env didn't work with gcov compiles) and a few
more options had to be turned off depending on archs to make things
build (like ipr on powerpc/64 which failed due to missing writeq).
* x86 and x86_64 UP and SMP allmodconfig and a custom test config.
* powerpc and powerpc64 SMP allmodconfig
* sparc and sparc64 SMP allmodconfig
* ia64 SMP allmodconfig
* s390 SMP allmodconfig
* alpha SMP allmodconfig
* um on x86_64 SMP allmodconfig
8. percpu.h modifications were reverted so that it could be applied as
a separate patch and serve as bisection point.
Given the fact that I had only a couple of failures from tests on step
6, I'm fairly confident about the coverage of this conversion patch.
If there is a breakage, it's likely to be something in one of the arch
headers which should be easily discoverable easily on most builds of
the specific arch.
Signed-off-by: Tejun Heo <tj@kernel.org>
Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
2010-03-24 02:04:11 -06:00
|
|
|
#include <linux/slab.h>
|
2014-06-30 04:51:09 -06:00
|
|
|
#include <linux/seqlock.h>
|
2014-06-30 04:51:12 -06:00
|
|
|
#include <trace/events/kvm.h>
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
|
2015-03-26 08:39:29 -06:00
|
|
|
#include <kvm/iodev.h>
|
2009-05-20 08:30:49 -06:00
|
|
|
|
2014-06-30 04:51:13 -06:00
|
|
|
#ifdef CONFIG_HAVE_KVM_IRQFD
|
2009-05-20 08:30:49 -06:00
|
|
|
/*
|
|
|
|
* --------------------------------------------------------------------
|
|
|
|
* irqfd: Allows an fd to be used to inject an interrupt to the guest
|
|
|
|
*
|
|
|
|
* Credit goes to Avi Kivity for the original idea.
|
|
|
|
* --------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
2012-09-21 11:58:03 -06:00
|
|
|
/*
|
|
|
|
* Resampling irqfds are a special variety of irqfds used to emulate
|
|
|
|
* level triggered interrupts. The interrupt is asserted on eventfd
|
|
|
|
* trigger. On acknowledgement through the irq ack notifier, the
|
|
|
|
* interrupt is de-asserted and userspace is notified through the
|
|
|
|
* resamplefd. All resamplers on the same gsi are de-asserted
|
|
|
|
* together, so we don't need to track the state of each individual
|
|
|
|
* user. We can also therefore share the same irq source ID.
|
|
|
|
*/
|
|
|
|
struct _irqfd_resampler {
|
|
|
|
struct kvm *kvm;
|
|
|
|
/*
|
|
|
|
* List of resampling struct _irqfd objects sharing this gsi.
|
|
|
|
* RCU list modified under kvm->irqfds.resampler_lock
|
|
|
|
*/
|
|
|
|
struct list_head list;
|
|
|
|
struct kvm_irq_ack_notifier notifier;
|
|
|
|
/*
|
|
|
|
* Entry in list of kvm->irqfd.resampler_list. Use for sharing
|
|
|
|
* resamplers among irqfds on the same gsi.
|
|
|
|
* Accessed and modified under kvm->irqfds.resampler_lock
|
|
|
|
*/
|
|
|
|
struct list_head link;
|
|
|
|
};
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
struct _irqfd {
|
2010-11-18 10:09:08 -07:00
|
|
|
/* Used for MSI fast-path */
|
|
|
|
struct kvm *kvm;
|
|
|
|
wait_queue_t wait;
|
|
|
|
/* Update side is protected by irqfds.lock */
|
2014-06-30 04:51:09 -06:00
|
|
|
struct kvm_kernel_irq_routing_entry irq_entry;
|
|
|
|
seqcount_t irq_entry_sc;
|
2010-11-18 10:09:08 -07:00
|
|
|
/* Used for level IRQ fast-path */
|
|
|
|
int gsi;
|
|
|
|
struct work_struct inject;
|
2012-09-21 11:58:03 -06:00
|
|
|
/* The resampler used by this irqfd (resampler-only) */
|
|
|
|
struct _irqfd_resampler *resampler;
|
|
|
|
/* Eventfd notified on resample (resampler-only) */
|
|
|
|
struct eventfd_ctx *resamplefd;
|
|
|
|
/* Entry in list of irqfds for a resampler (resampler-only) */
|
|
|
|
struct list_head resampler_link;
|
2010-11-18 10:09:08 -07:00
|
|
|
/* Used for setup/shutdown */
|
|
|
|
struct eventfd_ctx *eventfd;
|
|
|
|
struct list_head list;
|
|
|
|
poll_table pt;
|
|
|
|
struct work_struct shutdown;
|
2009-05-20 08:30:49 -06:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct workqueue_struct *irqfd_cleanup_wq;
|
|
|
|
|
|
|
|
static void
|
|
|
|
irqfd_inject(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
|
|
|
|
struct kvm *kvm = irqfd->kvm;
|
|
|
|
|
2012-09-21 11:58:03 -06:00
|
|
|
if (!irqfd->resampler) {
|
2013-04-11 05:21:40 -06:00
|
|
|
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1,
|
|
|
|
false);
|
|
|
|
kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0,
|
|
|
|
false);
|
2012-09-21 11:58:03 -06:00
|
|
|
} else
|
|
|
|
kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
|
2013-04-11 05:21:40 -06:00
|
|
|
irqfd->gsi, 1, false);
|
2012-09-21 11:58:03 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since resampler irqfds share an IRQ source ID, we de-assert once
|
|
|
|
* then notify all of the resampler irqfds using this GSI. We can't
|
|
|
|
* do multiple de-asserts or we risk racing with incoming re-asserts.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
irqfd_resampler_ack(struct kvm_irq_ack_notifier *kian)
|
|
|
|
{
|
|
|
|
struct _irqfd_resampler *resampler;
|
2014-01-16 05:44:20 -07:00
|
|
|
struct kvm *kvm;
|
2012-09-21 11:58:03 -06:00
|
|
|
struct _irqfd *irqfd;
|
2014-01-16 05:44:20 -07:00
|
|
|
int idx;
|
2012-09-21 11:58:03 -06:00
|
|
|
|
|
|
|
resampler = container_of(kian, struct _irqfd_resampler, notifier);
|
2014-01-16 05:44:20 -07:00
|
|
|
kvm = resampler->kvm;
|
2012-09-21 11:58:03 -06:00
|
|
|
|
2014-01-16 05:44:20 -07:00
|
|
|
kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
|
2013-04-11 05:21:40 -06:00
|
|
|
resampler->notifier.gsi, 0, false);
|
2012-09-21 11:58:03 -06:00
|
|
|
|
2014-01-16 05:44:20 -07:00
|
|
|
idx = srcu_read_lock(&kvm->irq_srcu);
|
2012-09-21 11:58:03 -06:00
|
|
|
|
|
|
|
list_for_each_entry_rcu(irqfd, &resampler->list, resampler_link)
|
|
|
|
eventfd_signal(irqfd->resamplefd, 1);
|
|
|
|
|
2014-01-16 05:44:20 -07:00
|
|
|
srcu_read_unlock(&kvm->irq_srcu, idx);
|
2012-09-21 11:58:03 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
irqfd_resampler_shutdown(struct _irqfd *irqfd)
|
|
|
|
{
|
|
|
|
struct _irqfd_resampler *resampler = irqfd->resampler;
|
|
|
|
struct kvm *kvm = resampler->kvm;
|
|
|
|
|
|
|
|
mutex_lock(&kvm->irqfds.resampler_lock);
|
|
|
|
|
|
|
|
list_del_rcu(&irqfd->resampler_link);
|
2014-01-16 05:44:20 -07:00
|
|
|
synchronize_srcu(&kvm->irq_srcu);
|
2012-09-21 11:58:03 -06:00
|
|
|
|
|
|
|
if (list_empty(&resampler->list)) {
|
|
|
|
list_del(&resampler->link);
|
|
|
|
kvm_unregister_irq_ack_notifier(kvm, &resampler->notifier);
|
|
|
|
kvm_set_irq(kvm, KVM_IRQFD_RESAMPLE_IRQ_SOURCE_ID,
|
2013-04-11 05:21:40 -06:00
|
|
|
resampler->notifier.gsi, 0, false);
|
2012-09-21 11:58:03 -06:00
|
|
|
kfree(resampler);
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&kvm->irqfds.resampler_lock);
|
2009-05-20 08:30:49 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Race-free decouple logic (ordering is critical)
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
irqfd_shutdown(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct _irqfd *irqfd = container_of(work, struct _irqfd, shutdown);
|
2010-01-13 10:12:30 -07:00
|
|
|
u64 cnt;
|
2009-05-20 08:30:49 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Synchronize with the wait-queue and unhook ourselves to prevent
|
|
|
|
* further events.
|
|
|
|
*/
|
2010-01-13 10:12:30 -07:00
|
|
|
eventfd_ctx_remove_wait_queue(irqfd->eventfd, &irqfd->wait, &cnt);
|
2009-05-20 08:30:49 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We know no new events will be scheduled at this point, so block
|
|
|
|
* until all previously outstanding events have completed
|
|
|
|
*/
|
2012-08-20 15:51:24 -06:00
|
|
|
flush_work(&irqfd->inject);
|
2009-05-20 08:30:49 -06:00
|
|
|
|
2012-09-21 11:58:03 -06:00
|
|
|
if (irqfd->resampler) {
|
|
|
|
irqfd_resampler_shutdown(irqfd);
|
|
|
|
eventfd_ctx_put(irqfd->resamplefd);
|
|
|
|
}
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
/*
|
|
|
|
* It is now safe to release the object's resources
|
|
|
|
*/
|
|
|
|
eventfd_ctx_put(irqfd->eventfd);
|
|
|
|
kfree(irqfd);
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/* assumes kvm->irqfds.lock is held */
|
|
|
|
static bool
|
|
|
|
irqfd_is_active(struct _irqfd *irqfd)
|
|
|
|
{
|
|
|
|
return list_empty(&irqfd->list) ? false : true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Mark the irqfd as inactive and schedule it for removal
|
|
|
|
*
|
|
|
|
* assumes kvm->irqfds.lock is held
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
irqfd_deactivate(struct _irqfd *irqfd)
|
|
|
|
{
|
|
|
|
BUG_ON(!irqfd_is_active(irqfd));
|
|
|
|
|
|
|
|
list_del_init(&irqfd->list);
|
|
|
|
|
|
|
|
queue_work(irqfd_cleanup_wq, &irqfd->shutdown);
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called with wqh->lock held and interrupts disabled
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
irqfd_wakeup(wait_queue_t *wait, unsigned mode, int sync, void *key)
|
|
|
|
{
|
|
|
|
struct _irqfd *irqfd = container_of(wait, struct _irqfd, wait);
|
|
|
|
unsigned long flags = (unsigned long)key;
|
2014-06-30 04:51:09 -06:00
|
|
|
struct kvm_kernel_irq_routing_entry irq;
|
2010-11-18 10:09:08 -07:00
|
|
|
struct kvm *kvm = irqfd->kvm;
|
2014-06-30 04:51:09 -06:00
|
|
|
unsigned seq;
|
2014-01-16 05:44:20 -07:00
|
|
|
int idx;
|
2009-05-20 08:30:49 -06:00
|
|
|
|
2010-11-18 10:09:08 -07:00
|
|
|
if (flags & POLLIN) {
|
2014-01-16 05:44:20 -07:00
|
|
|
idx = srcu_read_lock(&kvm->irq_srcu);
|
2014-06-30 04:51:09 -06:00
|
|
|
do {
|
|
|
|
seq = read_seqcount_begin(&irqfd->irq_entry_sc);
|
|
|
|
irq = irqfd->irq_entry;
|
|
|
|
} while (read_seqcount_retry(&irqfd->irq_entry_sc, seq));
|
2009-05-20 08:30:49 -06:00
|
|
|
/* An event has been signaled, inject an interrupt */
|
2014-06-30 04:51:09 -06:00
|
|
|
if (irq.type == KVM_IRQ_ROUTING_MSI)
|
|
|
|
kvm_set_msi(&irq, kvm, KVM_USERSPACE_IRQ_SOURCE_ID, 1,
|
2013-04-11 05:21:40 -06:00
|
|
|
false);
|
2010-11-18 10:09:08 -07:00
|
|
|
else
|
|
|
|
schedule_work(&irqfd->inject);
|
2014-01-16 05:44:20 -07:00
|
|
|
srcu_read_unlock(&kvm->irq_srcu, idx);
|
2010-11-18 10:09:08 -07:00
|
|
|
}
|
2009-05-20 08:30:49 -06:00
|
|
|
|
|
|
|
if (flags & POLLHUP) {
|
|
|
|
/* The eventfd is closing, detach from KVM */
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
spin_lock_irqsave(&kvm->irqfds.lock, flags);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We must check if someone deactivated the irqfd before
|
|
|
|
* we could acquire the irqfds.lock since the item is
|
|
|
|
* deactivated from the KVM side before it is unhooked from
|
|
|
|
* the wait-queue. If it is already deactivated, we can
|
|
|
|
* simply return knowing the other side will cleanup for us.
|
|
|
|
* We cannot race against the irqfd going away since the
|
|
|
|
* other side is required to acquire wqh->lock, which we hold
|
|
|
|
*/
|
|
|
|
if (irqfd_is_active(irqfd))
|
|
|
|
irqfd_deactivate(irqfd);
|
|
|
|
|
|
|
|
spin_unlock_irqrestore(&kvm->irqfds.lock, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
irqfd_ptable_queue_proc(struct file *file, wait_queue_head_t *wqh,
|
|
|
|
poll_table *pt)
|
|
|
|
{
|
|
|
|
struct _irqfd *irqfd = container_of(pt, struct _irqfd, pt);
|
|
|
|
add_wait_queue(wqh, &irqfd->wait);
|
|
|
|
}
|
|
|
|
|
2010-11-18 10:09:08 -07:00
|
|
|
/* Must be called under irqfds.lock */
|
2014-06-30 04:51:11 -06:00
|
|
|
static void irqfd_update(struct kvm *kvm, struct _irqfd *irqfd)
|
2010-11-18 10:09:08 -07:00
|
|
|
{
|
|
|
|
struct kvm_kernel_irq_routing_entry *e;
|
2014-06-30 04:51:10 -06:00
|
|
|
struct kvm_kernel_irq_routing_entry entries[KVM_NR_IRQCHIPS];
|
|
|
|
int i, n_entries;
|
|
|
|
|
2014-06-30 04:51:11 -06:00
|
|
|
n_entries = kvm_irq_map_gsi(kvm, entries, irqfd->gsi);
|
2010-11-18 10:09:08 -07:00
|
|
|
|
2014-06-30 04:51:09 -06:00
|
|
|
write_seqcount_begin(&irqfd->irq_entry_sc);
|
|
|
|
|
|
|
|
irqfd->irq_entry.type = 0;
|
2010-11-18 10:09:08 -07:00
|
|
|
|
2014-06-30 04:51:10 -06:00
|
|
|
e = entries;
|
|
|
|
for (i = 0; i < n_entries; ++i, ++e) {
|
2010-11-18 10:09:08 -07:00
|
|
|
/* Only fast-path MSI. */
|
|
|
|
if (e->type == KVM_IRQ_ROUTING_MSI)
|
2014-06-30 04:51:09 -06:00
|
|
|
irqfd->irq_entry = *e;
|
2010-11-18 10:09:08 -07:00
|
|
|
}
|
2014-06-30 04:51:09 -06:00
|
|
|
|
|
|
|
write_seqcount_end(&irqfd->irq_entry_sc);
|
2010-11-18 10:09:08 -07:00
|
|
|
}
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
static int
|
2012-06-29 09:56:08 -06:00
|
|
|
kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
|
2009-05-20 08:30:49 -06:00
|
|
|
{
|
2010-01-13 09:58:09 -07:00
|
|
|
struct _irqfd *irqfd, *tmp;
|
2013-08-30 13:47:17 -06:00
|
|
|
struct fd f;
|
2012-09-21 11:58:03 -06:00
|
|
|
struct eventfd_ctx *eventfd = NULL, *resamplefd = NULL;
|
2009-05-20 08:30:49 -06:00
|
|
|
int ret;
|
|
|
|
unsigned int events;
|
2014-06-30 04:51:11 -06:00
|
|
|
int idx;
|
2009-05-20 08:30:49 -06:00
|
|
|
|
2015-03-04 03:14:33 -07:00
|
|
|
if (!kvm_arch_intc_initialized(kvm))
|
|
|
|
return -EAGAIN;
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
irqfd = kzalloc(sizeof(*irqfd), GFP_KERNEL);
|
|
|
|
if (!irqfd)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
irqfd->kvm = kvm;
|
2012-06-29 09:56:08 -06:00
|
|
|
irqfd->gsi = args->gsi;
|
2009-05-20 08:30:49 -06:00
|
|
|
INIT_LIST_HEAD(&irqfd->list);
|
|
|
|
INIT_WORK(&irqfd->inject, irqfd_inject);
|
|
|
|
INIT_WORK(&irqfd->shutdown, irqfd_shutdown);
|
2014-06-30 04:51:09 -06:00
|
|
|
seqcount_init(&irqfd->irq_entry_sc);
|
2009-05-20 08:30:49 -06:00
|
|
|
|
2013-08-30 13:47:17 -06:00
|
|
|
f = fdget(args->fd);
|
|
|
|
if (!f.file) {
|
|
|
|
ret = -EBADF;
|
|
|
|
goto out;
|
2009-05-20 08:30:49 -06:00
|
|
|
}
|
|
|
|
|
2013-08-30 13:47:17 -06:00
|
|
|
eventfd = eventfd_ctx_fileget(f.file);
|
2009-05-20 08:30:49 -06:00
|
|
|
if (IS_ERR(eventfd)) {
|
|
|
|
ret = PTR_ERR(eventfd);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
irqfd->eventfd = eventfd;
|
|
|
|
|
2012-09-21 11:58:03 -06:00
|
|
|
if (args->flags & KVM_IRQFD_FLAG_RESAMPLE) {
|
|
|
|
struct _irqfd_resampler *resampler;
|
|
|
|
|
|
|
|
resamplefd = eventfd_ctx_fdget(args->resamplefd);
|
|
|
|
if (IS_ERR(resamplefd)) {
|
|
|
|
ret = PTR_ERR(resamplefd);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
irqfd->resamplefd = resamplefd;
|
|
|
|
INIT_LIST_HEAD(&irqfd->resampler_link);
|
|
|
|
|
|
|
|
mutex_lock(&kvm->irqfds.resampler_lock);
|
|
|
|
|
|
|
|
list_for_each_entry(resampler,
|
2012-12-06 14:44:59 -07:00
|
|
|
&kvm->irqfds.resampler_list, link) {
|
2012-09-21 11:58:03 -06:00
|
|
|
if (resampler->notifier.gsi == irqfd->gsi) {
|
|
|
|
irqfd->resampler = resampler;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!irqfd->resampler) {
|
|
|
|
resampler = kzalloc(sizeof(*resampler), GFP_KERNEL);
|
|
|
|
if (!resampler) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
mutex_unlock(&kvm->irqfds.resampler_lock);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
resampler->kvm = kvm;
|
|
|
|
INIT_LIST_HEAD(&resampler->list);
|
|
|
|
resampler->notifier.gsi = irqfd->gsi;
|
|
|
|
resampler->notifier.irq_acked = irqfd_resampler_ack;
|
|
|
|
INIT_LIST_HEAD(&resampler->link);
|
|
|
|
|
|
|
|
list_add(&resampler->link, &kvm->irqfds.resampler_list);
|
|
|
|
kvm_register_irq_ack_notifier(kvm,
|
|
|
|
&resampler->notifier);
|
|
|
|
irqfd->resampler = resampler;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_add_rcu(&irqfd->resampler_link, &irqfd->resampler->list);
|
2014-01-16 05:44:20 -07:00
|
|
|
synchronize_srcu(&kvm->irq_srcu);
|
2012-09-21 11:58:03 -06:00
|
|
|
|
|
|
|
mutex_unlock(&kvm->irqfds.resampler_lock);
|
|
|
|
}
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
/*
|
|
|
|
* Install our own custom wake-up handling so we are notified via
|
|
|
|
* a callback whenever someone signals the underlying eventfd
|
|
|
|
*/
|
|
|
|
init_waitqueue_func_entry(&irqfd->wait, irqfd_wakeup);
|
|
|
|
init_poll_funcptr(&irqfd->pt, irqfd_ptable_queue_proc);
|
|
|
|
|
2010-01-13 09:58:09 -07:00
|
|
|
spin_lock_irq(&kvm->irqfds.lock);
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
list_for_each_entry(tmp, &kvm->irqfds.items, list) {
|
|
|
|
if (irqfd->eventfd != tmp->eventfd)
|
|
|
|
continue;
|
|
|
|
/* This fd is used for another irq already. */
|
|
|
|
ret = -EBUSY;
|
|
|
|
spin_unlock_irq(&kvm->irqfds.lock);
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
2014-06-30 04:51:11 -06:00
|
|
|
idx = srcu_read_lock(&kvm->irq_srcu);
|
|
|
|
irqfd_update(kvm, irqfd);
|
|
|
|
srcu_read_unlock(&kvm->irq_srcu, idx);
|
2010-11-18 10:09:08 -07:00
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
list_add_tail(&irqfd->list, &kvm->irqfds.items);
|
|
|
|
|
2014-03-17 12:11:35 -06:00
|
|
|
spin_unlock_irq(&kvm->irqfds.lock);
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
/*
|
|
|
|
* Check if there was an event already pending on the eventfd
|
|
|
|
* before we registered, and trigger it as if we didn't miss it.
|
|
|
|
*/
|
2014-03-17 12:11:35 -06:00
|
|
|
events = f.file->f_op->poll(f.file, &irqfd->pt);
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
if (events & POLLIN)
|
|
|
|
schedule_work(&irqfd->inject);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* do not drop the file until the irqfd is fully initialized, otherwise
|
|
|
|
* we might race against the POLLHUP
|
|
|
|
*/
|
2013-08-30 13:47:17 -06:00
|
|
|
fdput(f);
|
2009-05-20 08:30:49 -06:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
fail:
|
2012-09-21 11:58:03 -06:00
|
|
|
if (irqfd->resampler)
|
|
|
|
irqfd_resampler_shutdown(irqfd);
|
|
|
|
|
|
|
|
if (resamplefd && !IS_ERR(resamplefd))
|
|
|
|
eventfd_ctx_put(resamplefd);
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
if (eventfd && !IS_ERR(eventfd))
|
|
|
|
eventfd_ctx_put(eventfd);
|
|
|
|
|
2013-08-30 13:47:17 -06:00
|
|
|
fdput(f);
|
2009-05-20 08:30:49 -06:00
|
|
|
|
2013-08-30 13:47:17 -06:00
|
|
|
out:
|
2009-05-20 08:30:49 -06:00
|
|
|
kfree(irqfd);
|
|
|
|
return ret;
|
|
|
|
}
|
2014-08-06 06:24:45 -06:00
|
|
|
|
|
|
|
bool kvm_irq_has_notifier(struct kvm *kvm, unsigned irqchip, unsigned pin)
|
|
|
|
{
|
|
|
|
struct kvm_irq_ack_notifier *kian;
|
|
|
|
int gsi, idx;
|
|
|
|
|
|
|
|
idx = srcu_read_lock(&kvm->irq_srcu);
|
|
|
|
gsi = kvm_irq_map_chip_pin(kvm, irqchip, pin);
|
|
|
|
if (gsi != -1)
|
|
|
|
hlist_for_each_entry_rcu(kian, &kvm->irq_ack_notifier_list,
|
|
|
|
link)
|
|
|
|
if (kian->gsi == gsi) {
|
|
|
|
srcu_read_unlock(&kvm->irq_srcu, idx);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
srcu_read_unlock(&kvm->irq_srcu, idx);
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(kvm_irq_has_notifier);
|
|
|
|
|
|
|
|
void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
|
|
|
|
{
|
|
|
|
struct kvm_irq_ack_notifier *kian;
|
|
|
|
int gsi, idx;
|
|
|
|
|
|
|
|
trace_kvm_ack_irq(irqchip, pin);
|
|
|
|
|
|
|
|
idx = srcu_read_lock(&kvm->irq_srcu);
|
|
|
|
gsi = kvm_irq_map_chip_pin(kvm, irqchip, pin);
|
|
|
|
if (gsi != -1)
|
|
|
|
hlist_for_each_entry_rcu(kian, &kvm->irq_ack_notifier_list,
|
|
|
|
link)
|
|
|
|
if (kian->gsi == gsi)
|
|
|
|
kian->irq_acked(kian);
|
|
|
|
srcu_read_unlock(&kvm->irq_srcu, idx);
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_register_irq_ack_notifier(struct kvm *kvm,
|
|
|
|
struct kvm_irq_ack_notifier *kian)
|
|
|
|
{
|
|
|
|
mutex_lock(&kvm->irq_lock);
|
|
|
|
hlist_add_head_rcu(&kian->link, &kvm->irq_ack_notifier_list);
|
|
|
|
mutex_unlock(&kvm->irq_lock);
|
|
|
|
kvm_vcpu_request_scan_ioapic(kvm);
|
|
|
|
}
|
|
|
|
|
|
|
|
void kvm_unregister_irq_ack_notifier(struct kvm *kvm,
|
|
|
|
struct kvm_irq_ack_notifier *kian)
|
|
|
|
{
|
|
|
|
mutex_lock(&kvm->irq_lock);
|
|
|
|
hlist_del_init_rcu(&kian->link);
|
|
|
|
mutex_unlock(&kvm->irq_lock);
|
|
|
|
synchronize_srcu(&kvm->irq_srcu);
|
|
|
|
kvm_vcpu_request_scan_ioapic(kvm);
|
|
|
|
}
|
2012-10-08 16:22:59 -06:00
|
|
|
#endif
|
2009-05-20 08:30:49 -06:00
|
|
|
|
|
|
|
void
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
kvm_eventfd_init(struct kvm *kvm)
|
2009-05-20 08:30:49 -06:00
|
|
|
{
|
2014-06-30 04:51:13 -06:00
|
|
|
#ifdef CONFIG_HAVE_KVM_IRQFD
|
2009-05-20 08:30:49 -06:00
|
|
|
spin_lock_init(&kvm->irqfds.lock);
|
|
|
|
INIT_LIST_HEAD(&kvm->irqfds.items);
|
2012-09-21 11:58:03 -06:00
|
|
|
INIT_LIST_HEAD(&kvm->irqfds.resampler_list);
|
|
|
|
mutex_init(&kvm->irqfds.resampler_lock);
|
2012-10-08 16:22:59 -06:00
|
|
|
#endif
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
INIT_LIST_HEAD(&kvm->ioeventfds);
|
2009-05-20 08:30:49 -06:00
|
|
|
}
|
|
|
|
|
2014-06-30 04:51:13 -06:00
|
|
|
#ifdef CONFIG_HAVE_KVM_IRQFD
|
2009-05-20 08:30:49 -06:00
|
|
|
/*
|
|
|
|
* shutdown any irqfd's that match fd+gsi
|
|
|
|
*/
|
|
|
|
static int
|
2012-06-29 09:56:08 -06:00
|
|
|
kvm_irqfd_deassign(struct kvm *kvm, struct kvm_irqfd *args)
|
2009-05-20 08:30:49 -06:00
|
|
|
{
|
|
|
|
struct _irqfd *irqfd, *tmp;
|
|
|
|
struct eventfd_ctx *eventfd;
|
|
|
|
|
2012-06-29 09:56:08 -06:00
|
|
|
eventfd = eventfd_ctx_fdget(args->fd);
|
2009-05-20 08:30:49 -06:00
|
|
|
if (IS_ERR(eventfd))
|
|
|
|
return PTR_ERR(eventfd);
|
|
|
|
|
|
|
|
spin_lock_irq(&kvm->irqfds.lock);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds.items, list) {
|
2012-06-29 09:56:08 -06:00
|
|
|
if (irqfd->eventfd == eventfd && irqfd->gsi == args->gsi) {
|
2010-11-18 10:09:08 -07:00
|
|
|
/*
|
2014-06-30 04:51:09 -06:00
|
|
|
* This clearing of irq_entry.type is needed for when
|
2011-03-06 04:03:26 -07:00
|
|
|
* another thread calls kvm_irq_routing_update before
|
|
|
|
* we flush workqueue below (we synchronize with
|
|
|
|
* kvm_irq_routing_update using irqfds.lock).
|
2010-11-18 10:09:08 -07:00
|
|
|
*/
|
2014-06-30 04:51:09 -06:00
|
|
|
write_seqcount_begin(&irqfd->irq_entry_sc);
|
|
|
|
irqfd->irq_entry.type = 0;
|
|
|
|
write_seqcount_end(&irqfd->irq_entry_sc);
|
2009-05-20 08:30:49 -06:00
|
|
|
irqfd_deactivate(irqfd);
|
2010-11-18 10:09:08 -07:00
|
|
|
}
|
2009-05-20 08:30:49 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
spin_unlock_irq(&kvm->irqfds.lock);
|
|
|
|
eventfd_ctx_put(eventfd);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Block until we know all outstanding shutdown jobs have completed
|
|
|
|
* so that we guarantee there will not be any more interrupts on this
|
|
|
|
* gsi once this deassign function returns.
|
|
|
|
*/
|
|
|
|
flush_workqueue(irqfd_cleanup_wq);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
2012-06-29 09:56:08 -06:00
|
|
|
kvm_irqfd(struct kvm *kvm, struct kvm_irqfd *args)
|
2009-05-20 08:30:49 -06:00
|
|
|
{
|
2012-09-21 11:58:03 -06:00
|
|
|
if (args->flags & ~(KVM_IRQFD_FLAG_DEASSIGN | KVM_IRQFD_FLAG_RESAMPLE))
|
2012-06-29 09:56:24 -06:00
|
|
|
return -EINVAL;
|
|
|
|
|
2012-06-29 09:56:08 -06:00
|
|
|
if (args->flags & KVM_IRQFD_FLAG_DEASSIGN)
|
|
|
|
return kvm_irqfd_deassign(kvm, args);
|
2009-05-20 08:30:49 -06:00
|
|
|
|
2012-06-29 09:56:08 -06:00
|
|
|
return kvm_irqfd_assign(kvm, args);
|
2009-05-20 08:30:49 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function is called as the kvm VM fd is being released. Shutdown all
|
|
|
|
* irqfds that still remain open
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
kvm_irqfd_release(struct kvm *kvm)
|
|
|
|
{
|
|
|
|
struct _irqfd *irqfd, *tmp;
|
|
|
|
|
|
|
|
spin_lock_irq(&kvm->irqfds.lock);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds.items, list)
|
|
|
|
irqfd_deactivate(irqfd);
|
|
|
|
|
|
|
|
spin_unlock_irq(&kvm->irqfds.lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Block until we know all outstanding shutdown jobs have completed
|
|
|
|
* since we do not take a kvm* reference.
|
|
|
|
*/
|
|
|
|
flush_workqueue(irqfd_cleanup_wq);
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2010-11-18 10:09:08 -07:00
|
|
|
/*
|
2014-06-30 04:51:11 -06:00
|
|
|
* Take note of a change in irq routing.
|
2014-01-16 05:44:20 -07:00
|
|
|
* Caller must invoke synchronize_srcu(&kvm->irq_srcu) afterwards.
|
2010-11-18 10:09:08 -07:00
|
|
|
*/
|
2014-06-30 04:51:11 -06:00
|
|
|
void kvm_irq_routing_update(struct kvm *kvm)
|
2010-11-18 10:09:08 -07:00
|
|
|
{
|
|
|
|
struct _irqfd *irqfd;
|
|
|
|
|
|
|
|
spin_lock_irq(&kvm->irqfds.lock);
|
|
|
|
|
|
|
|
list_for_each_entry(irqfd, &kvm->irqfds.items, list)
|
2014-06-30 04:51:11 -06:00
|
|
|
irqfd_update(kvm, irqfd);
|
2010-11-18 10:09:08 -07:00
|
|
|
|
|
|
|
spin_unlock_irq(&kvm->irqfds.lock);
|
|
|
|
}
|
|
|
|
|
2009-05-20 08:30:49 -06:00
|
|
|
/*
|
|
|
|
* create a host-wide workqueue for issuing deferred shutdown requests
|
|
|
|
* aggregated from all vm* instances. We need our own isolated single-thread
|
|
|
|
* queue to prevent deadlock against flushing the normal work-queue.
|
|
|
|
*/
|
2013-02-28 04:33:18 -07:00
|
|
|
int kvm_irqfd_init(void)
|
2009-05-20 08:30:49 -06:00
|
|
|
{
|
|
|
|
irqfd_cleanup_wq = create_singlethread_workqueue("kvm-irqfd-cleanup");
|
|
|
|
if (!irqfd_cleanup_wq)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2013-02-28 04:33:18 -07:00
|
|
|
void kvm_irqfd_exit(void)
|
2009-05-20 08:30:49 -06:00
|
|
|
{
|
|
|
|
destroy_workqueue(irqfd_cleanup_wq);
|
|
|
|
}
|
2012-10-08 16:22:59 -06:00
|
|
|
#endif
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
|
|
|
|
/*
|
|
|
|
* --------------------------------------------------------------------
|
|
|
|
* ioeventfd: translate a PIO/MMIO memory write to an eventfd signal.
|
|
|
|
*
|
|
|
|
* userspace can register a PIO/MMIO address with an eventfd for receiving
|
|
|
|
* notification when the memory has been touched.
|
|
|
|
* --------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct _ioeventfd {
|
|
|
|
struct list_head list;
|
|
|
|
u64 addr;
|
|
|
|
int length;
|
|
|
|
struct eventfd_ctx *eventfd;
|
|
|
|
u64 datamatch;
|
|
|
|
struct kvm_io_device dev;
|
2013-04-04 04:27:21 -06:00
|
|
|
u8 bus_idx;
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
bool wildcard;
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline struct _ioeventfd *
|
|
|
|
to_ioeventfd(struct kvm_io_device *dev)
|
|
|
|
{
|
|
|
|
return container_of(dev, struct _ioeventfd, dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
|
|
|
ioeventfd_release(struct _ioeventfd *p)
|
|
|
|
{
|
|
|
|
eventfd_ctx_put(p->eventfd);
|
|
|
|
list_del(&p->list);
|
|
|
|
kfree(p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
|
|
|
ioeventfd_in_range(struct _ioeventfd *p, gpa_t addr, int len, const void *val)
|
|
|
|
{
|
|
|
|
u64 _val;
|
|
|
|
|
2014-03-31 12:50:38 -06:00
|
|
|
if (addr != p->addr)
|
|
|
|
/* address must be precise for a hit */
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!p->length)
|
|
|
|
/* length = 0 means only look at the address, so always a hit */
|
|
|
|
return true;
|
|
|
|
|
|
|
|
if (len != p->length)
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
/* address-range must be precise for a hit */
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (p->wildcard)
|
|
|
|
/* all else equal, wildcard is always a hit */
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* otherwise, we have to actually compare the data */
|
|
|
|
|
|
|
|
BUG_ON(!IS_ALIGNED((unsigned long)val, len));
|
|
|
|
|
|
|
|
switch (len) {
|
|
|
|
case 1:
|
|
|
|
_val = *(u8 *)val;
|
|
|
|
break;
|
|
|
|
case 2:
|
|
|
|
_val = *(u16 *)val;
|
|
|
|
break;
|
|
|
|
case 4:
|
|
|
|
_val = *(u32 *)val;
|
|
|
|
break;
|
|
|
|
case 8:
|
|
|
|
_val = *(u64 *)val;
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return _val == p->datamatch ? true : false;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* MMIO/PIO writes trigger an event if the addr/val match */
|
|
|
|
static int
|
2015-03-26 08:39:28 -06:00
|
|
|
ioeventfd_write(struct kvm_vcpu *vcpu, struct kvm_io_device *this, gpa_t addr,
|
|
|
|
int len, const void *val)
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
{
|
|
|
|
struct _ioeventfd *p = to_ioeventfd(this);
|
|
|
|
|
|
|
|
if (!ioeventfd_in_range(p, addr, len, val))
|
|
|
|
return -EOPNOTSUPP;
|
|
|
|
|
|
|
|
eventfd_signal(p->eventfd, 1);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function is called as KVM is completely shutting down. We do not
|
|
|
|
* need to worry about locking just nuke anything we have as quickly as possible
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ioeventfd_destructor(struct kvm_io_device *this)
|
|
|
|
{
|
|
|
|
struct _ioeventfd *p = to_ioeventfd(this);
|
|
|
|
|
|
|
|
ioeventfd_release(p);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct kvm_io_device_ops ioeventfd_ops = {
|
|
|
|
.write = ioeventfd_write,
|
|
|
|
.destructor = ioeventfd_destructor,
|
|
|
|
};
|
|
|
|
|
|
|
|
/* assumes kvm->slots_lock held */
|
|
|
|
static bool
|
|
|
|
ioeventfd_check_collision(struct kvm *kvm, struct _ioeventfd *p)
|
|
|
|
{
|
|
|
|
struct _ioeventfd *_p;
|
|
|
|
|
|
|
|
list_for_each_entry(_p, &kvm->ioeventfds, list)
|
2013-04-04 04:27:21 -06:00
|
|
|
if (_p->bus_idx == p->bus_idx &&
|
2014-03-31 12:50:38 -06:00
|
|
|
_p->addr == p->addr &&
|
|
|
|
(!_p->length || !p->length ||
|
|
|
|
(_p->length == p->length &&
|
|
|
|
(_p->wildcard || p->wildcard ||
|
|
|
|
_p->datamatch == p->datamatch))))
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-02-28 04:33:20 -07:00
|
|
|
static enum kvm_bus ioeventfd_bus_from_flags(__u32 flags)
|
|
|
|
{
|
|
|
|
if (flags & KVM_IOEVENTFD_FLAG_PIO)
|
|
|
|
return KVM_PIO_BUS;
|
|
|
|
if (flags & KVM_IOEVENTFD_FLAG_VIRTIO_CCW_NOTIFY)
|
|
|
|
return KVM_VIRTIO_CCW_NOTIFY_BUS;
|
|
|
|
return KVM_MMIO_BUS;
|
|
|
|
}
|
|
|
|
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
static int
|
|
|
|
kvm_assign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
|
|
|
|
{
|
2013-02-28 04:33:20 -07:00
|
|
|
enum kvm_bus bus_idx;
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
struct _ioeventfd *p;
|
|
|
|
struct eventfd_ctx *eventfd;
|
|
|
|
int ret;
|
|
|
|
|
2013-02-28 04:33:20 -07:00
|
|
|
bus_idx = ioeventfd_bus_from_flags(args->flags);
|
2014-03-31 12:50:38 -06:00
|
|
|
/* must be natural-word sized, or 0 to ignore length */
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
switch (args->len) {
|
2014-03-31 12:50:38 -06:00
|
|
|
case 0:
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
case 1:
|
|
|
|
case 2:
|
|
|
|
case 4:
|
|
|
|
case 8:
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* check for range overflow */
|
|
|
|
if (args->addr + args->len < args->addr)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* check for extra flags that we don't understand */
|
|
|
|
if (args->flags & ~KVM_IOEVENTFD_VALID_FLAG_MASK)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2014-03-31 12:50:38 -06:00
|
|
|
/* ioeventfd with no length can't be combined with DATAMATCH */
|
|
|
|
if (!args->len &&
|
|
|
|
args->flags & (KVM_IOEVENTFD_FLAG_PIO |
|
|
|
|
KVM_IOEVENTFD_FLAG_DATAMATCH))
|
|
|
|
return -EINVAL;
|
|
|
|
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
eventfd = eventfd_ctx_fdget(args->fd);
|
|
|
|
if (IS_ERR(eventfd))
|
|
|
|
return PTR_ERR(eventfd);
|
|
|
|
|
|
|
|
p = kzalloc(sizeof(*p), GFP_KERNEL);
|
|
|
|
if (!p) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
INIT_LIST_HEAD(&p->list);
|
|
|
|
p->addr = args->addr;
|
2013-04-04 04:27:21 -06:00
|
|
|
p->bus_idx = bus_idx;
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
p->length = args->len;
|
|
|
|
p->eventfd = eventfd;
|
|
|
|
|
|
|
|
/* The datamatch feature is optional, otherwise this is a wildcard */
|
|
|
|
if (args->flags & KVM_IOEVENTFD_FLAG_DATAMATCH)
|
|
|
|
p->datamatch = args->datamatch;
|
|
|
|
else
|
|
|
|
p->wildcard = true;
|
|
|
|
|
2009-12-23 09:35:26 -07:00
|
|
|
mutex_lock(&kvm->slots_lock);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
|
2011-03-30 19:57:33 -06:00
|
|
|
/* Verify that there isn't a match already */
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
if (ioeventfd_check_collision(kvm, p)) {
|
|
|
|
ret = -EEXIST;
|
|
|
|
goto unlock_fail;
|
|
|
|
}
|
|
|
|
|
|
|
|
kvm_iodevice_init(&p->dev, &ioeventfd_ops);
|
|
|
|
|
2011-07-27 07:00:48 -06:00
|
|
|
ret = kvm_io_bus_register_dev(kvm, bus_idx, p->addr, p->length,
|
|
|
|
&p->dev);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
if (ret < 0)
|
|
|
|
goto unlock_fail;
|
|
|
|
|
KVM: VMX: speed up wildcard MMIO EVENTFD
With KVM, MMIO is much slower than PIO, due to the need to
do page walk and emulation. But with EPT, it does not have to be: we
know the address from the VMCS so if the address is unique, we can look
up the eventfd directly, bypassing emulation.
Unfortunately, this only works if userspace does not need to match on
access length and data. The implementation adds a separate FAST_MMIO
bus internally. This serves two purposes:
- minimize overhead for old userspace that does not use eventfd with lengtth = 0
- minimize disruption in other code (since we don't know the length,
devices on the MMIO bus only get a valid address in write, this
way we don't need to touch all devices to teach them to handle
an invalid length)
At the moment, this optimization only has effect for EPT on x86.
It will be possible to speed up MMIO for NPT and MMU using the same
idea in the future.
With this patch applied, on VMX MMIO EVENTFD is essentially as fast as PIO.
I was unable to detect any measureable slowdown to non-eventfd MMIO.
Making MMIO faster is important for the upcoming virtio 1.0 which
includes an MMIO signalling capability.
The idea was suggested by Peter Anvin. Lots of thanks to Gleb for
pre-review and suggestions.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2014-03-31 12:50:44 -06:00
|
|
|
/* When length is ignored, MMIO is also put on a separate bus, for
|
|
|
|
* faster lookups.
|
|
|
|
*/
|
|
|
|
if (!args->len && !(args->flags & KVM_IOEVENTFD_FLAG_PIO)) {
|
|
|
|
ret = kvm_io_bus_register_dev(kvm, KVM_FAST_MMIO_BUS,
|
|
|
|
p->addr, 0, &p->dev);
|
|
|
|
if (ret < 0)
|
|
|
|
goto register_fail;
|
|
|
|
}
|
|
|
|
|
2013-05-24 16:44:15 -06:00
|
|
|
kvm->buses[bus_idx]->ioeventfd_count++;
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
list_add_tail(&p->list, &kvm->ioeventfds);
|
|
|
|
|
2009-12-23 09:35:26 -07:00
|
|
|
mutex_unlock(&kvm->slots_lock);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
KVM: VMX: speed up wildcard MMIO EVENTFD
With KVM, MMIO is much slower than PIO, due to the need to
do page walk and emulation. But with EPT, it does not have to be: we
know the address from the VMCS so if the address is unique, we can look
up the eventfd directly, bypassing emulation.
Unfortunately, this only works if userspace does not need to match on
access length and data. The implementation adds a separate FAST_MMIO
bus internally. This serves two purposes:
- minimize overhead for old userspace that does not use eventfd with lengtth = 0
- minimize disruption in other code (since we don't know the length,
devices on the MMIO bus only get a valid address in write, this
way we don't need to touch all devices to teach them to handle
an invalid length)
At the moment, this optimization only has effect for EPT on x86.
It will be possible to speed up MMIO for NPT and MMU using the same
idea in the future.
With this patch applied, on VMX MMIO EVENTFD is essentially as fast as PIO.
I was unable to detect any measureable slowdown to non-eventfd MMIO.
Making MMIO faster is important for the upcoming virtio 1.0 which
includes an MMIO signalling capability.
The idea was suggested by Peter Anvin. Lots of thanks to Gleb for
pre-review and suggestions.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2014-03-31 12:50:44 -06:00
|
|
|
register_fail:
|
|
|
|
kvm_io_bus_unregister_dev(kvm, bus_idx, &p->dev);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
unlock_fail:
|
2009-12-23 09:35:26 -07:00
|
|
|
mutex_unlock(&kvm->slots_lock);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
|
|
|
|
fail:
|
|
|
|
kfree(p);
|
|
|
|
eventfd_ctx_put(eventfd);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
kvm_deassign_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
|
|
|
|
{
|
2013-02-28 04:33:20 -07:00
|
|
|
enum kvm_bus bus_idx;
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
struct _ioeventfd *p, *tmp;
|
|
|
|
struct eventfd_ctx *eventfd;
|
|
|
|
int ret = -ENOENT;
|
|
|
|
|
2013-02-28 04:33:20 -07:00
|
|
|
bus_idx = ioeventfd_bus_from_flags(args->flags);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
eventfd = eventfd_ctx_fdget(args->fd);
|
|
|
|
if (IS_ERR(eventfd))
|
|
|
|
return PTR_ERR(eventfd);
|
|
|
|
|
2009-12-23 09:35:26 -07:00
|
|
|
mutex_lock(&kvm->slots_lock);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
|
|
|
|
list_for_each_entry_safe(p, tmp, &kvm->ioeventfds, list) {
|
|
|
|
bool wildcard = !(args->flags & KVM_IOEVENTFD_FLAG_DATAMATCH);
|
|
|
|
|
2013-04-04 04:27:21 -06:00
|
|
|
if (p->bus_idx != bus_idx ||
|
|
|
|
p->eventfd != eventfd ||
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
p->addr != args->addr ||
|
|
|
|
p->length != args->len ||
|
|
|
|
p->wildcard != wildcard)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!p->wildcard && p->datamatch != args->datamatch)
|
|
|
|
continue;
|
|
|
|
|
2009-12-23 09:35:24 -07:00
|
|
|
kvm_io_bus_unregister_dev(kvm, bus_idx, &p->dev);
|
KVM: VMX: speed up wildcard MMIO EVENTFD
With KVM, MMIO is much slower than PIO, due to the need to
do page walk and emulation. But with EPT, it does not have to be: we
know the address from the VMCS so if the address is unique, we can look
up the eventfd directly, bypassing emulation.
Unfortunately, this only works if userspace does not need to match on
access length and data. The implementation adds a separate FAST_MMIO
bus internally. This serves two purposes:
- minimize overhead for old userspace that does not use eventfd with lengtth = 0
- minimize disruption in other code (since we don't know the length,
devices on the MMIO bus only get a valid address in write, this
way we don't need to touch all devices to teach them to handle
an invalid length)
At the moment, this optimization only has effect for EPT on x86.
It will be possible to speed up MMIO for NPT and MMU using the same
idea in the future.
With this patch applied, on VMX MMIO EVENTFD is essentially as fast as PIO.
I was unable to detect any measureable slowdown to non-eventfd MMIO.
Making MMIO faster is important for the upcoming virtio 1.0 which
includes an MMIO signalling capability.
The idea was suggested by Peter Anvin. Lots of thanks to Gleb for
pre-review and suggestions.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
2014-03-31 12:50:44 -06:00
|
|
|
if (!p->length) {
|
|
|
|
kvm_io_bus_unregister_dev(kvm, KVM_FAST_MMIO_BUS,
|
|
|
|
&p->dev);
|
|
|
|
}
|
2013-05-24 16:44:15 -06:00
|
|
|
kvm->buses[bus_idx]->ioeventfd_count--;
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
ioeventfd_release(p);
|
|
|
|
ret = 0;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2009-12-23 09:35:26 -07:00
|
|
|
mutex_unlock(&kvm->slots_lock);
|
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>
2009-07-07 15:08:49 -06:00
|
|
|
|
|
|
|
eventfd_ctx_put(eventfd);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int
|
|
|
|
kvm_ioeventfd(struct kvm *kvm, struct kvm_ioeventfd *args)
|
|
|
|
{
|
|
|
|
if (args->flags & KVM_IOEVENTFD_FLAG_DEASSIGN)
|
|
|
|
return kvm_deassign_ioeventfd(kvm, args);
|
|
|
|
|
|
|
|
return kvm_assign_ioeventfd(kvm, args);
|
|
|
|
}
|