iosignalfd

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]

Quoted 4 lines · Gregory Haskins

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]

Since Davide has already acked this patch, please include this in the signoff section so we don't lose the paperwork.

Today kvm_io_bus_regsiter_dev() returns void and will internally BUG_ON if it fails. We want to create dynamic MMIO/PIO entries driven from userspace later in the series, so we need to enhance the code to be more robust with the following changes:

1) Add a return value to the registration function
2) Fix up all the callsites to check the return code, handle any failures, and percolate the error up to the caller.
3) Refactor io_bus to allow "holes" in the array so device hotplug can add/remove devices arbitrarily.
4) Add an unregister function

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

---

 arch/x86/kvm/i8254.c      |   34 ++++++++++++++++++++++---------
 arch/x86/kvm/i8259.c      |    9 +++++++-
 include/linux/kvm_host.h  |    8 +++++--
 virt/kvm/coalesced_mmio.c |    8 ++++++-
 virt/kvm/ioapic.c         |    9 ++++++--
 virt/kvm/kvm_main.c       |   49 +++++++++++++++++++++++++++++++++++++++------
 6 files changed, 92 insertions(+), 25 deletions(-)

arch/x86/kvm/i8254.c +7 -10

index 584e3d3..6cf84d4 100644
@@ -564,36 +564,40 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm, u32 flags)
 {
 	struct kvm_pit *pit;
 	struct kvm_kpit_state *pit_state;
+	int ret;
 
 	pit = kzalloc(sizeof(struct kvm_pit), GFP_KERNEL);
 	if (!pit)
 		return NULL;
 
 	pit->irq_source_id = kvm_request_irq_source_id(kvm);
-	if (pit->irq_source_id < 0) {
-		kfree(pit);
-		return NULL;
-	}
-
-	mutex_init(&pit->pit_state.lock);
-	mutex_lock(&pit->pit_state.lock);
-	spin_lock_init(&pit->pit_state.inject_lock);
+	if (pit->irq_source_id < 0)
+		goto fail;
 
 	/* Initialize PIO device */
 	pit->dev.read = pit_ioport_read;
 	pit->dev.write = pit_ioport_write;
 	pit->dev.in_range = pit_in_range;
 	pit->dev.private = pit;
-	kvm_io_bus_register_dev(&kvm->pio_bus, &pit->dev);
+	ret = kvm_io_bus_register_dev(&kvm->pio_bus, &pit->dev);
+	if (ret < 0)
+		goto fail;
 
 	if (flags & KVM_PIT_SPEAKER_DUMMY) {
 		pit->speaker_dev.read = speaker_ioport_read;
 		pit->speaker_dev.write = speaker_ioport_write;
 		pit->speaker_dev.in_range = speaker_in_range;
 		pit->speaker_dev.private = pit;
-		kvm_io_bus_register_dev(&kvm->pio_bus, &pit->speaker_dev);
+		ret = kvm_io_bus_register_dev(&kvm->pio_bus,

arch/x86/kvm/i8254.c +8 -1

+	kvm_io_bus_unregister_dev(&kvm->pio_bus, &pit->dev);
+
+	if (pit->irq_source_id >= 0)
+		kvm_free_irq_source_id(kvm, pit->irq_source_id);
+
+	kfree(pit);
+	return NULL;
 }
 

@@ -52,7 +52,7 @@ extern struct kmem_cache *kvm_vcpu_cache;
  * in one place.
  */
 struct kvm_io_bus {
-	int                   dev_count;
+	spinlock_t lock;
 #define NR_IOBUS_DEVS 6
 	struct kvm_io_device *devs[NR_IOBUS_DEVS];
 };

@@ -61,8 +61,10 @@ void kvm_io_bus_init(struct kvm_io_bus *bus);
 void kvm_io_bus_destroy(struct kvm_io_bus *bus);

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

@@ -2453,21 +2455,54 @@ struct kvm_io_device *kvm_io_bus_find_dev(struct kvm_io_bus *bus,
 {
 	int i;

Quoted 75 lines · Gregory Haskins

Today kvm_io_bus_regsiter_dev() returns void and will internally BUG_ON if it
fails. We want to create dynamic MMIO/PIO entries driven from userspace later
in the series, so we need to enhance the code to be more robust with the following changes:

1) Add a return value to the registration function
2) Fix up all the callsites to check the return code, handle any failures, and percolate the error up to the caller.
3) Refactor io_bus to allow "holes" in the array so device hotplug can add/remove devices arbitrarily.
4) Add an unregister function

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

