kvm: eventfd interfaces (formerly irqfd)

We want to use eventfd from KVM which can be compiled as a module, so export the interfaces.

Signed-off-by Gregory Haskins <[email protected]>

KVM provides a complete virtual system environment for guests, including support for injecting interrupts modeled after the real exception/interrupt facilities present on the native platform (such as the IDT on x86). Virtual interrupts can come from a variety of sources (emulated devices, pass-through devices, etc) but all must be injected to the guest via the KVM infrastructure. This patch adds a new mechanism to inject a specific interrupt to a guest using a decoupled eventfd mechnanism: Any legal signal on the irqfd (using eventfd semantics from either userspace or kernel) will translate into an injected interrupt in the guest at the next available interrupt window.

arch/x86/kvm/x86.c +0 -0

 		r = 1;
 		break;
 	case KVM_CAP_COALESCED_MMIO:

include/linux/kvm.h +0 -0

index 3db5d8d..dfc4bcc 100644

include/linux/kvm.h +5 -0

+
+int
+kvm_deassign_irqfd(struct kvm *kvm, int fd)
+{
+	struct _irqfd *irqfd, *tmp;

Quoted 15 lines · Gregory Haskins

KVM provides a complete virtual system environment for guests, including support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86). Virtual interrupts can come from a variety of sources (emulated devices, pass-through devices, etc) but all must be injected to the guest via the KVM infrastructure. This patch adds a new mechanism to inject a specific
interrupt to a guest using a decoupled eventfd mechnanism: Any legal signal
on the irqfd (using eventfd semantics from either userspace or kernel) will
translate into an injected interrupt in the guest at the next available interrupt window.

include/linux/kvm.h struct kvm_trace_rec { · line 419

Quoted 13 lines

         r = 1;
         break;
     case KVM_CAP_COALESCED_MMIO:

include/linux/kvm.h +1 -0

index 3db5d8d..dfc4bcc 100644
@@ -415,6 +415,7 @@ struct kvm_trace_rec {
 #define KVM_CAP_ASSIGN_DEV_IRQ 29
 /* Another bug in KVM_SET_USER_MEMORY_REGION fixed: */
 #define KVM_CAP_JOIN_MEMORY_REGIONS_WORKS 30
+#define KVM_CAP_EVENTFD 31
 

Let's keep a fine granularity and call it IRQFD.

Quoted 12 lines

include/linux/kvm.h +11 -0

+
+int
+kvm_deassign_irqfd(struct kvm *kvm, int fd)
+{
+    struct _irqfd *irqfd, *tmp;
+
+    mutex_lock(&kvm->lock);
+
+    /*
+     * linear search isn't brilliant, but this should be a infrequent
+     * operation and the list should not grow very large

include/linux/kvm.h

Quoted 5 lines

include/linux/kvm.h +4 -0

+     */
+    list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds, list) {
+        if (irqfd->fd != fd)
+            continue;

Please fget() the new fd and compare the filps; fds aren't meaningful in the kernel. You can also drop _irqfd::fd.

It may also be useful to compare the gsi, this allows a "make-before-break" switchover:

- guest reroutes irq to a different gsi
- associate irqfd with new gsi
- disassociate irqfd from old gsi

include/linux/kvm.h

Quoted 5 lines

include/linux/kvm.h +4 -0

+
+        irqfd_release(irqfd);
+        mutex_unlock(&kvm->lock);
+        return 0;

Don't return, userspace may have multiple associations?

Quoted 3 lines

Please fget() the new fd and compare the filps; fds aren't meaningful in the kernel. You can also drop _irqfd::fd.

I like this as a second option...

Quoted 3 lines

It may also be useful to compare the gsi, this allows a "make-before-break" switchover:

...but I like this best. Good idea.

Quoted 11 lines

- guest reroutes irq to a different gsi
- associate irqfd with new gsi
- disassociate irqfd from old gsi

Quoted 6 lines

virt/kvm/eventfd.c new file +4 -0

+
+        irqfd_release(irqfd);
+        mutex_unlock(&kvm->lock);
+        return 0;

Quoted 2 lines

Don't return, userspace may have multiple associations?

Parse error. Can you elaborate?

Quoted 7 lines · Gregory Haskins

Quoted 3 lines

Please fget() the new fd and compare the filps; fds aren't meaningful in the kernel. You can also drop _irqfd::fd.

I like this as a second option...

Quoted 6 lines

Quoted 3 lines

It may also be useful to compare the gsi, this allows a "make-before-break" switchover:

...but I like this best. Good idea.

I thought of comparing both.

Quoted 11 lines

Quoted 11 lines

- guest reroutes irq to a different gsi
- associate irqfd with new gsi
- disassociate irqfd from old gsi

Quoted 5 lines

virt/kvm/eventfd.c new file +4 -0

+
+        irqfd_release(irqfd);
+        mutex_unlock(&kvm->lock);
+        return 0;

Quoted 6 lines

Quoted 2 lines

Don't return, userspace may have multiple associations?

Parse error. Can you elaborate?

You break out of the look when you match your irqfd. But there may be multiple matches.

Granted, it doesn't make much sense to hook the same fd to the same gsi multiple times (it may make sense to hook multiple fds to a single gsi, or maybe a single fd to multiple gsis), but it pays to have a consistent do-what-I-said-even-if-it-doesn't-make-sense interface.

KVM provides a complete virtual system environment for guests, including support for injecting interrupts modeled after the real exception/interrupt facilities present on the native platform (such as the IDT on x86). Virtual interrupts can come from a variety of sources (emulated devices, pass-through devices, etc) but all must be injected to the guest via the KVM infrastructure. This patch adds a new mechanism to inject a specific interrupt to a guest using a decoupled eventfd mechnanism: Any legal signal on the irqfd (using eventfd semantics from either userspace or kernel) will translate into an injected interrupt in the guest at the next available interrupt window.

virt/kvm/eventfd.c new file +5 -0

+	mutex_lock(&kvm->lock);
+	kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1);
+	kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0);
+	mutex_unlock(&kvm->lock);
+}

