| Message ID | 20090706203321.14222.67866.stgit@dev.haskins.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Some comments below. Sorry, I know it's late in the series, but previously I've been too confused with complicated locking to notice anything else :(. On Mon, Jul 06, 2009 at 04:33:21PM -0400, Gregory Haskins wrote: > 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. > > -------------------- > > Signed-off-by: Gregory Haskins <ghaskins@novell.com> > --- > > arch/x86/kvm/x86.c | 1 > include/linux/kvm.h | 15 ++ > include/linux/kvm_host.h | 10 +- > virt/kvm/eventfd.c | 280 ++++++++++++++++++++++++++++++++++++++++++++++ > virt/kvm/kvm_main.c | 11 ++ > 5 files changed, 313 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 0e74d98..6e4b2f5 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -1204,6 +1204,7 @@ int kvm_dev_ioctl_check_extension(long ext) > case KVM_CAP_IRQ_INJECT_STATUS: > case KVM_CAP_ASSIGN_DEV_IRQ: > case KVM_CAP_IRQFD: > + case KVM_CAP_IOSIGNALFD: > case KVM_CAP_PIT2: > r = 1; > break; > diff --git a/include/linux/kvm.h b/include/linux/kvm.h > index 76c6408..236f12d 100644 > --- a/include/linux/kvm.h > +++ b/include/linux/kvm.h > @@ -307,6 +307,19 @@ struct kvm_guest_debug { > struct kvm_guest_debug_arch arch; > }; > > +#define KVM_IOSIGNALFD_FLAG_TRIGGER (1 << 0) /* trigger is valid */ can we rename trigger -> value? > +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) /* is a pio (otherwise mmio) */ > +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 2) > + > +struct kvm_iosignalfd { > + __u64 trigger; for length <8, it's the 8*len least significant bits that are used, right? That's a bit ugly ... Maybe just put an 8 byte array here instead, then the first len bytes are valid. > + __u64 addr; /* legal pio/mmio address */ > + __u32 len; /* 1, 2, 4, or 8 bytes */ > + __s32 fd; > + __u32 flags; > + __u8 pad[36]; > +}; > + > #define KVM_TRC_SHIFT 16 > /* > * kvm trace categories > @@ -409,6 +422,7 @@ struct kvm_guest_debug { > #define KVM_CAP_PIT2 33 > #endif > #define KVM_CAP_SET_BOOT_CPU_ID 34 > +#define KVM_CAP_IOSIGNALFD 35 > > #ifdef KVM_CAP_IRQ_ROUTING > > @@ -517,6 +531,7 @@ struct kvm_irqfd { > #define KVM_IRQFD _IOW(KVMIO, 0x76, struct kvm_irqfd) > #define KVM_CREATE_PIT2 _IOW(KVMIO, 0x77, struct kvm_pit_config) > #define KVM_SET_BOOT_CPU_ID _IO(KVMIO, 0x78) > +#define KVM_IOSIGNALFD _IOW(KVMIO, 0x79, struct kvm_iosignalfd) > > /* > * ioctls for vcpu fds > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index 306bc67..5099416 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -154,6 +154,7 @@ struct kvm { > spinlock_t lock; > struct list_head items; > } irqfds; > + struct list_head iosignalfds; > #endif > struct kvm_vm_stat stat; > struct kvm_arch arch; > @@ -532,19 +533,24 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {} > > #ifdef CONFIG_HAVE_KVM_EVENTFD > > -void kvm_irqfd_init(struct kvm *kvm); > +void kvm_eventfd_init(struct kvm *kvm); > int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags); > void kvm_irqfd_release(struct kvm *kvm); > +int kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args); > > #else > > -static inline void kvm_irqfd_init(struct kvm *kvm) {} > +static inline void kvm_eventfd_init(struct kvm *kvm) {} > static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags) > { > return -EINVAL; > } > > static inline void kvm_irqfd_release(struct kvm *kvm) {} > +static inline int kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) > +{ > + return -ENOSYS; > +} > > #endif /* CONFIG_HAVE_KVM_EVENTFD */ > > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c > index 4092b8d..c03b619 100644 > --- a/virt/kvm/eventfd.c > +++ b/virt/kvm/eventfd.c > @@ -21,6 +21,7 @@ > */ > > #include <linux/kvm_host.h> > +#include <linux/kvm.h> > #include <linux/workqueue.h> > #include <linux/syscalls.h> > #include <linux/wait.h> > @@ -28,6 +29,9 @@ > #include <linux/file.h> > #include <linux/list.h> > #include <linux/eventfd.h> > +#include <linux/kernel.h> > + > +#include "iodev.h" > > /* > * -------------------------------------------------------------------- > @@ -234,10 +238,12 @@ fail: > } > > void > -kvm_irqfd_init(struct kvm *kvm) > +kvm_eventfd_init(struct kvm *kvm) > { > spin_lock_init(&kvm->irqfds.lock); > INIT_LIST_HEAD(&kvm->irqfds.items); > + don't need this empty line > + INIT_LIST_HEAD(&kvm->iosignalfds); > } > > /* > @@ -327,3 +333,275 @@ static void __exit irqfd_module_exit(void) > > module_init(irqfd_module_init); > module_exit(irqfd_module_exit); > + > +/* > + * -------------------------------------------------------------------- > + * iosignalfd: translate a PIO/MMIO memory write to an eventfd signal. > + * > + * userspace can register a PIO/MMIO address with an eventfd for recieving recieving -> receiving > + * notification when the memory has been touched. > + * -------------------------------------------------------------------- > + */ > + > +struct _iosignalfd { > + struct list_head list; > + u64 addr; > + size_t length; "int length" should be enough: the value is 1, 2, 4 or 8. and put wildcard near it if you want to save some space > + struct eventfd_ctx *eventfd; > + u64 match; match -> value > + struct kvm_io_device dev; > + int wildcard:1; don't use bitfields > +}; > + > +static inline struct _iosignalfd * > +to_iosignalfd(struct kvm_io_device *dev) > +{ > + return container_of(dev, struct _iosignalfd, dev); > +} > + > +static void > +iosignalfd_release(struct _iosignalfd *p) > +{ > + eventfd_ctx_put(p->eventfd); > + list_del(&p->list); > + kfree(p); > +} > + > +static bool > +iosignalfd_in_range(struct _iosignalfd *p, gpa_t addr, int len, const void *val) > +{ > + u64 _val; > + > + if (!(addr == p->addr && len == p->length)) de-morgan's laws can help simplify this > + /* address-range must be precise for a hit */ So there's apparently no way to specify that you want 1,2, or 4 byte writes at address X? > + 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->match ? true : false; Life be simpler if we use an 8 byte array for match and just do memcmp here. > +} > + > +/* > + * MMIO/PIO writes trigger an event if the addr/val match > + */ single line comment can look like this: /* MMIO/PIO writes trigger an event if the addr/val match */ > +static int > +iosignalfd_write(struct kvm_io_device *this, gpa_t addr, int len, > + const void *val) > +{ > + struct _iosignalfd *p = to_iosignalfd(this); > + > + if (!iosignalfd_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 > +iosignalfd_destructor(struct kvm_io_device *this) > +{ > + struct _iosignalfd *p = to_iosignalfd(this); > + > + iosignalfd_release(p); > +} > + > +static const struct kvm_io_device_ops iosignalfd_ops = { > + .write = iosignalfd_write, > + .destructor = iosignalfd_destructor, > +}; > + > +static bool > +iosignalfd_overlap(struct _iosignalfd *lhs, struct _iosignalfd *rhs) this checks both region overlap and data collision. better split into two helpers? > +{ > + /* > + * Check for completely non-overlapping regions. We can simply > + * return "false" for non-overlapping regions and be done with > + * it. > + */ done with it -> ignore the value > + if ((rhs->addr + rhs->length) <= lhs->addr) > + return false; rhs->addr + rhs->length <= lhs->addr is not less clear, as precedence for simple math follows the familiar rules from school. > + > + if ((lhs->addr + lhs->length) <= rhs->addr) this math can overflow. > + return false; or shorter: if (rhs->addr + rhs->length <= lhs->addr || lhs->addr + lhs->length <= rhs->addr) return true; > + > + /* > + * If we get here, we know there is *some* overlap, but we don't > + * yet know how much. how much? > Make sure its a "precise" overlap, or precise overlap -> address/len pairs match > + * its rejected as incompatible > + */ "rejected" does not seem to make sense in the context of a boolean function > + if (lhs->addr != rhs->addr) > + return true; > + > + if (lhs->length != rhs->length) > + return true; > + or shorter: if (lhs->addr != rhs->addr || lhs->length != rhs->length) return true; > + /* > + * If we get here, the request should be a precise overlap > + * between rhs+lhs. The only thing left to check is for > + * data-match overlap. If the data match is distinctly different > + * we can allow the two to co-exist. Any kind of wild-card > + * consitutes an incompatible range, so reject any wild-cards, > + * or if the match token is identical. > + */ > + if (lhs->wildcard || rhs->wildcard || lhs->match == rhs->match) > + return true; > + > + return false; > +} > + > +/* assumes kvm->slots_lock write-lock held */ it seems you only need read lock? > +static bool > +iosignalfd_check_collision(struct kvm *kvm, struct _iosignalfd *p) > +{ > + struct _iosignalfd *_p; > + > + list_for_each_entry(_p, &kvm->iosignalfds, list) > + if (iosignalfd_overlap(_p, p)) This looks wrong: let's assume I want one signal with length 1 and one with length 2 at address 0. They never trigger together, so it should be ok to have 2 such devices. > + return true; > + > + return false; > +} > + > +static int > +kvm_assign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) > +{ > + int pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO; > + struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus; > + struct _iosignalfd *p; > + struct eventfd_ctx *eventfd; > + int ret; > + > + switch (args->len) { > + case 1: > + case 2: > + case 4: > + case 8: > + break; > + default: > + return -EINVAL; > + } > + > + eventfd = eventfd_ctx_fdget(args->fd); > + if (IS_ERR(eventfd)) > + return PTR_ERR(eventfd); since this eventfd is kept around indefinitely, we should keep the file * around as well, so that this eventfd is accounted for properly with # of open files limit set by the admin. > + > + p = kzalloc(sizeof(*p), GFP_KERNEL); > + if (!p) { > + ret = -ENOMEM; > + goto fail; > + } > + > + INIT_LIST_HEAD(&p->list); > + p->addr = args->addr; > + p->length = args->len; > + p->eventfd = eventfd; > + > + /* > + * A trigger address is optional, otherwise this is a wildcard > + */ A single line comment can look like this: /* A trigger address is optional, otherwise this is a wildcard */ > + if (args->flags & KVM_IOSIGNALFD_FLAG_TRIGGER) > + p->match = args->trigger; For len < 8, high bits in trigger are ignored. it's better to check that they are 0, less confusing if the user e.g. gets the endian-ness wrong. > + else > + p->wildcard = true; > + > + down_write(&kvm->slots_lock); > + > + /* Verify that there isnt a match already */ Better to put documentation to where function is declared, not where it is used. > + if (iosignalfd_check_collision(kvm, p)) { > + ret = -EEXIST; > + goto unlock_fail; > + } > + > + kvm_iodevice_init(&p->dev, &iosignalfd_ops); > + > + ret = __kvm_io_bus_register_dev(bus, &p->dev); > + if (ret < 0) > + goto unlock_fail; > + > + list_add_tail(&p->list, &kvm->iosignalfds); > + > + up_write(&kvm->slots_lock); > + > + return 0; > + we probably do not need an empty line after each line of code here > +unlock_fail: > + up_write(&kvm->slots_lock); > +fail: > + /* > + * it would have never made it to the list in the failure path, so > + * we dont need to worry about removing it > + */ of course: you goto fail before list_add can just kill this comment > + kfree(p); > + > + eventfd_ctx_put(eventfd); > + > + return ret; we probably do not need an empty line after each line of code here > +} > + > + two empty lines > +static int > +kvm_deassign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) > +{ > + int pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO; > + struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus; > + struct _iosignalfd *p, *tmp; > + struct eventfd_ctx *eventfd; > + int ret = 0; > + > + eventfd = eventfd_ctx_fdget(args->fd); > + if (IS_ERR(eventfd)) > + return PTR_ERR(eventfd); > + > + down_write(&kvm->slots_lock); > + > + list_for_each_entry_safe(p, tmp, &kvm->iosignalfds, list) { > + kill empty line > + if (p->eventfd != eventfd) > + continue; So for deassign, you ignore all arguments besides fd? Is this intentional? Looks strange - think of multiple addresses triggering a single eventfd. But if so, it's better to have a different ioctl with just the fields we need. > + > + __kvm_io_bus_unregister_dev(bus, &p->dev); > + iosignalfd_release(p); a single deassign removed multiple irqfds? Looks ugly. > + } > + kill empty line > + up_write(&kvm->slots_lock); > + > + eventfd_ctx_put(eventfd); > + > + return ret; > +} return error status if no device was found? > + > +int > +kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) > +{ > + if (args->flags & KVM_IOSIGNALFD_FLAG_DEASSIGN) > + return kvm_deassign_iosignalfd(kvm, args); Better check that only known flag values are present. Otherwise when you add more flags things just break silently. > + > + return kvm_assign_iosignalfd(kvm, args); > +} > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index 11595c7..5ac381b 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -979,7 +979,7 @@ static struct kvm *kvm_create_vm(void) > spin_lock_init(&kvm->mmu_lock); > spin_lock_init(&kvm->requests_lock); > kvm_io_bus_init(&kvm->pio_bus); > - kvm_irqfd_init(kvm); > + kvm_eventfd_init(kvm); > mutex_init(&kvm->lock); > mutex_init(&kvm->irq_lock); > kvm_io_bus_init(&kvm->mmio_bus); > @@ -2271,6 +2271,15 @@ static long kvm_vm_ioctl(struct file *filp, > r = kvm_irqfd(kvm, data.fd, data.gsi, data.flags); > break; > } > + case KVM_IOSIGNALFD: { > + struct kvm_iosignalfd data; > + > + r = -EFAULT; this trick is nice, it saves a line of code for the closing brace but why waste it on an empty line above then? > + if (copy_from_user(&data, argp, sizeof data)) > + goto out; > + r = kvm_iosignalfd(kvm, &data); > + break; > + } > #ifdef CONFIG_KVM_APIC_ARCHITECTURE > case KVM_SET_BOOT_CPU_ID: > r = 0; -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(adding Davide, there's a small comment for you in the middle, search for eventfd) On 07/07/2009 02:20 PM, Michael S. Tsirkin wrote: > >> @@ -307,6 +307,19 @@ struct kvm_guest_debug { >> struct kvm_guest_debug_arch arch; >> }; >> >> +#define KVM_IOSIGNALFD_FLAG_TRIGGER (1<< 0) /* trigger is valid */ >> > > can we rename trigger -> value? > Or maybe data_match? Speaking of renames, how about IOSIGNALFD -> IOEVENTFD? I have some vague uneasiness seeing signals all the time. >> +#define KVM_IOSIGNALFD_FLAG_PIO (1<< 1) /* is a pio (otherwise mmio) */ >> +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1<< 2) >> + >> +struct kvm_iosignalfd { >> + __u64 trigger; >> > > for length<8, it's the 8*len least significant bits that are used, right? > That's a bit ugly ... Maybe just put an 8 byte array here instead, then > the first len bytes are valid. > > We're matching the value as the guest wrote it. I think this is fine. >> + struct kvm_io_device dev; >> + int wildcard:1; >> > > don't use bitfields > Yeah, bool is better. >> + /* address-range must be precise for a hit */ >> > > So there's apparently no way to specify that > you want 1,2, or 4 byte writes at address X? > Why would you want that? > >> + 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->match ? true : false; >> > > Life be simpler if we use an 8 byte array for match > and just do memcmp here. > My plan is to change the io_dev interface to pass a u64. >> + >> + eventfd = eventfd_ctx_fdget(args->fd); >> + if (IS_ERR(eventfd)) >> + return PTR_ERR(eventfd); >> > > since this eventfd is kept around indefinitely, we should keep the > file * around as well, so that this eventfd is accounted for > properly with # of open files limit set by the admin. > Won't all eventfd_ctx_get() uses suffer from that? Davide, I think this is better handled in eventfd. Or else we can ignore it and trust whoever holds the eventfd_ctx to limit the mount of objects. >> + >> +int >> +kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) >> +{ >> + if (args->flags& KVM_IOSIGNALFD_FLAG_DEASSIGN) >> + return kvm_deassign_iosignalfd(kvm, args); >> > > Better check that only known flag values are present. > Otherwise when you add more flags things just break > silently. > Good comment and something that we miss a lot. >> + case KVM_IOSIGNALFD: { >> + struct kvm_iosignalfd data; >> + >> + r = -EFAULT; >> > > this trick is nice, it saves a line of code for the closing brace > but why waste it on an empty line above then? > Traditionally C code separates declarations from code.
Michael S. Tsirkin wrote: > Some comments below. Sorry, I know it's late in the series, but > previously I've been too confused with complicated locking to notice > anything else :(. > > On Mon, Jul 06, 2009 at 04:33:21PM -0400, Gregory Haskins wrote: > > >> +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) /* is a pio (otherwise mmio) */ >> +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 2) >> + >> +struct kvm_iosignalfd { >> + __u64 trigger; >> > > for length <8, it's the 8*len least significant bits that are used, right? > That's a bit ugly ... Maybe just put an 8 byte array here instead, then > the first len bytes are valid. > The original series uses an array that I kmalloc'ed to size, or left it NULL for a wildcard. Avi didn't like this and requested a u64 for all values. I don't care either way, but since you two are asking for conflicting designs, I will let you debate. > >> >> void >> -kvm_irqfd_init(struct kvm *kvm) >> +kvm_eventfd_init(struct kvm *kvm) >> { >> spin_lock_init(&kvm->irqfds.lock); >> INIT_LIST_HEAD(&kvm->irqfds.items); >> + >> > > don't need this empty line > Ack > >> + INIT_LIST_HEAD(&kvm->iosignalfds); >> } >> >> /* >> @@ -327,3 +333,275 @@ static void __exit irqfd_module_exit(void) >> >> module_init(irqfd_module_init); >> module_exit(irqfd_module_exit); >> + >> +/* >> + * -------------------------------------------------------------------- >> + * iosignalfd: translate a PIO/MMIO memory write to an eventfd signal. >> + * >> + * userspace can register a PIO/MMIO address with an eventfd for recieving >> > > recieving -> receiving > > Ack /me is embarrassed >> + * notification when the memory has been touched. >> + * -------------------------------------------------------------------- >> + */ >> + >> +struct _iosignalfd { >> + struct list_head list; >> + u64 addr; >> + size_t length; >> > > "int length" should be enough: the value is 1, 2, 4 or 8. > and put wildcard near it if you want to save some space > > Ok >> + struct eventfd_ctx *eventfd; >> + u64 match; >> > > match -> value > > Ok >> + struct kvm_io_device dev; >> + int wildcard:1; >> > > don't use bitfields > bool? > >> +}; >> + >> +static inline struct _iosignalfd * >> +to_iosignalfd(struct kvm_io_device *dev) >> +{ >> + return container_of(dev, struct _iosignalfd, dev); >> +} >> + >> +static void >> +iosignalfd_release(struct _iosignalfd *p) >> +{ >> + eventfd_ctx_put(p->eventfd); >> + list_del(&p->list); >> + kfree(p); >> +} >> + >> +static bool >> +iosignalfd_in_range(struct _iosignalfd *p, gpa_t addr, int len, const void *val) >> +{ >> + u64 _val; >> + >> + if (!(addr == p->addr && len == p->length)) >> > > de-morgan's laws can help simplify this > > >> + /* address-range must be precise for a hit */ >> > > So there's apparently no way to specify that > you want 1,2, or 4 byte writes at address X? > No, they can be any legal size (1, 2, 4, or 8). The only limitation is that any overlap of two or more registrations have to be uniform in addr/len. > >> + 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->match ? true : false; >> > > Life be simpler if we use an 8 byte array for match > and just do memcmp here. > > You would need to use an n-byte array, technically (to avoid endian issues). As mentioned earlier, I already did it that way in earlier versions but Avi wanted to see it this current (u64 based) way. >> +} >> + >> +/* >> + * MMIO/PIO writes trigger an event if the addr/val match >> + */ >> > > single line comment can look like this: > /* MMIO/PIO writes trigger an event if the addr/val match */ > > Ack >> +static int >> +iosignalfd_write(struct kvm_io_device *this, gpa_t addr, int len, >> + const void *val) >> +{ >> + struct _iosignalfd *p = to_iosignalfd(this); >> + >> + if (!iosignalfd_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 >> +iosignalfd_destructor(struct kvm_io_device *this) >> +{ >> + struct _iosignalfd *p = to_iosignalfd(this); >> + >> + iosignalfd_release(p); >> +} >> + >> +static const struct kvm_io_device_ops iosignalfd_ops = { >> + .write = iosignalfd_write, >> + .destructor = iosignalfd_destructor, >> +}; >> + >> +static bool >> +iosignalfd_overlap(struct _iosignalfd *lhs, struct _iosignalfd *rhs) >> > > this checks both region overlap and data collision. > better split into two helpers? > > Why? >> +{ >> + /* >> + * Check for completely non-overlapping regions. We can simply >> + * return "false" for non-overlapping regions and be done with >> + * it. >> + */ >> > > done with it -> ignore the value > > I think that is a valid expression (at least here in the states), but ok. Note that "false" means we are accepting the request, not ignoring any value. I will construct a better comment either way. >> + if ((rhs->addr + rhs->length) <= lhs->addr) >> + return false; >> > > rhs->addr + rhs->length <= lhs->addr > is not less clear, as precedence for simple math > follows the familiar rules from school. > > Yes, but the "eye compiler" isn't as efficient as a machine driven tool. ;) The annotation is for the readers benefit (or at least me), not technical/mathematical correctness. But whatever, I'll take it out. >> + >> + if ((lhs->addr + lhs->length) <= rhs->addr) >> > > this math can overflow. > > Well, we should probably have vetted that during assign since addr+length that overflows is not a valid region. I will put a check in for that. >> + return false; >> > > or shorter: > if (rhs->addr + rhs->length <= lhs->addr || > lhs->addr + lhs->length <= rhs->addr) > return true; > > Ok >> + >> + /* >> + * If we get here, we know there is *some* overlap, but we don't >> + * yet know how much. >> > > how much? > Well, as stated we don't know yet. > >> Make sure its a "precise" overlap, or >> > > precise overlap -> address/len pairs match > > Precisely. >> + * its rejected as incompatible >> + */ >> > > "rejected" does not seem to make sense in the context of a boolean > function > > Why? true = rejected, false = accepted. Seems boolean to me. Whats wrong with that? >> + if (lhs->addr != rhs->addr) >> + return true; >> + >> + if (lhs->length != rhs->length) >> + return true; >> + >> > > or shorter: > if (lhs->addr != rhs->addr || lhs->length != rhs->length) > return true; > Ok > > >> + /* >> + * If we get here, the request should be a precise overlap >> + * between rhs+lhs. The only thing left to check is for >> + * data-match overlap. If the data match is distinctly different >> + * we can allow the two to co-exist. Any kind of wild-card >> + * consitutes an incompatible range, so reject any wild-cards, >> + * or if the match token is identical. >> + */ >> + if (lhs->wildcard || rhs->wildcard || lhs->match == rhs->match) >> + return true; >> + >> + return false; >> +} >> > > > >> + >> +/* assumes kvm->slots_lock write-lock held */ >> > > it seems you only need read lock? > > The caller needs write-lock, so we just inherit that state. I can update the comment though (I just ran a find/replace on "kvm->lock held" while updating to your new interface, thus the vague comment) >> +static bool >> +iosignalfd_check_collision(struct kvm *kvm, struct _iosignalfd *p) >> +{ >> + struct _iosignalfd *_p; >> + >> + list_for_each_entry(_p, &kvm->iosignalfds, list) >> + if (iosignalfd_overlap(_p, p)) >> > > This looks wrong: let's assume I want one signal with length 1 and one > with length 2 at address 0. They never trigger together, so it should > be ok to have 2 such devices. > We have previously decided to not support mis-matched overlaps. It's more complicated to handle, and there isn't a compelling use-case for it that I am aware of. > >> + return true; >> + >> + return false; >> +} >> + >> +static int >> +kvm_assign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) >> +{ >> + int pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO; >> + struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus; >> + struct _iosignalfd *p; >> + struct eventfd_ctx *eventfd; >> + int ret; >> + >> + switch (args->len) { >> + case 1: >> + case 2: >> + case 4: >> + case 8: >> + break; >> + default: >> + return -EINVAL; >> + } >> + >> + eventfd = eventfd_ctx_fdget(args->fd); >> + if (IS_ERR(eventfd)) >> + return PTR_ERR(eventfd); >> > > since this eventfd is kept around indefinitely, we should keep the > file * around as well, so that this eventfd is accounted for > properly with # of open files limit set by the admin. > I agree. The fact that I am missing that is a side-effect to the recent change in eventfd-upstream. If I acquire both a file* and ctx* and hold them, it should work around the issue, but perhaps we should let the eventfd interface handle this. > >> + >> + p = kzalloc(sizeof(*p), GFP_KERNEL); >> + if (!p) { >> + ret = -ENOMEM; >> + goto fail; >> + } >> + >> + INIT_LIST_HEAD(&p->list); >> + p->addr = args->addr; >> + p->length = args->len; >> + p->eventfd = eventfd; >> + >> + /* >> + * A trigger address is optional, otherwise this is a wildcard >> + */ >> > > A single line comment can look like this: > /* A trigger address is optional, otherwise this is a wildcard */ > > >> + if (args->flags & KVM_IOSIGNALFD_FLAG_TRIGGER) >> + p->match = args->trigger; >> > > For len < 8, high bits in trigger are ignored. > it's better to check that they are 0, less confusing > if the user e.g. gets the endian-ness wrong. > > >> + else >> + p->wildcard = true; >> + >> > > >> + down_write(&kvm->slots_lock); >> + >> + /* Verify that there isnt a match already */ >> > > Better to put documentation to where function is declared, > not where it is used. > > >> + if (iosignalfd_check_collision(kvm, p)) { >> + ret = -EEXIST; >> + goto unlock_fail; >> + } >> + >> + kvm_iodevice_init(&p->dev, &iosignalfd_ops); >> + >> + ret = __kvm_io_bus_register_dev(bus, &p->dev); >> + if (ret < 0) >> + goto unlock_fail; >> + >> + list_add_tail(&p->list, &kvm->iosignalfds); >> + >> + up_write(&kvm->slots_lock); >> + >> + return 0; >> + >> > > we probably do not need an empty line after each line of code here > > >> +unlock_fail: >> + up_write(&kvm->slots_lock); >> +fail: >> + /* >> + * it would have never made it to the list in the failure path, so >> + * we dont need to worry about removing it >> + */ >> > > of course: you goto fail before list_add > can just kill this comment > > >> + kfree(p); >> + >> + eventfd_ctx_put(eventfd); >> + >> + return ret; >> > > we probably do not need an empty line after each line of code here > > > >> +} >> + >> + >> > > two empty lines > Ack > >> +static int >> +kvm_deassign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) >> +{ >> + int pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO; >> + struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus; >> + struct _iosignalfd *p, *tmp; >> + struct eventfd_ctx *eventfd; >> + int ret = 0; >> + >> + eventfd = eventfd_ctx_fdget(args->fd); >> + if (IS_ERR(eventfd)) >> + return PTR_ERR(eventfd); >> + >> + down_write(&kvm->slots_lock); >> + >> + list_for_each_entry_safe(p, tmp, &kvm->iosignalfds, list) { >> + >> > > kill empty line > > >> + if (p->eventfd != eventfd) >> + continue; >> > > So for deassign, you ignore all arguments besides fd? Is this > intentional? Looks strange - think of multiple addresses triggering a > single eventfd. But if so, it's better to have a different ioctl with > just the fields we need. > Hmm... I suspect the check for a range-match got lost along the way. I agree we should probably qualify this with more than just the eventfd. > >> + >> + __kvm_io_bus_unregister_dev(bus, &p->dev); >> + iosignalfd_release(p); >> > > a single deassign removed multiple irqfds? Looks ugly. > Avi requested this general concept. > >> + } >> + >> > > kill empty line > > >> + up_write(&kvm->slots_lock); >> + >> + eventfd_ctx_put(eventfd); >> + >> + return ret; >> +} >> > > return error status if no device was found? > Ack > >> + >> +int >> +kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) >> +{ >> + if (args->flags & KVM_IOSIGNALFD_FLAG_DEASSIGN) >> + return kvm_deassign_iosignalfd(kvm, args); >> > > Better check that only known flag values are present. > Otherwise when you add more flags things just break > silently. > Ok > >> + >> + return kvm_assign_iosignalfd(kvm, args); >> +} >> diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c >> index 11595c7..5ac381b 100644 >> --- a/virt/kvm/kvm_main.c >> +++ b/virt/kvm/kvm_main.c >> @@ -979,7 +979,7 @@ static struct kvm *kvm_create_vm(void) >> spin_lock_init(&kvm->mmu_lock); >> spin_lock_init(&kvm->requests_lock); >> kvm_io_bus_init(&kvm->pio_bus); >> - kvm_irqfd_init(kvm); >> + kvm_eventfd_init(kvm); >> mutex_init(&kvm->lock); >> mutex_init(&kvm->irq_lock); >> kvm_io_bus_init(&kvm->mmio_bus); >> @@ -2271,6 +2271,15 @@ static long kvm_vm_ioctl(struct file *filp, >> r = kvm_irqfd(kvm, data.fd, data.gsi, data.flags); >> break; >> } >> + case KVM_IOSIGNALFD: { >> + struct kvm_iosignalfd data; >> + >> + r = -EFAULT; >> > > this trick is nice, it saves a line of code for the closing brace > but why waste it on an empty line above then? > > >> + if (copy_from_user(&data, argp, sizeof data)) >> + goto out; >> + r = kvm_iosignalfd(kvm, &data); >> + break; >> + } >> #ifdef CONFIG_KVM_APIC_ARCHITECTURE >> case KVM_SET_BOOT_CPU_ID: >> r = 0; >>
On Tue, Jul 07, 2009 at 02:53:18PM +0300, Avi Kivity wrote: >>> + /* address-range must be precise for a hit */ >>> >> >> So there's apparently no way to specify that >> you want 1,2, or 4 byte writes at address X? >> > > Why would you want that? Donnu. Why would anyone want to catch 8 byte writes at all? Seriously, why add artificial limitations? IMO, addr=0,len=1 and addr=0,len=2 should not conflict.
On 07/07/2009 03:22 PM, Michael S. Tsirkin wrote: > On Tue, Jul 07, 2009 at 02:53:18PM +0300, Avi Kivity wrote: > >>>> + /* address-range must be precise for a hit */ >>>> >>>> >>> So there's apparently no way to specify that >>> you want 1,2, or 4 byte writes at address X? >>> >>> >> Why would you want that? >> > > Donnu. Why would anyone want to catch 8 byte writes at all? > One of the natural write sizes. > Seriously, why add artificial limitations? > IMO, addr=0,len=1 and addr=0,len=2 should not conflict. > > They should not conflict, but a two byte write need not hit a one byte registration.
On Tue, Jul 07, 2009 at 08:15:08AM -0400, Gregory Haskins wrote: > Michael S. Tsirkin wrote: > > Some comments below. Sorry, I know it's late in the series, but > > previously I've been too confused with complicated locking to notice > > anything else :(. > > > > On Mon, Jul 06, 2009 at 04:33:21PM -0400, Gregory Haskins wrote: > > > > > >> +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) /* is a pio (otherwise mmio) */ > >> +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 2) > >> + > >> +struct kvm_iosignalfd { > >> + __u64 trigger; > >> > > > > for length <8, it's the 8*len least significant bits that are used, right? > > That's a bit ugly ... Maybe just put an 8 byte array here instead, then > > the first len bytes are valid. > > > > The original series uses an array that I kmalloc'ed to size, or left it > NULL for a wildcard. Avi didn't like this and requested a u64 for all > values. I don't care either way, but since you two are asking for > conflicting designs, I will let you debate. It turns out the io bus will be changed in the future. Let's just document the usage, and check that unused bits are zeroed. > >> + struct kvm_io_device dev; > >> + int wildcard:1; > >> > > > > don't use bitfields > > > > bool? sure > >> +} > >> + > >> +/* > >> + * MMIO/PIO writes trigger an event if the addr/val match > >> + */ > >> > > > > single line comment can look like this: > > /* MMIO/PIO writes trigger an event if the addr/val match */ > > > > > Ack > > >> +static int > >> +iosignalfd_write(struct kvm_io_device *this, gpa_t addr, int len, > >> + const void *val) > >> +{ > >> + struct _iosignalfd *p = to_iosignalfd(this); > >> + > >> + if (!iosignalfd_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 > >> +iosignalfd_destructor(struct kvm_io_device *this) > >> +{ > >> + struct _iosignalfd *p = to_iosignalfd(this); > >> + > >> + iosignalfd_release(p); > >> +} > >> + > >> +static const struct kvm_io_device_ops iosignalfd_ops = { > >> + .write = iosignalfd_write, > >> + .destructor = iosignalfd_destructor, > >> +}; > >> + > >> +static bool > >> +iosignalfd_overlap(struct _iosignalfd *lhs, struct _iosignalfd *rhs) > >> > > > > this checks both region overlap and data collision. > > better split into two helpers? > > > > > Why? Because it says iosignalfd_overlap but that's not what it does? > >> +{ > >> + /* > >> + * Check for completely non-overlapping regions. We can simply > >> + * return "false" for non-overlapping regions and be done with > >> + * it. > >> + */ > >> > > > > done with it -> ignore the value > > > > > I think that is a valid expression (at least here in the states), I'm always interested in improving my english :) here's what I thought: "done with it" says we skip the rest of the function. "ignore the value" says skip the value check. So I was trying to say let's be more specific. Isn't that what it means? > but > ok. Note that "false" means we are accepting the request, not ignoring > any value. I will construct a better comment either way. Maybe name a function in a way that makes this explicit? > >> + > >> + if ((lhs->addr + lhs->length) <= rhs->addr) > >> > > > > this math can overflow. > > > > > Well, we should probably have vetted that during assign since > addr+length that overflows is not a valid region. I will put a check in > for that. add = ~0x0ULL, len = 1 should be valid. You'll have to make the math not overflow. > >> + > >> + /* > >> + * If we get here, we know there is *some* overlap, but we don't > >> + * yet know how much. > >> > > > > how much? > > > Well, as stated we don't know yet. So why tell me :)? What I mean is this statement (especially the the part of the statement after the comma) does not add useful information. > > > >> Make sure its a "precise" overlap, or > >> > > > > precise overlap -> address/len pairs match > > > > > > Precisely. so say so :) > >> + * its rejected as incompatible > >> + */ > >> > > > > "rejected" does not seem to make sense in the context of a boolean > > function > > > > > > Why? true = rejected, false = accepted. Seems boolean to me. How should I know that? Rename it to iosignalfd_rejected? > Whats > wrong with that? If you want to return 0 on success, != 0 on failure, make the function int. > >> + > >> +/* assumes kvm->slots_lock write-lock held */ > >> > > > > it seems you only need read lock? > > > > > > The caller needs write-lock, so we just inherit that state. I can > update the comment though (I just ran a find/replace on "kvm->lock held" > while updating to your new interface, thus the vague comment) I guess so. > >> +static bool > >> +iosignalfd_check_collision(struct kvm *kvm, struct _iosignalfd *p) > >> +{ > >> + struct _iosignalfd *_p; > >> + > >> + list_for_each_entry(_p, &kvm->iosignalfds, list) > >> + if (iosignalfd_overlap(_p, p)) > >> > > > > This looks wrong: let's assume I want one signal with length 1 and one > > with length 2 at address 0. They never trigger together, so it should > > be ok to have 2 such devices. > > > > We have previously decided to not support mis-matched overlaps. It's > more complicated to handle, and there isn't a compelling use-case for it > that I am aware of. That's not what I propose. By all means len = X should only catch len = X and not len = X - 1. However, I think it makes sense to allow both len = 2 and len = 1 at the same address even though they seem to overlap. And all you really need to do is simplify the code: replace the tricky overlap logic with simple if (rhs->addr == lhs->addr && rhs->len == lhs->len) reject else accept (+add wildcard thing) > >> + if (p->eventfd != eventfd) > >> + continue; > >> > > > > So for deassign, you ignore all arguments besides fd? Is this > > intentional? Looks strange - think of multiple addresses triggering a > > single eventfd. But if so, it's better to have a different ioctl with > > just the fields we need. > > > > Hmm... I suspect the check for a range-match got lost along the way. I > agree we should probably qualify this with more than just the eventfd. > > > > >> + > >> + __kvm_io_bus_unregister_dev(bus, &p->dev); > >> + iosignalfd_release(p); > >> > > > > a single deassign removed multiple irqfds? Looks ugly. > > > > Avi requested this general concept. Really? Avi, could you explain? I would think each assign needs to be matched with 1 deassign. No?
On Tue, Jul 07, 2009 at 03:27:49PM +0300, Avi Kivity wrote: > On 07/07/2009 03:22 PM, Michael S. Tsirkin wrote: >> On Tue, Jul 07, 2009 at 02:53:18PM +0300, Avi Kivity wrote: >> >>>>> + /* address-range must be precise for a hit */ >>>>> >>>>> >>>> So there's apparently no way to specify that >>>> you want 1,2, or 4 byte writes at address X? >>>> >>>> >>> Why would you want that? >>> >> >> Donnu. Why would anyone want to catch 8 byte writes at all? >> > > One of the natural write sizes. > >> Seriously, why add artificial limitations? >> IMO, addr=0,len=1 and addr=0,len=2 should not conflict. >> >> > > They should not conflict, but a two byte write need not hit a one byte > registration. Yes. That's exactly what I'm saying. I think it should be possible to create 2 fds: addr = 0 len = 1 addr = 0 len = 2 and at most one will ever trigger. But current code will not let you create the second one.
On 07/07/2009 03:48 PM, Michael S. Tsirkin wrote: >>>> + >>>> + __kvm_io_bus_unregister_dev(bus,&p->dev); >>>> + iosignalfd_release(p); >>>> >>>> >>> a single deassign removed multiple irqfds? Looks ugly. >>> >>> >> Avi requested this general concept. >> > > Really? Avi, could you explain? I would think each > assign needs to be matched with 1 deassign. No? > Doesn't it follow naturally? How can a single deassign remove multiple fds (unless all were registered with exactly the same arguments)? Maybe we should instead detect that the duplicate iosignaldfds are registered. Note that we do need to allow the same fd to be multiple times, but not with exactly the same address/match etc.
Michael S. Tsirkin wrote: > On Tue, Jul 07, 2009 at 03:27:49PM +0300, Avi Kivity wrote: > >> On 07/07/2009 03:22 PM, Michael S. Tsirkin wrote: >> >>> On Tue, Jul 07, 2009 at 02:53:18PM +0300, Avi Kivity wrote: >>> >>> >>>>>> + /* address-range must be precise for a hit */ >>>>>> >>>>>> >>>>>> >>>>> So there's apparently no way to specify that >>>>> you want 1,2, or 4 byte writes at address X? >>>>> >>>>> >>>>> >>>> Why would you want that? >>>> >>>> >>> Donnu. Why would anyone want to catch 8 byte writes at all? >>> >>> >> One of the natural write sizes. >> >> >>> Seriously, why add artificial limitations? >>> IMO, addr=0,len=1 and addr=0,len=2 should not conflict. >>> >>> >>> >> They should not conflict, but a two byte write need not hit a one byte >> registration. >> > > Yes. That's exactly what I'm saying. I think it should be possible to > create 2 fds: > > addr = 0 > len = 1 > addr = 0 > len = 2 > and at most one will ever trigger. > > But current code will not let you create the second one. > > Note that this was by design to keep the code simple since we don't have a (known) use case for overlap. At the very least, you have to address how data subsets are handled. But do we really need that functionality? -Greg
On 07/07/2009 03:51 PM, Michael S. Tsirkin wrote: > >>> Seriously, why add artificial limitations? >>> IMO, addr=0,len=1 and addr=0,len=2 should not conflict. >>> >>> >>> >> They should not conflict, but a two byte write need not hit a one byte >> registration. >> > > Yes. That's exactly what I'm saying. I think it should be possible to > create 2 fds: > > addr = 0 > len = 1 > addr = 0 > len = 2 > and at most one will ever trigger. > > But current code will not let you create the second one. > I agree then. Good catch.
On Tue, Jul 07, 2009 at 03:56:09PM +0300, Avi Kivity wrote: > On 07/07/2009 03:48 PM, Michael S. Tsirkin wrote: >>>>> + >>>>> + __kvm_io_bus_unregister_dev(bus,&p->dev); >>>>> + iosignalfd_release(p); >>>>> >>>>> >>>> a single deassign removed multiple irqfds? Looks ugly. >>>> >>>> >>> Avi requested this general concept. >>> >> >> Really? Avi, could you explain? I would think each >> assign needs to be matched with 1 deassign. No? >> > > Doesn't it follow naturally? Yes. > How can a single deassign remove multiple > fds (unless all were registered with exactly the same arguments)? > Maybe we should instead detect that the duplicate iosignaldfds are > registered. > > Note that we do need to allow the same fd to be multiple times, but not > with exactly the same address/match etc.
Michael S. Tsirkin wrote: > On Tue, Jul 07, 2009 at 08:15:08AM -0400, Gregory Haskins wrote: > >> Michael S. Tsirkin wrote: >> >>> Some comments below. Sorry, I know it's late in the series, but >>> previously I've been too confused with complicated locking to notice >>> anything else :(. >>> >>> On Mon, Jul 06, 2009 at 04:33:21PM -0400, Gregory Haskins wrote: >>> >>> >>> >>>> +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) /* is a pio (otherwise mmio) */ >>>> +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 2) >>>> + >>>> +struct kvm_iosignalfd { >>>> + __u64 trigger; >>>> >>>> >>> for length <8, it's the 8*len least significant bits that are used, right? >>> That's a bit ugly ... Maybe just put an 8 byte array here instead, then >>> the first len bytes are valid. >>> >>> >> The original series uses an array that I kmalloc'ed to size, or left it >> NULL for a wildcard. Avi didn't like this and requested a u64 for all >> values. I don't care either way, but since you two are asking for >> conflicting designs, I will let you debate. >> > > It turns out the io bus will be changed in the future. > Let's just document the usage, and check that unused bits > are zeroed. > > >>>> + struct kvm_io_device dev; >>>> + int wildcard:1; >>>> >>>> >>> don't use bitfields >>> >>> >> bool? >> > > sure > > >>>> +} >>>> + >>>> +/* >>>> + * MMIO/PIO writes trigger an event if the addr/val match >>>> + */ >>>> >>>> >>> single line comment can look like this: >>> /* MMIO/PIO writes trigger an event if the addr/val match */ >>> >>> >>> >> Ack >> >> >>>> +static int >>>> +iosignalfd_write(struct kvm_io_device *this, gpa_t addr, int len, >>>> + const void *val) >>>> +{ >>>> + struct _iosignalfd *p = to_iosignalfd(this); >>>> + >>>> + if (!iosignalfd_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 >>>> +iosignalfd_destructor(struct kvm_io_device *this) >>>> +{ >>>> + struct _iosignalfd *p = to_iosignalfd(this); >>>> + >>>> + iosignalfd_release(p); >>>> +} >>>> + >>>> +static const struct kvm_io_device_ops iosignalfd_ops = { >>>> + .write = iosignalfd_write, >>>> + .destructor = iosignalfd_destructor, >>>> +}; >>>> + >>>> +static bool >>>> +iosignalfd_overlap(struct _iosignalfd *lhs, struct _iosignalfd *rhs) >>>> >>>> >>> this checks both region overlap and data collision. >>> better split into two helpers? >>> >>> >>> >> Why? >> > > Because it says iosignalfd_overlap but that's not what it does? > It would seem to me that that is exactly what it does. Given that I wrote it, I'm sure my perspective is skewed, so let me turn it around on you. Why do you think "overlap" is inaccurate? > >>>> +{ >>>> + /* >>>> + * Check for completely non-overlapping regions. We can simply >>>> + * return "false" for non-overlapping regions and be done with >>>> + * it. >>>> + */ >>>> >>>> >>> done with it -> ignore the value >>> >>> >>> >> I think that is a valid expression (at least here in the states), >> > > I'm always interested in improving my english :) I'm sure its slang and not proper english, so don't take it too seriously ;) > here's what I thought: > > "done with it" says we skip the rest of the function. "ignore the value" > says skip the value check. So I was trying to say let's be more > specific. > > Isn't that what it means? > Yes, you are right. I thought you were saying the comment was somehow wrong. But I see now you are just clarifying it. > >> but >> ok. Note that "false" means we are accepting the request, not ignoring >> any value. I will construct a better comment either way. >> > > Maybe name a function in a way that makes this explicit? > > Sure >>>> + >>>> + if ((lhs->addr + lhs->length) <= rhs->addr) >>>> >>>> >>> this math can overflow. >>> >>> >>> >> Well, we should probably have vetted that during assign since >> addr+length that overflows is not a valid region. I will put a check in >> for that. >> > > add = ~0x0ULL, len = 1 should be valid. > You'll have to make the math not overflow. > > Yes, understood. >>>> + >>>> + /* >>>> + * If we get here, we know there is *some* overlap, but we don't >>>> + * yet know how much. >>>> >>>> >>> how much? >>> >>> >> Well, as stated we don't know yet. >> > > So why tell me :)? > What I mean is this statement (especially the the part of the statement > after the comma) does not add useful information. > What I was trying to convey is that the next section of code tries to narrow the amount of overlap down further. If it bothers you, I will just remove the comment. > >>> >>> >>>> Make sure its a "precise" overlap, or >>>> >>>> >>> precise overlap -> address/len pairs match >>> >>> >>> >> Precisely. >> > > so say so :) > Ok > >>>> + * its rejected as incompatible >>>> + */ >>>> >>>> >>> "rejected" does not seem to make sense in the context of a boolean >>> function >>> >>> >>> >> Why? true = rejected, false = accepted. Seems boolean to me. >> > > How should I know that? Rename it to iosignalfd_rejected? > Dunno.. Seems clear to me already: collision = true if overlap = true. collision = reject the request to create a new object on grounds that we already have one in that spot. I don't really care what we call it, but I don't currently see a superior way to describe what I am doing that isn't just a synonym. > >> Whats >> wrong with that? >> > > If you want to return 0 on success, != 0 on failure, > make the function int. > > I don't want that. I want to know true or false on whether we have a collision. A collision is defined by whether there is overlap with any existing object. >>>> + >>>> +/* assumes kvm->slots_lock write-lock held */ >>>> >>>> >>> it seems you only need read lock? >>> >>> >>> >> The caller needs write-lock, so we just inherit that state. I can >> update the comment though (I just ran a find/replace on "kvm->lock held" >> while updating to your new interface, thus the vague comment) >> > > I guess so. > > >>>> +static bool >>>> +iosignalfd_check_collision(struct kvm *kvm, struct _iosignalfd *p) >>>> +{ >>>> + struct _iosignalfd *_p; >>>> + >>>> + list_for_each_entry(_p, &kvm->iosignalfds, list) >>>> + if (iosignalfd_overlap(_p, p)) >>>> >>>> >>> This looks wrong: let's assume I want one signal with length 1 and one >>> with length 2 at address 0. They never trigger together, so it should >>> be ok to have 2 such devices. >>> >>> >> We have previously decided to not support mis-matched overlaps. It's >> more complicated to handle, and there isn't a compelling use-case for it >> that I am aware of. >> > > That's not what I propose. By all means len = X should only catch > len = X and not len = X - 1. > > However, I think it makes sense to > allow both len = 2 and len = 1 at the same address even though > they seem to overlap. And all you really need to do is simplify > the code: replace the tricky overlap logic with simple > > if (rhs->addr == lhs->addr && rhs->len == lhs->len) > reject > else > accept > > (+add wildcard thing) > Hmm..ok. I can't imagine anyone using that, but it seems simple enough to implement. > >>>> + if (p->eventfd != eventfd) >>>> + continue; >>>> >>>> >>> So for deassign, you ignore all arguments besides fd? Is this >>> intentional? Looks strange - think of multiple addresses triggering a >>> single eventfd. But if so, it's better to have a different ioctl with >>> just the fields we need. >>> >>> >> Hmm... I suspect the check for a range-match got lost along the way. I >> agree we should probably qualify this with more than just the eventfd. >> >> >>> >>> >>>> + >>>> + __kvm_io_bus_unregister_dev(bus, &p->dev); >>>> + iosignalfd_release(p); >>>> >>>> >>> a single deassign removed multiple irqfds? Looks ugly. >>> >>> >> Avi requested this general concept. >> > > Really? Avi, could you explain? I would think each > assign needs to be matched with 1 deassign. No? > >
Avi Kivity wrote: > (adding Davide, there's a small comment for you in the middle, search > for eventfd) > > On 07/07/2009 02:20 PM, Michael S. Tsirkin wrote: >> >>> @@ -307,6 +307,19 @@ struct kvm_guest_debug { >>> struct kvm_guest_debug_arch arch; >>> }; >>> >>> +#define KVM_IOSIGNALFD_FLAG_TRIGGER (1<< 0) /* trigger is valid */ >>> >> >> can we rename trigger -> value? >> > > Or maybe data_match? Yeah, at the least I should be consistent with trigger/match > > Speaking of renames, how about IOSIGNALFD -> IOEVENTFD? I have some > vague uneasiness seeing signals all the time. Sure, that works for me. -Greg
On Tue, Jul 07, 2009 at 08:56:43AM -0400, Gregory Haskins wrote: > Michael S. Tsirkin wrote: > > On Tue, Jul 07, 2009 at 03:27:49PM +0300, Avi Kivity wrote: > > > >> On 07/07/2009 03:22 PM, Michael S. Tsirkin wrote: > >> > >>> On Tue, Jul 07, 2009 at 02:53:18PM +0300, Avi Kivity wrote: > >>> > >>> > >>>>>> + /* address-range must be precise for a hit */ > >>>>>> > >>>>>> > >>>>>> > >>>>> So there's apparently no way to specify that > >>>>> you want 1,2, or 4 byte writes at address X? > >>>>> > >>>>> > >>>>> > >>>> Why would you want that? > >>>> > >>>> > >>> Donnu. Why would anyone want to catch 8 byte writes at all? > >>> > >>> > >> One of the natural write sizes. > >> > >> > >>> Seriously, why add artificial limitations? > >>> IMO, addr=0,len=1 and addr=0,len=2 should not conflict. > >>> > >>> > >>> > >> They should not conflict, but a two byte write need not hit a one byte > >> registration. > >> > > > > Yes. That's exactly what I'm saying. I think it should be possible to > > create 2 fds: > > > > addr = 0 > > len = 1 > > addr = 0 > > len = 2 > > and at most one will ever trigger. > > > > But current code will not let you create the second one. > > > > > Note that this was by design to keep the code simple since we don't have > a (known) use case for overlap. At the very least, you have to address > how data subsets are handled. But do we really need that functionality? > > -Greg > Hey, forget about overlap. Overlap does not exist as a concept. You now spend a lot of effort to detect it. Kill all that code, and just do this on assignment: list_for_each(...) if (rhs->add == lhs->addr && rhs->len == lhs->len && (rhs->wildcard || lhs->wildcard || rhs->data == lhs->data)) return -EEXIST;
Michael S. Tsirkin wrote: > On Tue, Jul 07, 2009 at 08:56:43AM -0400, Gregory Haskins wrote: > >> Michael S. Tsirkin wrote: >> >>> On Tue, Jul 07, 2009 at 03:27:49PM +0300, Avi Kivity wrote: >>> >>> >>>> On 07/07/2009 03:22 PM, Michael S. Tsirkin wrote: >>>> >>>> >>>>> On Tue, Jul 07, 2009 at 02:53:18PM +0300, Avi Kivity wrote: >>>>> >>>>> >>>>> >>>>>>>> + /* address-range must be precise for a hit */ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> So there's apparently no way to specify that >>>>>>> you want 1,2, or 4 byte writes at address X? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Why would you want that? >>>>>> >>>>>> >>>>>> >>>>> Donnu. Why would anyone want to catch 8 byte writes at all? >>>>> >>>>> >>>>> >>>> One of the natural write sizes. >>>> >>>> >>>> >>>>> Seriously, why add artificial limitations? >>>>> IMO, addr=0,len=1 and addr=0,len=2 should not conflict. >>>>> >>>>> >>>>> >>>>> >>>> They should not conflict, but a two byte write need not hit a one byte >>>> registration. >>>> >>>> >>> Yes. That's exactly what I'm saying. I think it should be possible to >>> create 2 fds: >>> >>> addr = 0 >>> len = 1 >>> addr = 0 >>> len = 2 >>> and at most one will ever trigger. >>> >>> But current code will not let you create the second one. >>> >>> >>> >> Note that this was by design to keep the code simple since we don't have >> a (known) use case for overlap. At the very least, you have to address >> how data subsets are handled. But do we really need that functionality? >> >> -Greg >> >> > > Hey, forget about overlap. Overlap does not exist as a concept. You now > spend a lot of effort to detect it. Kill all that code, and just do > this on assignment: > > list_for_each(...) > if (rhs->add == lhs->addr && rhs->len == lhs->len && > (rhs->wildcard || lhs->wildcard || rhs->data == lhs->data)) > return -EEXIST; > > I like it. Will do for v10. Thanks Michael, -Greg
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 0e74d98..6e4b2f5 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1204,6 +1204,7 @@ int kvm_dev_ioctl_check_extension(long ext) case KVM_CAP_IRQ_INJECT_STATUS: case KVM_CAP_ASSIGN_DEV_IRQ: case KVM_CAP_IRQFD: + case KVM_CAP_IOSIGNALFD: case KVM_CAP_PIT2: r = 1; break; diff --git a/include/linux/kvm.h b/include/linux/kvm.h index 76c6408..236f12d 100644 --- a/include/linux/kvm.h +++ b/include/linux/kvm.h @@ -307,6 +307,19 @@ struct kvm_guest_debug { struct kvm_guest_debug_arch arch; }; +#define KVM_IOSIGNALFD_FLAG_TRIGGER (1 << 0) /* trigger is valid */ +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) /* is a pio (otherwise mmio) */ +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 2) + +struct kvm_iosignalfd { + __u64 trigger; + __u64 addr; /* legal pio/mmio address */ + __u32 len; /* 1, 2, 4, or 8 bytes */ + __s32 fd; + __u32 flags; + __u8 pad[36]; +}; + #define KVM_TRC_SHIFT 16 /* * kvm trace categories @@ -409,6 +422,7 @@ struct kvm_guest_debug { #define KVM_CAP_PIT2 33 #endif #define KVM_CAP_SET_BOOT_CPU_ID 34 +#define KVM_CAP_IOSIGNALFD 35 #ifdef KVM_CAP_IRQ_ROUTING @@ -517,6 +531,7 @@ struct kvm_irqfd { #define KVM_IRQFD _IOW(KVMIO, 0x76, struct kvm_irqfd) #define KVM_CREATE_PIT2 _IOW(KVMIO, 0x77, struct kvm_pit_config) #define KVM_SET_BOOT_CPU_ID _IO(KVMIO, 0x78) +#define KVM_IOSIGNALFD _IOW(KVMIO, 0x79, struct kvm_iosignalfd) /* * ioctls for vcpu fds diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 306bc67..5099416 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -154,6 +154,7 @@ struct kvm { spinlock_t lock; struct list_head items; } irqfds; + struct list_head iosignalfds; #endif struct kvm_vm_stat stat; struct kvm_arch arch; @@ -532,19 +533,24 @@ static inline void kvm_free_irq_routing(struct kvm *kvm) {} #ifdef CONFIG_HAVE_KVM_EVENTFD -void kvm_irqfd_init(struct kvm *kvm); +void kvm_eventfd_init(struct kvm *kvm); int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags); void kvm_irqfd_release(struct kvm *kvm); +int kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args); #else -static inline void kvm_irqfd_init(struct kvm *kvm) {} +static inline void kvm_eventfd_init(struct kvm *kvm) {} static inline int kvm_irqfd(struct kvm *kvm, int fd, int gsi, int flags) { return -EINVAL; } static inline void kvm_irqfd_release(struct kvm *kvm) {} +static inline int kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) +{ + return -ENOSYS; +} #endif /* CONFIG_HAVE_KVM_EVENTFD */ diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c index 4092b8d..c03b619 100644 --- a/virt/kvm/eventfd.c +++ b/virt/kvm/eventfd.c @@ -21,6 +21,7 @@ */ #include <linux/kvm_host.h> +#include <linux/kvm.h> #include <linux/workqueue.h> #include <linux/syscalls.h> #include <linux/wait.h> @@ -28,6 +29,9 @@ #include <linux/file.h> #include <linux/list.h> #include <linux/eventfd.h> +#include <linux/kernel.h> + +#include "iodev.h" /* * -------------------------------------------------------------------- @@ -234,10 +238,12 @@ fail: } void -kvm_irqfd_init(struct kvm *kvm) +kvm_eventfd_init(struct kvm *kvm) { spin_lock_init(&kvm->irqfds.lock); INIT_LIST_HEAD(&kvm->irqfds.items); + + INIT_LIST_HEAD(&kvm->iosignalfds); } /* @@ -327,3 +333,275 @@ static void __exit irqfd_module_exit(void) module_init(irqfd_module_init); module_exit(irqfd_module_exit); + +/* + * -------------------------------------------------------------------- + * iosignalfd: 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 _iosignalfd { + struct list_head list; + u64 addr; + size_t length; + struct eventfd_ctx *eventfd; + u64 match; + struct kvm_io_device dev; + int wildcard:1; +}; + +static inline struct _iosignalfd * +to_iosignalfd(struct kvm_io_device *dev) +{ + return container_of(dev, struct _iosignalfd, dev); +} + +static void +iosignalfd_release(struct _iosignalfd *p) +{ + eventfd_ctx_put(p->eventfd); + list_del(&p->list); + kfree(p); +} + +static bool +iosignalfd_in_range(struct _iosignalfd *p, gpa_t addr, int len, const void *val) +{ + u64 _val; + + if (!(addr == p->addr && len == p->length)) + /* 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->match ? true : false; +} + +/* + * MMIO/PIO writes trigger an event if the addr/val match + */ +static int +iosignalfd_write(struct kvm_io_device *this, gpa_t addr, int len, + const void *val) +{ + struct _iosignalfd *p = to_iosignalfd(this); + + if (!iosignalfd_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 +iosignalfd_destructor(struct kvm_io_device *this) +{ + struct _iosignalfd *p = to_iosignalfd(this); + + iosignalfd_release(p); +} + +static const struct kvm_io_device_ops iosignalfd_ops = { + .write = iosignalfd_write, + .destructor = iosignalfd_destructor, +}; + +static bool +iosignalfd_overlap(struct _iosignalfd *lhs, struct _iosignalfd *rhs) +{ + /* + * Check for completely non-overlapping regions. We can simply + * return "false" for non-overlapping regions and be done with + * it. + */ + if ((rhs->addr + rhs->length) <= lhs->addr) + return false; + + if ((lhs->addr + lhs->length) <= rhs->addr) + return false; + + /* + * If we get here, we know there is *some* overlap, but we don't + * yet know how much. Make sure its a "precise" overlap, or + * its rejected as incompatible + */ + if (lhs->addr != rhs->addr) + return true; + + if (lhs->length != rhs->length) + return true; + + /* + * If we get here, the request should be a precise overlap + * between rhs+lhs. The only thing left to check is for + * data-match overlap. If the data match is distinctly different + * we can allow the two to co-exist. Any kind of wild-card + * consitutes an incompatible range, so reject any wild-cards, + * or if the match token is identical. + */ + if (lhs->wildcard || rhs->wildcard || lhs->match == rhs->match) + return true; + + return false; +} + +/* assumes kvm->slots_lock write-lock held */ +static bool +iosignalfd_check_collision(struct kvm *kvm, struct _iosignalfd *p) +{ + struct _iosignalfd *_p; + + list_for_each_entry(_p, &kvm->iosignalfds, list) + if (iosignalfd_overlap(_p, p)) + return true; + + return false; +} + +static int +kvm_assign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) +{ + int pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO; + struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus; + struct _iosignalfd *p; + struct eventfd_ctx *eventfd; + int ret; + + switch (args->len) { + case 1: + case 2: + case 4: + case 8: + break; + default: + return -EINVAL; + } + + 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; + p->length = args->len; + p->eventfd = eventfd; + + /* + * A trigger address is optional, otherwise this is a wildcard + */ + if (args->flags & KVM_IOSIGNALFD_FLAG_TRIGGER) + p->match = args->trigger; + else + p->wildcard = true; + + down_write(&kvm->slots_lock); + + /* Verify that there isnt a match already */ + if (iosignalfd_check_collision(kvm, p)) { + ret = -EEXIST; + goto unlock_fail; + } + + kvm_iodevice_init(&p->dev, &iosignalfd_ops); + + ret = __kvm_io_bus_register_dev(bus, &p->dev); + if (ret < 0) + goto unlock_fail; + + list_add_tail(&p->list, &kvm->iosignalfds); + + up_write(&kvm->slots_lock); + + return 0; + +unlock_fail: + up_write(&kvm->slots_lock); +fail: + /* + * it would have never made it to the list in the failure path, so + * we dont need to worry about removing it + */ + kfree(p); + + eventfd_ctx_put(eventfd); + + return ret; +} + + +static int +kvm_deassign_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) +{ + int pio = args->flags & KVM_IOSIGNALFD_FLAG_PIO; + struct kvm_io_bus *bus = pio ? &kvm->pio_bus : &kvm->mmio_bus; + struct _iosignalfd *p, *tmp; + struct eventfd_ctx *eventfd; + int ret = 0; + + eventfd = eventfd_ctx_fdget(args->fd); + if (IS_ERR(eventfd)) + return PTR_ERR(eventfd); + + down_write(&kvm->slots_lock); + + list_for_each_entry_safe(p, tmp, &kvm->iosignalfds, list) { + + if (p->eventfd != eventfd) + continue; + + __kvm_io_bus_unregister_dev(bus, &p->dev); + iosignalfd_release(p); + } + + up_write(&kvm->slots_lock); + + eventfd_ctx_put(eventfd); + + return ret; +} + +int +kvm_iosignalfd(struct kvm *kvm, struct kvm_iosignalfd *args) +{ + if (args->flags & KVM_IOSIGNALFD_FLAG_DEASSIGN) + return kvm_deassign_iosignalfd(kvm, args); + + return kvm_assign_iosignalfd(kvm, args); +} diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index 11595c7..5ac381b 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -979,7 +979,7 @@ static struct kvm *kvm_create_vm(void) spin_lock_init(&kvm->mmu_lock); spin_lock_init(&kvm->requests_lock); kvm_io_bus_init(&kvm->pio_bus); - kvm_irqfd_init(kvm); + kvm_eventfd_init(kvm); mutex_init(&kvm->lock); mutex_init(&kvm->irq_lock); kvm_io_bus_init(&kvm->mmio_bus); @@ -2271,6 +2271,15 @@ static long kvm_vm_ioctl(struct file *filp, r = kvm_irqfd(kvm, data.fd, data.gsi, data.flags); break; } + case KVM_IOSIGNALFD: { + struct kvm_iosignalfd data; + + r = -EFAULT; + if (copy_from_user(&data, argp, sizeof data)) + goto out; + r = kvm_iosignalfd(kvm, &data); + break; + } #ifdef CONFIG_KVM_APIC_ARCHITECTURE case KVM_SET_BOOT_CPU_ID: r = 0;
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. -------------------- Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- arch/x86/kvm/x86.c | 1 include/linux/kvm.h | 15 ++ include/linux/kvm_host.h | 10 +- virt/kvm/eventfd.c | 280 ++++++++++++++++++++++++++++++++++++++++++++++ virt/kvm/kvm_main.c | 11 ++ 5 files changed, 313 insertions(+), 4 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html