---

 arch/x86/kvm/i8254.c      |   34 ++++++++++++++++++++++---------
 arch/x86/kvm/i8259.c      |    9 +++++++-
 include/linux/kvm_host.h  |    8 +++++--
 virt/kvm/coalesced_mmio.c |    8 ++++++-
 virt/kvm/ioapic.c         |    9 ++++++--
 virt/kvm/kvm_main.c       |   49
+++++++++++++++++++++++++++++++++++++++------
 6 files changed, 92 insertions(+), 25 deletions(-)

arch/x86/kvm/i8254.c +10 -10

index 584e3d3..6cf84d4 100644
@@ -564,36 +564,40 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm,
 u32 flags)
 {
     struct kvm_pit *pit;
     struct kvm_kpit_state *pit_state;
+    int ret;
 
     pit = kzalloc(sizeof(struct kvm_pit), GFP_KERNEL);
     if (!pit)
         return NULL;
 
     pit->irq_source_id = kvm_request_irq_source_id(kvm);
-    if (pit->irq_source_id < 0) {
-        kfree(pit);
-        return NULL;
-    }
-
-    mutex_init(&pit->pit_state.lock);
-    mutex_lock(&pit->pit_state.lock);
-    spin_lock_init(&pit->pit_state.inject_lock);
+    if (pit->irq_source_id < 0)
+        goto fail;
 
     /* Initialize PIO device */
     pit->dev.read = pit_ioport_read;
     pit->dev.write = pit_ioport_write;
     pit->dev.in_range = pit_in_range;
     pit->dev.private = pit;
-    kvm_io_bus_register_dev(&kvm->pio_bus, &pit->dev);
+    ret = kvm_io_bus_register_dev(&kvm->pio_bus, &pit->dev);
+    if (ret < 0)
+        goto fail;
 
     if (flags & KVM_PIT_SPEAKER_DUMMY) {
         pit->speaker_dev.read = speaker_ioport_read;
         pit->speaker_dev.write = speaker_ioport_write;
         pit->speaker_dev.in_range = speaker_in_range;
         pit->speaker_dev.private = pit;
-        kvm_io_bus_register_dev(&kvm->pio_bus, &pit->speaker_dev);
+        ret = kvm_io_bus_register_dev(&kvm->pio_bus,
+                          &pit->speaker_dev);
+        if (ret < 0)
+            goto fail;
     }
 

arch/x86/kvm/i8254.c struct kvm_pit *kvm_create_pit(struct kvm *kvm, u32 flags) · line 603

Quoted 5 lines

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

+    mutex_init(&pit->pit_state.lock);
+    mutex_lock(&pit->pit_state.lock);
+    spin_lock_init(&pit->pit_state.inject_lock);
+
 

You are registering the PIT before it is initialized. That exposes a race. The original code also did that, but at least the pit lock was held while this was done.

Quoted 8 lines

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

     kvm->arch.vpit = pit;

     pit->kvm = kvm;

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

@@ -613,6 +617,16 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm,
 u32 flags)
     kvm_register_irq_mask_notifier(kvm, 0, &pit->mask_notifier);
 

arch/x86/kvm/i8254.c struct kvm_pit *kvm_create_pit(struct kvm *kvm, u32 flags) · line 631

Quoted 5 lines

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

     return pit;
+
+fail:
+    kvm_io_bus_unregister_dev(&kvm->pio_bus, &pit->speaker_dev);
 

There's an option now to avoid speaker_dev, so this needs to be conditional.

Quoted 26 lines

arch/x86/kvm/i8254.c +9 -3

+    kvm_io_bus_unregister_dev(&kvm->pio_bus, &pit->dev);
+
+    if (pit->irq_source_id >= 0)
+        kvm_free_irq_source_id(kvm, pit->irq_source_id);
+
+    kfree(pit);
+    return NULL;
 }

@@ -52,7 +52,7 @@ extern struct kmem_cache *kvm_vcpu_cache;
  * in one place.
  */
 struct kvm_io_bus {
-    int                   dev_count;
+    spinlock_t lock;
 #define NR_IOBUS_DEVS 6
     struct kvm_io_device *devs[NR_IOBUS_DEVS];
 };