Quoted 15 lines · Gregory Haskins

KVM provides a complete virtual system environment for guests, including support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86). Virtual interrupts can come from a variety of sources (emulated devices, pass-through devices, etc) but all must be injected to the guest via the KVM infrastructure. This patch adds a new mechanism to inject a specific
interrupt to a guest using a decoupled eventfd mechnanism: Any legal signal
on the irqfd (using eventfd semantics from either userspace or kernel) will
translate into an injected interrupt in the guest at the next available interrupt window.

virt/kvm/eventfd.c line 55

Quoted 8 lines

virt/kvm/eventfd.c new file +7 -0

+
+static void
+irqfd_inject(struct work_struct *work)
+{
+    struct _irqfd *irqfd = container_of(work, struct _irqfd, work);
+    struct kvm *kvm = irqfd->kvm;
+

I think you need to ->read() from the irqfd, otherwise the count will never clear.

Quoted 7 lines

virt/kvm/eventfd.c new file +5 -0

+    mutex_lock(&kvm->lock);
+    kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 1);
+    kvm_set_irq(kvm, KVM_USERSPACE_IRQ_SOURCE_ID, irqfd->gsi, 0);
+    mutex_unlock(&kvm->lock);
+}

Quoted 16 lines · Avi Kivity

Quoted 15 lines · Gregory Haskins

KVM provides a complete virtual system environment for guests, including support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86). Virtual interrupts can come from a variety of sources (emulated devices, pass-through devices, etc) but all must be injected to the guest via the KVM infrastructure. This patch adds a new mechanism to inject a specific
interrupt to a guest using a decoupled eventfd mechnanism: Any legal signal
on the irqfd (using eventfd semantics from either userspace or kernel) will
translate into an injected interrupt in the guest at the next available interrupt window.

Quoted 12 lines

virt/kvm/eventfd.c line 55

Quoted 8 lines

virt/kvm/eventfd.c new file +7 -0

+
+static void
+irqfd_inject(struct work_struct *work)
+{
+    struct _irqfd *irqfd = container_of(work, struct _irqfd, work);
+    struct kvm *kvm = irqfd->kvm;
+

I think you need to ->read() from the irqfd, otherwise the count will never clear.

Yeah, and this is a disavantage to using eventfd vs a custom anon-fd implementation.

However, the count is really only there for deciding whether to sleep a traditional eventfd recipient which doesn't really apply in this application. I suppose we could try to invoke the read method (or add a new method to eventfd to allow it to be cleared independent of the f_ops->read() (ala eventfd_signal() vs f_ops->write()). I'm not convinced we really need to worry about it, though. IMO we can just let the count accumulate.

But if you insist this loose end should be addressed, perhaps Davide has some thoughts on how to best do this?

Quoted 42 lines · Gregory Haskins

Quoted 17 lines · Avi Kivity

Quoted 15 lines · Gregory Haskins

KVM provides a complete virtual system environment for guests, including support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86). Virtual interrupts can come from a variety of sources (emulated devices, pass-through devices, etc) but all must be injected to the guest via the KVM infrastructure. This patch adds a new mechanism to inject a specific
interrupt to a guest using a decoupled eventfd mechnanism: Any legal signal
on the irqfd (using eventfd semantics from either userspace or kernel) will
translate into an injected interrupt in the guest at the next available interrupt window.

Quoted 12 lines

virt/kvm/eventfd.c line 55

Quoted 9 lines

virt/kvm/eventfd.c new file +7 -0