@@ -61,8 +61,10 @@ void kvm_io_bus_init(struct kvm_io_bus *bus);
 void kvm_io_bus_destroy(struct kvm_io_bus *bus);
 struct kvm_io_device *kvm_io_bus_find_dev(struct kvm_io_bus *bus,
                       gpa_t addr, int len, int is_write);
-void kvm_io_bus_register_dev(struct kvm_io_bus *bus,
-                 struct kvm_io_device *dev);
+int kvm_io_bus_register_dev(struct kvm_io_bus *bus,

arch/x86/kvm/i8254.c void kvm_io_bus_init(struct kvm_io_bus *bus); · line 69

Quoted 5 lines

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

+                struct kvm_io_device *dev);
+int kvm_io_bus_unregister_dev(struct kvm_io_bus *bus,
+                struct kvm_io_device *dev);
 
 

unregister() should return void. There's really nothing you can do to recover from a failure.

Quoted 11 lines

arch/x86/kvm/i8254.c +1 -1

@@ -2453,21 +2455,54 @@ struct kvm_io_device
 *kvm_io_bus_find_dev(struct kvm_io_bus *bus,
 {
     int i;
 
-    for (i = 0; i < bus->dev_count; i++) {
+    for (i = 0; i < NR_IOBUS_DEVS; i++) {
         struct kvm_io_device *pos = bus->devs[i];
 

arch/x86/kvm/i8254.c struct kvm_io_device · line 2465

Quoted 5 lines

arch/x86/kvm/i8254.c +1 -1

-        if (pos->in_range(pos, addr, len, is_write))
+        if (pos && pos->in_range(pos, addr, len, is_write))
             return pos;
     }
 

Let's keep dev_count, and just move things around on unregister.

iosignalfd 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 iosignalfd.

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
iosignalfd-mmio: 200100 iops, 5.00us rtt
iosignalfd-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
iosignalfd-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.

virt/kvm/eventfd.c +5 -0

+
+static int
+kvm_assign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args)
+{
+	int                 pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO;

Quoted 85 lines · Gregory Haskins

iosignalfd 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 iosignalfd.

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
iosignalfd-mmio: 200100 iops, 5.00us rtt
iosignalfd-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
iosignalfd-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.

virt/kvm/eventfd.c +6 -0

+/* writes trigger an event */
+static void
+iosignalfd_write(struct kvm_io_device *this, gpa_t addr, int len,
+         const void *val)
+{
+    struct _iosignalfd *iosignalfd = (struct _iosignalfd

*)this->private;

virt/kvm/eventfd.c kvm_irqfd_release(struct kvm *kvm) · line 276

Quoted 3 lines

virt/kvm/eventfd.c +3 -0

+
+    eventfd_signal(iosignalfd->file, 1);
+}

I much prefer including kvm_io_device inside _iosignalfd and using container_of() instead of ->private. But that is of course unrelated to this patch and is not a requirement.

Quoted 6 lines

virt/kvm/eventfd.c +5 -0

+
+static int
+kvm_assign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args)
+{
+    int                 pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO;

virt/kvm/eventfd.c kvm_irqfd_release(struct kvm *kvm) · line 315

Quoted 10 lines

virt/kvm/eventfd.c +10 -0

+    struct kvm_io_bus  *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus;
+    struct _iosignalfd *iosignalfd;
+    struct file        *file;
+    int                 ret;
+
+    file = eventfd_fget(args->fd);
+    if (IS_ERR(file)) {
+        ret = PTR_ERR(file);
+        printk(KERN_ERR "iosignalfd: failed to get %d eventfd: %d\n",
+               args->fd, ret);

drop the printk, we don't want to let users spam dmesg.

virt/kvm/eventfd.c kvm_irqfd_release(struct kvm *kvm) · line 321

Quoted 7 lines

virt/kvm/eventfd.c +6 -0

+        return ret;
+    }
+
+    iosignalfd = kzalloc(sizeof(*iosignalfd), GFP_KERNEL);
+    if (!iosignalfd) {
+        printk(KERN_ERR "iosignalfd: memory pressure\n");

here too.

virt/kvm/eventfd.c kvm_irqfd_release(struct kvm *kvm) · line 341

Quoted 5 lines

virt/kvm/eventfd.c +4 -0

+    ret = kvm_io_bus_register_dev(bus, &iosignalfd->dev);
+    if (ret < 0) {
+        printk(KERN_ERR "iosignalfd: failed to register IODEV: %d\n",
+               ret);

and here etc.

What happens if you register to iosignalfds for the same address but with different cookies (a very practical scenario)?

Quoted 4 lines

What happens if you register to iosignalfds for the same address but with different cookies (a very practical scenario)?

This is really only supported at the iosignal interface level. Today, you can do this and the registration will succeed, but at run-time an IO-exit will stop at the first in_range() hit it finds. Therefore, you will only get service on the first/lowest registered range.

I knew this was a limitation of the current io_bus, but I put the feature into iosignalfd anyway so that the user/kern interface was robust enough to support the notion should we ever need it (and can thus patch io_bus at that time). Perhaps that is short-sighted because userspace would never know its ranges weren't really registered properly.

I guess its simple enough to have io_bus check all devices for a match instead of stopping on the first. Should I just make a patch to fix this, or should I fix iosignalfd to check for in_range matches and fail if it finds overlap? (We could then add a CAP_OVERLAP_IO bit in the future if we finally fix the io_bus capability). I am inclined to lean towards option 2, since its not known whether this will ever be useful, and io_bus scanning is in a hot-path.

Thinking about it some more, I wonder if we should just get rid of the notion of overlap to begin with. Its a slippery slope (should we also return to userspace after scanning and matching io_bus to see if it has any overlap too?). I am not sure if it would ever be used (real hardware doesn't have multiple devices at the same address), and we can always have multiple end-points mux from one iosignalfd if we really need that. Thoughts?

Quoted 25 lines · Gregory Haskins

Quoted 4 lines

What happens if you register to iosignalfds for the same address but with different cookies (a very practical scenario)?

This is really only supported at the iosignal interface level. Today, you can do this and the registration will succeed, but at run-time an IO-exit will stop at the first in_range() hit it finds. Therefore, you will only get service on the first/lowest registered range.

I knew this was a limitation of the current io_bus, but I put the feature into iosignalfd anyway so that the user/kern interface was robust enough to support the notion should we ever need it (and can thus patch io_bus at that time). Perhaps that is short-sighted because userspace would never know its ranges weren't really registered properly.

I guess its simple enough to have io_bus check all devices for a match instead of stopping on the first. Should I just make a patch to fix this, or should I fix iosignalfd to check for in_range matches and fail if it finds overlap? (We could then add a CAP_OVERLAP_IO bit in the future if we finally fix the io_bus capability). I am inclined to lean towards option 2, since its not known whether this will ever be useful, and io_bus scanning is in a hot-path.

Quoted 8 lines

Thinking about it some more, I wonder if we should just get rid of the notion of overlap to begin with. Its a slippery slope (should we also return to userspace after scanning and matching io_bus to see if it has any overlap too?). I am not sure if it would ever be used (real hardware doesn't have multiple devices at the same address), and we can always have multiple end-points mux from one iosignalfd if we really need that. Thoughts?

Multiple cookies on the same address are required by virtio. You can't mux since the data doesn't go anywhere.

Virtio can survive by checking all rings on a notify, and we can later add a mechanism that has a distinct address for each ring, but let's see if we can cope with multiple cookies. Mark?

You could search existing iosignalfds for the same address and re-use the same iodevice. I don't want to search the entire list since that precludes tricks like using hashtables or sorting the list by frequency of access.

Multiple cookies on the same address are required by virtio. You can't mux since the data doesn't go anywhere.

Virtio can survive by checking all rings on a notify, and we can later add a mechanism that has a distinct address for each ring, but let's see if we can cope with multiple cookies. Mark?

Quoted 7 lines · Avi Kivity

Multiple cookies on the same address are required by virtio. You can't mux since the data doesn't go anywhere.

Virtio can survive by checking all rings on a notify, and we can later add a mechanism that has a distinct address for each ring, but let's see if we can cope with multiple cookies. Mark?

Trying to catch up, but you're talking about replacing virtio-pci QUEUE_NOTIFY handling with iosignalfd ?

For a perfect replacement, what you really need is to be able to register multiple cookies per address range, but only have them trigger if the written data matches a provided value.

If the data is lost, virtio has no way of knowing which queue is being notified, so we either end up with per-device, rather than per-queue, notifications (probably not too bad for net, at least) or a different notify address per queue (limiting the number of queues per device).

Quoted 11 lines · Mark McLoughlin

Quoted 7 lines · Avi Kivity

Multiple cookies on the same address are required by virtio. You can't mux since the data doesn't go anywhere.

Virtio can survive by checking all rings on a notify, and we can later add a mechanism that has a distinct address for each ring, but let's see if we can cope with multiple cookies. Mark?

Quoted 7 lines

Trying to catch up, but you're talking about replacing virtio-pci QUEUE_NOTIFY handling with iosignalfd ?

For a perfect replacement, what you really need is to be able to register multiple cookies per address range, but only have them trigger if the written data matches a provided value.

Hmm..thats an interesting idea. To date, the "cookie" has really been for identifying the proper range selected for deassignment. I never thought of using it as an actual trigger value at run-time.

Quoted 5 lines

If the data is lost, virtio has no way of knowing which queue is being notified, so we either end up with per-device, rather than per-queue, notifications (probably not too bad for net, at least) or a different notify address per queue (limiting the number of queues per device).

The addr-per-queue is how I was envisioning it, but the trigger value concept hadn't occurred to me. I could make this an option during assignment (e.g. "COOKIE" flag means only trigger on writes of the provided cookie, otherwise trigger on any write). Sound good?

Quoted 33 lines · Gregory Haskins

Quoted 12 lines · Mark McLoughlin

Quoted 8 lines · Avi Kivity

Multiple cookies on the same address are required by virtio. You can't mux since the data doesn't go anywhere.

Virtio can survive by checking all rings on a notify, and we can later add a mechanism that has a distinct address for each ring, but let's see if we can cope with multiple cookies. Mark?

Quoted 8 lines

Trying to catch up, but you're talking about replacing virtio-pci QUEUE_NOTIFY handling with iosignalfd ?

For a perfect replacement, what you really need is to be able to register multiple cookies per address range, but only have them trigger if the written data matches a provided value.

Hmm..thats an interesting idea. To date, the "cookie" has really been for identifying the proper range selected for deassignment. I never thought of using it as an actual trigger value at run-time.

Quoted 6 lines

If the data is lost, virtio has no way of knowing which queue is being notified, so we either end up with per-device, rather than per-queue, notifications (probably not too bad for net, at least) or a different notify address per queue (limiting the number of queues per device).

Quoted 5 lines

The addr-per-queue is how I was envisioning it, but the trigger value concept hadn't occurred to me. I could make this an option during assignment (e.g. "COOKIE" flag means only trigger on writes of the provided cookie, otherwise trigger on any write). Sound good?

Ah, I'd been thinking of the trigger data being provided separately to the cookie.

The virtio ABI is fixed, so we couldn't e.g. have the guest use a cookie to identify a queue - it's just going to continue using a per-device queue number.

So, if the cookie was also the trigger, we'd need an eventfd per device.

Quoted 3 lines · Mark McLoughlin

The virtio ABI is fixed, so we couldn't e.g. have the guest use a cookie to identify a queue - it's just going to continue using a per-device queue number.

Actually, I was originally thinking this would be exposed as a virtio FEATURE bit anyway, so there were no backwards-compat constraints. That said, we can possibly make it work in a backwards compat way, too. IIRC, today virtio does a PIO cycle to a specific register with the queue-id when it wants to signal guest->host, right? What is the width of the write?

Quoted 3 lines

So, if the cookie was also the trigger, we'd need an eventfd per device.

I'm having trouble parsing this one. The cookie namespace is controlled by the userspace component that owns the corresponding IO address, so there's no reason you can't make "queue-id = 0" use cookie = 0, or whatever. That said, I still think a separation of the cookie and trigger as suggested above is a good idea, so its probably moot to discuss this point further.

Quoted 6 lines · Gregory Haskins

Quoted 4 lines · Mark McLoughlin

The virtio ABI is fixed, so we couldn't e.g. have the guest use a cookie to identify a queue - it's just going to continue using a per-device queue number.

Quoted 7 lines

Actually, I was originally thinking this would be exposed as a virtio FEATURE bit anyway, so there were no backwards-compat constraints. That said, we can possibly make it work in a backwards compat way, too. IIRC, today virtio does a PIO cycle to a specific register with the queue-id when it wants to signal guest->host, right? What is the width of the write?

It's a 16-bit write.

/* A 16-bit r/w queue notifier */
#define VIRTIO_PCI_QUEUE_NOTIFY 16

Quoted 5 lines

Quoted 5 lines

So, if the cookie was also the trigger, we'd need an eventfd per device.

Quoted 7 lines

I'm having trouble parsing this one. The cookie namespace is controlled by the userspace component that owns the corresponding IO address, so there's no reason you can't make "queue-id = 0" use cookie = 0, or whatever. That said, I still think a separation of the cookie and trigger as suggested above is a good idea, so its probably moot to discuss this point further.

Ah, my mistake - I thought the cookie was returned to userspace when the eventfd was signalled, but no ... userspace only gets an event counter value and the cookie is used during de-assignment to distinguish between iosignalfds.

Okay, so suppose you do assign multiple times at a given address - you're presumably going to use a different eventfd for each assignment? If so, can't we match using both the address and eventfd at de-assignment and drop the cookie from the interface altogether?

This is closer to how the original series worked, but Avi asked for a data-match token and thus the cookie was born. I think the rationale is that we can't predict whether the same eventfd will be registered more than once, and thus we need a way to further qualify it. However, to your point, I cannot think of a valid use case for having the same fd registered to the same address more than once, so perhaps your fd/addr tuple is sufficient and we can drop the cookie (or, really, rename it to "trigger" ;)

Avi?

Quoted 11 lines · Gregory Haskins

This is closer to how the original series worked, but Avi asked for a data-match token and thus the cookie was born. I think the rationale is that we can't predict whether the same eventfd will be registered more than once, and thus we need a way to further qualify it. However, to your point, I cannot think of a valid use case for having the same fd registered to the same address more than once, so perhaps your fd/addr tuple is sufficient and we can drop the cookie (or, really, rename it to "trigger" ;)

Avi?

This is just how virtio works. To kick ring N of device X, it writes N to a port specific to X.

If we lose N, then we don't know which ring was kicked and have to check them all.

May we can rename cookie to data_match to make it explicit. If the data doesn't match, the eventfd isn't kicked.

(Mark, same as we have arbitrary ring->MSI mappings (allowing one MSI to notify multiple rings), perhaps we should have the same capability for the other direction? So the guest could kick mulitple rings with one write, or just one ring, according to personal preference.

Quoted 33 lines · Gregory Haskins

Quoted 12 lines · Mark McLoughlin

Quoted 8 lines · Avi Kivity

Multiple cookies on the same address are required by virtio. You can't mux since the data doesn't go anywhere.

Virtio can survive by checking all rings on a notify, and we can later add a mechanism that has a distinct address for each ring, but let's see if we can cope with multiple cookies. Mark?

Quoted 8 lines

Trying to catch up, but you're talking about replacing virtio-pci QUEUE_NOTIFY handling with iosignalfd ?

For a perfect replacement, what you really need is to be able to register multiple cookies per address range, but only have them trigger if the written data matches a provided value.

Hmm..thats an interesting idea. To date, the "cookie" has really been for identifying the proper range selected for deassignment. I never thought of using it as an actual trigger value at run-time.

Quoted 6 lines

If the data is lost, virtio has no way of knowing which queue is being notified, so we either end up with per-device, rather than per-queue, notifications (probably not too bad for net, at least) or a different notify address per queue (limiting the number of queues per device).

Quoted 5 lines

The addr-per-queue is how I was envisioning it, but the trigger value concept hadn't occurred to me. I could make this an option during assignment (e.g. "COOKIE" flag means only trigger on writes of the provided cookie, otherwise trigger on any write). Sound good?

Ah, I'd been thinking of the trigger data being provided separately to the cookie.

The virtio ABI is fixed, so we couldn't e.g. have the guest use a cookie to identify a queue - it's just going to continue using a per-device queue number. So, if the cookie was also the trigger, we'd need an eventfd per device.

And if this was a device where the guest writes similar values to multiple addresses, you'd need an eventfd per address.

Hi Mark,
So with the v5 release of iosignalfd, we now have the notion of a
"trigger", the API of which is as follows:

-----------------------
/*!
* \brief Assign an eventfd to an IO port (PIO or MMIO)
*
* Assigns an eventfd based file-descriptor to a specific PIO or MMIO
* address range. Any guest writes to the specified range will generate
* an eventfd signal.
*
* A data-match pointer can be optionally provided in "trigger" and only
* writes which match this value exactly will generate an event. The length
* of the trigger is established by the length of the overall IO range, and
* therefore must be in a natural byte-width for the IO routines of your
* particular architecture (e.g. 1, 2, 4, or 8 bytes on x86_64).