+
+static void
+irqfd_inject(struct work_struct *work)
+{
+    struct _irqfd *irqfd = container_of(work, struct _irqfd, work);
+    struct kvm *kvm = irqfd->kvm;
+

I think you need to ->read() from the irqfd, otherwise the count will never clear.

Yeah, and this is a disavantage to using eventfd vs a custom anon-fd implementation.

However, the count is really only there for deciding whether to sleep a traditional eventfd recipient which doesn't really apply in this application. I suppose we could try to invoke the read method (or add a new method to eventfd to allow it to be cleared independent of the f_ops->read() (ala eventfd_signal() vs f_ops->write()). I'm not convinced we really need to worry about it, though. IMO we can just let the count accumulate.

Quoted 3 lines

But if you insist this loose end should be addressed, perhaps Davide has some thoughts on how to best do this?

The counter is 64bit, so at 1M IRQ/s will take about 585K years to saturate. But from a symmetry POV, it may be better to clear it. Maybe with a kernel-side eventfd_read()?

iofd is a mechanism to register PIO/MMIO regions to trigger an eventfd signal when written to. Userspace can register any arbitrary address with a corresponding eventfd.

Signed-off-by Gregory Haskins <[email protected]>

---

 include/linux/kvm.h      |   12 +++++
 include/linux/kvm_host.h |    2 +
 virt/kvm/eventfd.c       |  107 ++++++++++++++++++++++++++++++++++++++++++++++
 virt/kvm/kvm_main.c      |   13 ++++++
 4 files changed, 134 insertions(+), 0 deletions(-)

include/linux/kvm.h +12 -0

index dfc4bcc..99b6e45 100644
@@ -292,6 +292,17 @@ struct kvm_guest_debug {
 	struct kvm_guest_debug_arch arch;
 };
 
+#define KVM_IOFD_FLAG_DEASSIGN  (1 << 0)
+#define KVM_IOFD_FLAG_PIO       (1 << 1)
+
+struct kvm_iofd {
+	__u64 addr;
+	__u32 len;
+	__u32 fd;
+	__u32 flags;
+	__u8  pad[12];
+};
+
 #define KVM_TRC_SHIFT           16
 /*
  * kvm trace categories

@@ -508,6 +519,7 @@ struct kvm_irqfd {
 #define KVM_DEASSIGN_DEV_IRQ       _IOW(KVMIO, 0x75, struct kvm_assigned_irq)
 #define KVM_ASSIGN_IRQFD           _IOW(KVMIO, 0x76, struct kvm_irqfd)
 #define KVM_DEASSIGN_IRQFD         _IOW(KVMIO, 0x77, __u32)
+#define KVM_IOFD                   _IOW(KVMIO, 0x78, struct kvm_iofd)
 
 /*
  * ioctls for vcpu fds

include/linux/kvm_host.h +2 -0

index 1acc528..d53cb70 100644
@@ -529,5 +529,7 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {}
 int kvm_assign_irqfd(struct kvm *kvm, int fd, int gsi, int flags);
 int kvm_deassign_irqfd(struct kvm *kvm, int fd);
 void kvm_irqfd_release(struct kvm *kvm);
+int kvm_iofd(struct kvm *kvm, unsigned long addr, size_t len,
+	     int fd, int flags);
 
 #endif

virt/kvm/eventfd.c +107 -0

index 71afd62..8b23317 100644
@@ -21,12 +21,16 @@
  */
 
 #include <linux/kvm_host.h>
+#include <linux/kvm.h>
 #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>
+
+#include "iodev.h"
 
 /*
  * --------------------------------------------------------------------

@@ -185,3 +189,106 @@ kvm_irqfd_release(struct kvm *kvm)
 	list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds, list)
 		irqfd_release(irqfd);
 }
+
+/*
+ * --------------------------------------------------------------------
+ * iofd: translate a PIO/MMIO memory write to an eventfd signal.
+ *
+ * userspace can register a PIO/MMIO address with an eventfd for recieving
+ * notification when the memory has been touched.
+ * --------------------------------------------------------------------
+ */
+
+struct _iofd {
+	u64                  addr;
+	size_t               length;
+	struct file         *file;
+	struct kvm_io_device dev;
+};
+
+static int
+iofd_in_range(struct kvm_io_device *this, gpa_t addr, int len, int is_write)
+{
+	struct _iofd *iofd = (struct _iofd *)this->private;
+
+	return ((addr >= iofd->addr && (addr < iofd->addr + iofd->length)));
+}
+
+/* writes trigger an event */
+static void
+iofd_write(struct kvm_io_device *this, gpa_t addr, int len, const void *val)
+{
+	struct _iofd *iofd = (struct _iofd *)this->private;
+
+	eventfd_signal(iofd->file, 1);
+}
+
+/* reads return all zeros */
+static void
+iofd_read(struct kvm_io_device *this, gpa_t addr, int len, void *val)
+{
+	memset(val, 0, len);
+}
+
+static void
+iofd_destructor(struct kvm_io_device *this)
+{
+	struct _iofd *iofd = (struct _iofd *)this->private;
+
+	fput(iofd->file);
+	kfree(iofd);
+}
+
+static int
+kvm_assign_iofd(struct kvm *kvm, unsigned long addr, size_t len,
+		int fd, int flags)
+{
+	int                pio = flags & KVM_IOFD_FLAG_PIO;
+	struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus;
+	struct _iofd      *iofd;
+	struct file       *file;
+
+	file = eventfd_fget(fd);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
+
+	iofd = kzalloc(sizeof(*iofd), GFP_KERNEL);
+	if (!iofd) {
+		fput(file);
+		return -ENOMEM;
+	}
+
+	iofd->dev.read       = iofd_read;
+	iofd->dev.write      = iofd_write;
+	iofd->dev.in_range   = iofd_in_range;
+	iofd->dev.destructor = iofd_destructor;
+	iofd->dev.private    = iofd;
+
+	iofd->addr           = addr;
+	iofd->length         = len;
+	iofd->file           = file;
+
+	kvm_io_bus_register_dev(bus, &iofd->dev);
+
+	printk(KERN_DEBUG "registering %s iofd at %lx of size %d\n",
+	       pio  ? "PIO" : "MMIO", addr, (int)len);
+
+	return 0;
+}
+
+static int
+kvm_deassign_iofd(struct kvm *kvm, unsigned long addr, size_t len,
+		  int fd, int flags)
+{
+	/* FIXME: We need an io_bus_unregister() function */
+	return -EINVAL;
+}
+
+int
+kvm_iofd(struct kvm *kvm, unsigned long addr, size_t len, int fd, int flags)
+{
+	if (flags & KVM_IOFD_FLAG_DEASSIGN)
+		return kvm_deassign_iofd(kvm, addr, len, fd, flags);
+
+	return kvm_assign_iofd(kvm, addr, len, fd, flags);
+}

virt/kvm/kvm_main.c +13 -1

index 7aa9f0a..a443974 100644
@@ -2228,6 +2228,19 @@ static long kvm_vm_ioctl(struct file *filp,
 		r = kvm_deassign_irqfd(kvm, data);
 		break;
 	}
+	case KVM_IOFD: {
+		struct kvm_iofd entry;
+
+		r = -EFAULT;
+		if (copy_from_user(&entry, argp, sizeof entry))
+			goto out;
+
+		r = kvm_iofd(kvm, entry.addr, entry.len, entry.fd,
+			     entry.flags);
+		if (r)
+			goto out;
+		break;
+	}
 	default:
 		r = kvm_arch_vm_ioctl(filp, ioctl, arg);
 	}
 
--

To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

[ updated with figures, graphs, performance-test-harness info ]

iofd is a mechanism to register PIO/MMIO regions to trigger an eventfd signal when written to by a guest. Userspace can register any arbitrary 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 iofd.

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
iofd-mmio: 200100 iops, 5.00us rtt
iofd-pio:  367300 iops, 2.72us rtt

I didn't measure qemu-pio, because I have to figure out how to register a PIO region, 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
iofd-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 <[email protected]>

---

 include/linux/kvm.h      |   12 +++++
 include/linux/kvm_host.h |    2 +
 virt/kvm/eventfd.c       |  107 ++++++++++++++++++++++++++++++++++++++++++++++
 virt/kvm/kvm_main.c      |   13 ++++++
 4 files changed, 134 insertions(+), 0 deletions(-)

include/linux/kvm.h +12 -0

index dfc4bcc..99b6e45 100644
@@ -292,6 +292,17 @@ struct kvm_guest_debug {
 	struct kvm_guest_debug_arch arch;
 };
 
+#define KVM_IOFD_FLAG_DEASSIGN  (1 << 0)
+#define KVM_IOFD_FLAG_PIO       (1 << 1)
+
+struct kvm_iofd {
+	__u64 addr;
+	__u32 len;
+	__u32 fd;
+	__u32 flags;
+	__u8  pad[12];
+};
+
 #define KVM_TRC_SHIFT           16
 /*
  * kvm trace categories

@@ -508,6 +519,7 @@ struct kvm_irqfd {
 #define KVM_DEASSIGN_DEV_IRQ       _IOW(KVMIO, 0x75, struct kvm_assigned_irq)
 #define KVM_ASSIGN_IRQFD           _IOW(KVMIO, 0x76, struct kvm_irqfd)
 #define KVM_DEASSIGN_IRQFD         _IOW(KVMIO, 0x77, __u32)
+#define KVM_IOFD                   _IOW(KVMIO, 0x78, struct kvm_iofd)
 
 /*
  * ioctls for vcpu fds

include/linux/kvm_host.h +2 -0

index 1acc528..d53cb70 100644
@@ -529,5 +529,7 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {}
 int kvm_assign_irqfd(struct kvm *kvm, int fd, int gsi, int flags);
 int kvm_deassign_irqfd(struct kvm *kvm, int fd);
 void kvm_irqfd_release(struct kvm *kvm);
+int kvm_iofd(struct kvm *kvm, unsigned long addr, size_t len,
+	     int fd, int flags);
 
 #endif

virt/kvm/eventfd.c +74 -0

index 71afd62..8b23317 100644
@@ -21,12 +21,16 @@
  */
 
 #include <linux/kvm_host.h>
+#include <linux/kvm.h>
 #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>
+
+#include "iodev.h"
 
 /*
  * --------------------------------------------------------------------

@@ -185,3 +189,106 @@ kvm_irqfd_release(struct kvm *kvm)
 	list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds, list)
 		irqfd_release(irqfd);
 }
+
+/*
+ * --------------------------------------------------------------------
+ * iofd: translate a PIO/MMIO memory write to an eventfd signal.
+ *
+ * userspace can register a PIO/MMIO address with an eventfd for recieving
+ * notification when the memory has been touched.
+ * --------------------------------------------------------------------
+ */
+
+struct _iofd {
+	u64                  addr;
+	size_t               length;
+	struct file         *file;
+	struct kvm_io_device dev;
+};
+
+static int
+iofd_in_range(struct kvm_io_device *this, gpa_t addr, int len, int is_write)
+{
+	struct _iofd *iofd = (struct _iofd *)this->private;
+
+	return ((addr >= iofd->addr && (addr < iofd->addr + iofd->length)));
+}
+
+/* writes trigger an event */
+static void
+iofd_write(struct kvm_io_device *this, gpa_t addr, int len, const void *val)
+{
+	struct _iofd *iofd = (struct _iofd *)this->private;
+
+	eventfd_signal(iofd->file, 1);
+}
+
+/* reads return all zeros */
+static void
+iofd_read(struct kvm_io_device *this, gpa_t addr, int len, void *val)
+{
+	memset(val, 0, len);
+}
+
+static void
+iofd_destructor(struct kvm_io_device *this)
+{
+	struct _iofd *iofd = (struct _iofd *)this->private;
+
+	fput(iofd->file);
+	kfree(iofd);
+}
+
+static int
+kvm_assign_iofd(struct kvm *kvm, unsigned long addr, size_t len,
+		int fd, int flags)
+{
+	int                pio = flags & KVM_IOFD_FLAG_PIO;
+	struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus;
+	struct _iofd      *iofd;
+	struct file       *file;
+
+	file = eventfd_fget(fd);
+	if (IS_ERR(file))
+		return PTR_ERR(file);
+
+	iofd = kzalloc(sizeof(*iofd), GFP_KERNEL);
+	if (!iofd) {
+		fput(file);
+		return -ENOMEM;
+	}
+
+	iofd->dev.read       = iofd_read;

virt/kvm/eventfd.c +23 -0

+
+	printk(KERN_DEBUG "registering %s iofd at %lx of size %d\n",
+	       pio  ? "PIO" : "MMIO", addr, (int)len);
+
+	return 0;
+}
+
+static int
+kvm_deassign_iofd(struct kvm *kvm, unsigned long addr, size_t len,
+		  int fd, int flags)
+{
+	/* FIXME: We need an io_bus_unregister() function */
+	return -EINVAL;
+}
+
+int
+kvm_iofd(struct kvm *kvm, unsigned long addr, size_t len, int fd, int flags)
+{
+	if (flags & KVM_IOFD_FLAG_DEASSIGN)
+		return kvm_deassign_iofd(kvm, addr, len, fd, flags);
+
+	return kvm_assign_iofd(kvm, addr, len, fd, flags);
+}

virt/kvm/kvm_main.c +13 -1

index 7aa9f0a..a443974 100644
@@ -2228,6 +2228,19 @@ static long kvm_vm_ioctl(struct file *filp,
 		r = kvm_deassign_irqfd(kvm, data);
 		break;
 	}
+	case KVM_IOFD: {
+		struct kvm_iofd entry;
+
+		r = -EFAULT;
+		if (copy_from_user(&entry, argp, sizeof entry))
+			goto out;
+
+		r = kvm_iofd(kvm, entry.addr, entry.len, entry.fd,
+			     entry.flags);
+		if (r)
+			goto out;
+		break;
+	}
 	default:
 		r = kvm_arch_vm_ioctl(filp, ioctl, arg);
 	}
 
--

To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

iofd is a mechanism to register PIO/MMIO regions to trigger an eventfd signal when written to. Userspace can register any arbitrary address with a corresponding eventfd.

include/linux/kvm.h +2 -0

index dfc4bcc..99b6e45 100644
@@ -292,6 +292,17 @@ struct kvm_guest_debug {
 	struct kvm_guest_debug_arch arch;
 };
 
+#define KVM_IOFD_FLAG_DEASSIGN  (1 << 0)
+#define KVM_IOFD_FLAG_PIO       (1 << 1)

Quoted 5 lines · Gregory Haskins

iofd is a mechanism to register PIO/MMIO regions to trigger an eventfd signal when written to. Userspace can register any arbitrary address with a corresponding eventfd.

Please start a separate patchset for this so I can merge irqfd.

Quoted 10 lines

include/linux/kvm.h +0 -0

index dfc4bcc..99b6e45 100644
@@ -292,6 +292,17 @@ struct kvm_guest_debug {
     struct kvm_guest_debug_arch arch;
 };
 

include/linux/kvm.h struct kvm_guest_debug {

Quoted 12 lines

include/linux/kvm.h +11 -0

+#define KVM_IOFD_FLAG_DEASSIGN  (1 << 0)
+#define KVM_IOFD_FLAG_PIO       (1 << 1)
+
+struct kvm_iofd {
+    __u64 addr;
+    __u32 len;
+    __u32 fd;
+    __u32 flags;
+    __u8  pad[12];
+};
+
 

Please add a data match capability. virtio uses a write with the data containing the queue ID, and we want a separate event for each queue.

include/linux/kvm.h struct kvm_irqfd { · line 524

Quoted 10 lines

include/linux/kvm.h +1 -0

  * kvm trace categories

@@ -508,6 +519,7 @@ struct kvm_irqfd {
 #define KVM_DEASSIGN_DEV_IRQ       _IOW(KVMIO, 0x75, struct
 kvm_assigned_irq)
 #define KVM_ASSIGN_IRQFD           _IOW(KVMIO, 0x76, struct kvm_irqfd)
 #define KVM_DEASSIGN_IRQFD         _IOW(KVMIO, 0x77, __u32)
+#define KVM_IOFD                   _IOW(KVMIO, 0x78, struct kvm_iofd)
 

Too general a name. It's not doing IO, just sending out notifications.

Why have assign/deassign for irqfd and a single ioctl for iofd?

The rest looks good.

Quoted 6 lines

Quoted 6 lines

include/linux/kvm.h +6 -0

+#define KVM_IOFD_FLAG_PIO       (1 << 1)
+
+struct kvm_iofd {
+    __u64 addr;
+    __u32 len;
+    __u32 fd;

Quoted 9 lines

include/linux/kvm.h struct kvm_guest_debug { · line 305

Quoted 6 lines

include/linux/kvm.h +4 -0

+    __u32 flags;
+    __u8  pad[12];
+};
+

Please add a data match capability. virtio uses a write with the data containing the queue ID, and we want a separate event for each queue.

How about "u64 cookie" ?

Quoted 11 lines

include/linux/kvm.h struct kvm_irqfd { · line 525

Quoted 9 lines

* kvm trace categories

include/linux/kvm.h +1 -0

@@ -508,6 +519,7 @@ struct kvm_irqfd {
 #define KVM_DEASSIGN_DEV_IRQ       _IOW(KVMIO, 0x75, struct
 kvm_assigned_irq)
 #define KVM_ASSIGN_IRQFD           _IOW(KVMIO, 0x76, struct kvm_irqfd)
 #define KVM_DEASSIGN_IRQFD         _IOW(KVMIO, 0x77, __u32)
+#define KVM_IOFD                   _IOW(KVMIO, 0x78, struct kvm_iofd)
 
 

Too general a name. It's not doing IO, just sending out notifications.

Hmm...good point. I was trying to reflect "[MM/P]IO-FD". How about "IOSIGNALFD"

Quoted 2 lines

Why have assign/deassign for irqfd and a single ioctl for iofd?

Heh.. irqfd "liked" two because the deassign only needed a u32. iofd needed more or less the same structure for both so I guess I thought I would be "slick" and condense the vectors. Will fix so they are symmetrical.