* [KVM PATCH v3 0/4] iosignalfd
@ 2009-05-21 16:51 Gregory Haskins
2009-05-21 16:51 ` [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use Gregory Haskins
` (3 more replies)
0 siblings, 4 replies; 9+ messages in thread
From: Gregory Haskins @ 2009-05-21 16:51 UTC (permalink / raw)
To: kvm; +Cc: linux-kernel, avi, mtosatti
(Applies to kvm.git/master:7391a6d5)
This is v3 of the series. For more details, please see the header to
patch 4/4.
This series has been tested against the kvm-eventfd unit test, and
appears to be functioning properly. You can download this test here:
ftp://ftp.novell.com/dev/ghaskins/kvm-eventfd.tar.bz2
(Note that the test released with irqfd had a bug in it that prevented
iosignalfd from working properly. The tarball has been updated with the
fix)
This series is ready to be considered for inclusion, pending any further
review comments.
[
Changelog:
v3:
*) fixed patch 2/4 to handle error cases instead of BUG_ON
*) implemented same HAVE_EVENTFD protection mechanism as
irqfd to prevent compilation errors on unsupported arches
*) completed testing
*) rebased to kvm.git/master:7391a6d5
v2:
*) added optional data-matching capability (via cookie field)
*) changed name from iofd to iosignalfd
*) added io_bus unregister function
*) implemented deassign feature
v1:
*) original release (integrated into irqfd v7 series as "iofd")
]
---
Gregory Haskins (4):
kvm: add iosignalfd support
kvm: add io_bus unregister function
kvm: add return value to kvm_io_bus_register_dev
eventfd: export eventfd interfaces for module use
arch/x86/kvm/i8254.c | 27 +++++--
arch/x86/kvm/i8259.c | 9 ++
arch/x86/kvm/x86.c | 1
fs/eventfd.c | 3 +
include/linux/kvm.h | 15 ++++
include/linux/kvm_host.h | 18 ++++-
virt/kvm/coalesced_mmio.c | 8 ++
virt/kvm/eventfd.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
virt/kvm/ioapic.c | 9 ++
virt/kvm/kvm_main.c | 60 ++++++++++++++--
10 files changed, 286 insertions(+), 29 deletions(-)
--
Signature
^ permalink raw reply [flat|nested] 9+ messages in thread* [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use 2009-05-21 16:51 [KVM PATCH v3 0/4] iosignalfd Gregory Haskins @ 2009-05-21 16:51 ` Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 2/4] kvm: add return value to kvm_io_bus_register_dev Gregory Haskins ` (2 subsequent siblings) 3 siblings, 0 replies; 9+ messages in thread From: Gregory Haskins @ 2009-05-21 16:51 UTC (permalink / raw) To: kvm; +Cc: linux-kernel, avi, mtosatti We want to use eventfd from KVM which can be compiled as a module, so export the interfaces. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- fs/eventfd.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/eventfd.c b/fs/eventfd.c index 2a701d5..3f0e197 100644 --- a/fs/eventfd.c +++ b/fs/eventfd.c @@ -16,6 +16,7 @@ #include <linux/anon_inodes.h> #include <linux/eventfd.h> #include <linux/syscalls.h> +#include <linux/module.h> struct eventfd_ctx { wait_queue_head_t wqh; @@ -56,6 +57,7 @@ int eventfd_signal(struct file *file, int n) return n; } +EXPORT_SYMBOL_GPL(eventfd_signal); static int eventfd_release(struct inode *inode, struct file *file) { @@ -197,6 +199,7 @@ struct file *eventfd_fget(int fd) return file; } +EXPORT_SYMBOL_GPL(eventfd_fget); SYSCALL_DEFINE2(eventfd2, unsigned int, count, int, flags) { ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [KVM PATCH v3 2/4] kvm: add return value to kvm_io_bus_register_dev 2009-05-21 16:51 [KVM PATCH v3 0/4] iosignalfd Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use Gregory Haskins @ 2009-05-21 16:51 ` Gregory Haskins 2009-05-26 15:23 ` Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 3/4] kvm: add io_bus unregister function Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 4/4] kvm: add iosignalfd support Gregory Haskins 3 siblings, 1 reply; 9+ messages in thread From: Gregory Haskins @ 2009-05-21 16:51 UTC (permalink / raw) To: kvm; +Cc: linux-kernel, avi, mtosatti Today this function 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 enhance this API to return an error code on failure. We also fix up all the callsites to check the return code, handle any failures, and percolate the error up to the caller. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- arch/x86/kvm/i8254.c | 27 +++++++++++++++++---------- arch/x86/kvm/i8259.c | 9 ++++++++- include/linux/kvm_host.h | 4 ++-- virt/kvm/coalesced_mmio.c | 8 ++++++-- virt/kvm/ioapic.c | 9 +++++++-- virt/kvm/kvm_main.c | 7 +++++-- 6 files changed, 45 insertions(+), 19 deletions(-) diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c index 4d6f0d2..3ef8b1b 100644 --- a/arch/x86/kvm/i8254.c +++ b/arch/x86/kvm/i8254.c @@ -564,33 +564,36 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm) { 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; 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; + + mutex_init(&pit->pit_state.lock); + mutex_lock(&pit->pit_state.lock); + spin_lock_init(&pit->pit_state.inject_lock); kvm->arch.vpit = pit; pit->kvm = kvm; @@ -611,6 +614,10 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm) kvm_register_irq_mask_notifier(kvm, 0, &pit->mask_notifier); return pit; + +fail: + kfree(pit); + return NULL; } void kvm_free_pit(struct kvm *kvm) diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c index 1ccb50c..0caf7d4 100644 --- a/arch/x86/kvm/i8259.c +++ b/arch/x86/kvm/i8259.c @@ -519,6 +519,8 @@ static void pic_irq_request(void *opaque, int level) struct kvm_pic *kvm_create_pic(struct kvm *kvm) { struct kvm_pic *s; + int ret; + s = kzalloc(sizeof(struct kvm_pic), GFP_KERNEL); if (!s) return NULL; @@ -538,6 +540,11 @@ struct kvm_pic *kvm_create_pic(struct kvm *kvm) s->dev.write = picdev_write; s->dev.in_range = picdev_in_range; s->dev.private = s; - kvm_io_bus_register_dev(&kvm->pio_bus, &s->dev); + ret = kvm_io_bus_register_dev(&kvm->pio_bus, &s->dev); + if (ret < 0) { + kfree(s); + return NULL; + } + return s; } diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 28bd112..5289552 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -61,8 +61,8 @@ 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, + struct kvm_io_device *dev); struct kvm_vcpu { struct kvm *kvm; diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c index 5ae620d..ede9087 100644 --- a/virt/kvm/coalesced_mmio.c +++ b/virt/kvm/coalesced_mmio.c @@ -86,6 +86,7 @@ static void coalesced_mmio_destructor(struct kvm_io_device *this) int kvm_coalesced_mmio_init(struct kvm *kvm) { struct kvm_coalesced_mmio_dev *dev; + int ret; dev = kzalloc(sizeof(struct kvm_coalesced_mmio_dev), GFP_KERNEL); if (!dev) @@ -96,9 +97,12 @@ int kvm_coalesced_mmio_init(struct kvm *kvm) dev->dev.private = dev; dev->kvm = kvm; kvm->coalesced_mmio_dev = dev; - kvm_io_bus_register_dev(&kvm->mmio_bus, &dev->dev); - return 0; + ret = kvm_io_bus_register_dev(&kvm->mmio_bus, &dev->dev); + if (ret < 0) + kfree(dev); + + return ret; } int kvm_vm_ioctl_register_coalesced_mmio(struct kvm *kvm, diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c index 1eddae9..9be89f5 100644 --- a/virt/kvm/ioapic.c +++ b/virt/kvm/ioapic.c @@ -317,6 +317,7 @@ void kvm_ioapic_reset(struct kvm_ioapic *ioapic) int kvm_ioapic_init(struct kvm *kvm) { struct kvm_ioapic *ioapic; + int ret; ioapic = kzalloc(sizeof(struct kvm_ioapic), GFP_KERNEL); if (!ioapic) @@ -328,7 +329,11 @@ int kvm_ioapic_init(struct kvm *kvm) ioapic->dev.in_range = ioapic_in_range; ioapic->dev.private = ioapic; ioapic->kvm = kvm; - kvm_io_bus_register_dev(&kvm->mmio_bus, &ioapic->dev); - return 0; + + ret = kvm_io_bus_register_dev(&kvm->mmio_bus, &ioapic->dev); + if (ret < 0) + kfree(ioapic); + + return ret; } diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index de042cb..c71f276 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2463,11 +2463,14 @@ struct kvm_io_device *kvm_io_bus_find_dev(struct kvm_io_bus *bus, return NULL; } -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, struct kvm_io_device *dev) { - BUG_ON(bus->dev_count > (NR_IOBUS_DEVS-1)); + if (bus->dev_count > (NR_IOBUS_DEVS-1)) + return -ENOSPC; bus->devs[bus->dev_count++] = dev; + + return 0; } static struct notifier_block kvm_cpu_notifier = { ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [KVM PATCH v3 2/4] kvm: add return value to kvm_io_bus_register_dev 2009-05-21 16:51 ` [KVM PATCH v3 2/4] kvm: add return value to kvm_io_bus_register_dev Gregory Haskins @ 2009-05-26 15:23 ` Gregory Haskins 0 siblings, 0 replies; 9+ messages in thread From: Gregory Haskins @ 2009-05-26 15:23 UTC (permalink / raw) To: Gregory Haskins; +Cc: kvm, linux-kernel, avi, mtosatti [-- Attachment #1: Type: text/plain, Size: 6812 bytes --] Gregory Haskins wrote: > Today this function 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 enhance this API to return an error code on failure. > > We also fix up all the callsites to check the return code, handle any > failures, and percolate the error up to the caller. > > Signed-off-by: Gregory Haskins <ghaskins@novell.com> > --- > > arch/x86/kvm/i8254.c | 27 +++++++++++++++++---------- > arch/x86/kvm/i8259.c | 9 ++++++++- > include/linux/kvm_host.h | 4 ++-- > virt/kvm/coalesced_mmio.c | 8 ++++++-- > virt/kvm/ioapic.c | 9 +++++++-- > virt/kvm/kvm_main.c | 7 +++++-- > 6 files changed, 45 insertions(+), 19 deletions(-) > > diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c > index 4d6f0d2..3ef8b1b 100644 > --- a/arch/x86/kvm/i8254.c > +++ b/arch/x86/kvm/i8254.c > @@ -564,33 +564,36 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm) > { > 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; > > 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; > + > + mutex_init(&pit->pit_state.lock); > + mutex_lock(&pit->pit_state.lock); > + spin_lock_init(&pit->pit_state.inject_lock); > > kvm->arch.vpit = pit; > pit->kvm = kvm; > @@ -611,6 +614,10 @@ struct kvm_pit *kvm_create_pit(struct kvm *kvm) > kvm_register_irq_mask_notifier(kvm, 0, &pit->mask_notifier); > > return pit; > + > +fail: > + kfree(pit); > Hmm, this is broken. I need to also potentially free any successfully registered devices. Looks like we need a v4 afterall. > + return NULL; > } > > void kvm_free_pit(struct kvm *kvm) > diff --git a/arch/x86/kvm/i8259.c b/arch/x86/kvm/i8259.c > index 1ccb50c..0caf7d4 100644 > --- a/arch/x86/kvm/i8259.c > +++ b/arch/x86/kvm/i8259.c > @@ -519,6 +519,8 @@ static void pic_irq_request(void *opaque, int level) > struct kvm_pic *kvm_create_pic(struct kvm *kvm) > { > struct kvm_pic *s; > + int ret; > + > s = kzalloc(sizeof(struct kvm_pic), GFP_KERNEL); > if (!s) > return NULL; > @@ -538,6 +540,11 @@ struct kvm_pic *kvm_create_pic(struct kvm *kvm) > s->dev.write = picdev_write; > s->dev.in_range = picdev_in_range; > s->dev.private = s; > - kvm_io_bus_register_dev(&kvm->pio_bus, &s->dev); > + ret = kvm_io_bus_register_dev(&kvm->pio_bus, &s->dev); > + if (ret < 0) { > + kfree(s); > + return NULL; > + } > + > return s; > } > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index 28bd112..5289552 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -61,8 +61,8 @@ 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, > + struct kvm_io_device *dev); > > struct kvm_vcpu { > struct kvm *kvm; > diff --git a/virt/kvm/coalesced_mmio.c b/virt/kvm/coalesced_mmio.c > index 5ae620d..ede9087 100644 > --- a/virt/kvm/coalesced_mmio.c > +++ b/virt/kvm/coalesced_mmio.c > @@ -86,6 +86,7 @@ static void coalesced_mmio_destructor(struct kvm_io_device *this) > int kvm_coalesced_mmio_init(struct kvm *kvm) > { > struct kvm_coalesced_mmio_dev *dev; > + int ret; > > dev = kzalloc(sizeof(struct kvm_coalesced_mmio_dev), GFP_KERNEL); > if (!dev) > @@ -96,9 +97,12 @@ int kvm_coalesced_mmio_init(struct kvm *kvm) > dev->dev.private = dev; > dev->kvm = kvm; > kvm->coalesced_mmio_dev = dev; > - kvm_io_bus_register_dev(&kvm->mmio_bus, &dev->dev); > > - return 0; > + ret = kvm_io_bus_register_dev(&kvm->mmio_bus, &dev->dev); > + if (ret < 0) > + kfree(dev); > + > + return ret; > } > > int kvm_vm_ioctl_register_coalesced_mmio(struct kvm *kvm, > diff --git a/virt/kvm/ioapic.c b/virt/kvm/ioapic.c > index 1eddae9..9be89f5 100644 > --- a/virt/kvm/ioapic.c > +++ b/virt/kvm/ioapic.c > @@ -317,6 +317,7 @@ void kvm_ioapic_reset(struct kvm_ioapic *ioapic) > int kvm_ioapic_init(struct kvm *kvm) > { > struct kvm_ioapic *ioapic; > + int ret; > > ioapic = kzalloc(sizeof(struct kvm_ioapic), GFP_KERNEL); > if (!ioapic) > @@ -328,7 +329,11 @@ int kvm_ioapic_init(struct kvm *kvm) > ioapic->dev.in_range = ioapic_in_range; > ioapic->dev.private = ioapic; > ioapic->kvm = kvm; > - kvm_io_bus_register_dev(&kvm->mmio_bus, &ioapic->dev); > - return 0; > + > + ret = kvm_io_bus_register_dev(&kvm->mmio_bus, &ioapic->dev); > + if (ret < 0) > + kfree(ioapic); > + > + return ret; > } > > diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c > index de042cb..c71f276 100644 > --- a/virt/kvm/kvm_main.c > +++ b/virt/kvm/kvm_main.c > @@ -2463,11 +2463,14 @@ struct kvm_io_device *kvm_io_bus_find_dev(struct kvm_io_bus *bus, > return NULL; > } > > -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, struct kvm_io_device *dev) > { > - BUG_ON(bus->dev_count > (NR_IOBUS_DEVS-1)); > + if (bus->dev_count > (NR_IOBUS_DEVS-1)) > + return -ENOSPC; > > bus->devs[bus->dev_count++] = dev; > + > + return 0; > } > > static struct notifier_block kvm_cpu_notifier = { > > -- > 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 > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [KVM PATCH v3 3/4] kvm: add io_bus unregister function 2009-05-21 16:51 [KVM PATCH v3 0/4] iosignalfd Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 2/4] kvm: add return value to kvm_io_bus_register_dev Gregory Haskins @ 2009-05-21 16:51 ` Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 4/4] kvm: add iosignalfd support Gregory Haskins 3 siblings, 0 replies; 9+ messages in thread From: Gregory Haskins @ 2009-05-21 16:51 UTC (permalink / raw) To: kvm; +Cc: linux-kernel, avi, mtosatti We want to support the notion of dynamic MMIO/PIO registrations and therefore will need to support both register as well as unregister. However, the current io_bus code is structured as a linear array and is not conducive to unregistering, so refactor to allow "holes" in the array. We then enhance the API with an unregister function. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- include/linux/kvm_host.h | 4 +++- virt/kvm/kvm_main.c | 48 ++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 43 insertions(+), 9 deletions(-) diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 5289552..7dcae4b 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -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]; }; @@ -63,6 +63,8 @@ struct kvm_io_device *kvm_io_bus_find_dev(struct kvm_io_bus *bus, gpa_t addr, int len, int is_write); int kvm_io_bus_register_dev(struct kvm_io_bus *bus, struct kvm_io_device *dev); +int kvm_io_bus_unregister_dev(struct kvm_io_bus *bus, + struct kvm_io_device *dev); struct kvm_vcpu { struct kvm *kvm; diff --git a/virt/kvm/kvm_main.c b/virt/kvm/kvm_main.c index c71f276..4c36ac8 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -2435,16 +2435,18 @@ static struct notifier_block kvm_reboot_notifier = { void kvm_io_bus_init(struct kvm_io_bus *bus) { memset(bus, 0, sizeof(*bus)); + spin_lock_init(&bus->lock); } void kvm_io_bus_destroy(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]; - kvm_iodevice_destructor(pos); + if (pos) + kvm_iodevice_destructor(pos); } } @@ -2453,10 +2455,10 @@ 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]; - if (pos->in_range(pos, addr, len, is_write)) + if (pos && pos->in_range(pos, addr, len, is_write)) return pos; } @@ -2465,12 +2467,42 @@ struct kvm_io_device *kvm_io_bus_find_dev(struct kvm_io_bus *bus, int kvm_io_bus_register_dev(struct kvm_io_bus *bus, struct kvm_io_device *dev) { - if (bus->dev_count > (NR_IOBUS_DEVS-1)) - return -ENOSPC; + int i; - bus->devs[bus->dev_count++] = dev; + spin_lock(&bus->lock); - return 0; + for (i = 0; i < NR_IOBUS_DEVS; i++) { + if (bus->devs[i]) + continue; + + bus->devs[i] = dev; + spin_unlock(&bus->lock); + return 0; + } + + spin_unlock(&bus->lock); + + return -ENOSPC; +} + +int kvm_io_bus_unregister_dev(struct kvm_io_bus *bus, struct kvm_io_device *dev) +{ + int i; + + spin_lock(&bus->lock); + + for (i = 0; i < NR_IOBUS_DEVS; i++) { + + if (bus->devs[i] == dev) { + bus->devs[i] = NULL; + spin_unlock(&bus->lock); + return 0; + } + } + + spin_unlock(&bus->lock); + + return -ENOENT; } static struct notifier_block kvm_cpu_notifier = { ^ permalink raw reply related [flat|nested] 9+ messages in thread
* [KVM PATCH v3 4/4] kvm: add iosignalfd support 2009-05-21 16:51 [KVM PATCH v3 0/4] iosignalfd Gregory Haskins ` (2 preceding siblings ...) 2009-05-21 16:51 ` [KVM PATCH v3 3/4] kvm: add io_bus unregister function Gregory Haskins @ 2009-05-21 16:51 ` Gregory Haskins 2009-05-22 22:05 ` Marcelo Tosatti 3 siblings, 1 reply; 9+ messages in thread From: Gregory Haskins @ 2009-05-21 16:51 UTC (permalink / raw) To: kvm; +Cc: linux-kernel, avi, mtosatti 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 | 165 ++++++++++++++++++++++++++++++++++++++++++++++ virt/kvm/kvm_main.c | 11 +++ 5 files changed, 198 insertions(+), 4 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 98c2434..cee63ff 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -1085,6 +1085,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: r = 1; break; case KVM_CAP_COALESCED_MMIO: diff --git a/include/linux/kvm.h b/include/linux/kvm.h index 8f53f24..8162466 100644 --- a/include/linux/kvm.h +++ b/include/linux/kvm.h @@ -292,6 +292,19 @@ struct kvm_guest_debug { struct kvm_guest_debug_arch arch; }; +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 0) +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) +#define KVM_IOSIGNALFD_FLAG_COOKIE (1 << 2) + +struct kvm_iosignalfd { + __u64 cookie; + __u64 addr; + __u32 len; + __u32 fd; + __u32 flags; + __u8 pad[12]; +}; + #define KVM_TRC_SHIFT 16 /* * kvm trace categories @@ -419,6 +432,7 @@ struct kvm_trace_rec { #define KVM_CAP_MCE 31 #endif #define KVM_CAP_IRQFD 32 +#define KVM_CAP_IOSIGNALFD 33 #ifdef KVM_CAP_IRQ_ROUTING @@ -525,6 +539,7 @@ struct kvm_irqfd { _IOW(KVMIO, 0x74, struct kvm_assigned_msix_entry) #define KVM_DEASSIGN_DEV_IRQ _IOW(KVMIO, 0x75, struct kvm_assigned_irq) #define KVM_IRQFD _IOW(KVMIO, 0x76, struct kvm_irqfd) +#define KVM_IOSIGNALFD _IOW(KVMIO, 0x77, struct kvm_iosignalfd) /* * ioctls for vcpu fds diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h index 7dcae4b..5b2be86 100644 --- a/include/linux/kvm_host.h +++ b/include/linux/kvm_host.h @@ -138,6 +138,7 @@ struct kvm { struct kvm_io_bus pio_bus; #ifdef CONFIG_HAVE_KVM_EVENTFD struct list_head irqfds; + struct list_head iosignalfds; #endif struct kvm_vm_stat stat; struct kvm_arch arch; @@ -535,19 +536,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 -EINVAL; +} #endif /* CONFIG_HAVE_KVM_EVENTFD */ diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c index c63ff6a..7700e39 100644 --- a/virt/kvm/eventfd.c +++ b/virt/kvm/eventfd.c @@ -21,12 +21,16 @@ */ #include <linux/kvm_host.h> +#include <linux/kvm.h> #include <linux/workqueue.h> #include <linux/syscalls.h> #include <linux/wait.h> #include <linux/poll.h> #include <linux/file.h> #include <linux/list.h> +#include <linux/eventfd.h> + +#include "iodev.h" /* * -------------------------------------------------------------------- @@ -207,9 +211,10 @@ kvm_deassign_irqfd(struct kvm *kvm, int fd, int gsi) } void -kvm_irqfd_init(struct kvm *kvm) +kvm_eventfd_init(struct kvm *kvm) { INIT_LIST_HEAD(&kvm->irqfds); + INIT_LIST_HEAD(&kvm->iosignalfds); } int @@ -232,3 +237,161 @@ kvm_irqfd_release(struct kvm *kvm) irqfd_release(irqfd); } } + +/* + * -------------------------------------------------------------------- + * 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 { + u64 cookie; + u64 addr; + size_t length; + struct file *file; + struct list_head list; + struct kvm_io_device dev; +}; + +static int +iosignalfd_in_range(struct kvm_io_device *this, gpa_t addr, int len, + int is_write) +{ + struct _iosignalfd *p = (struct _iosignalfd *)this->private; + + return ((addr >= p->addr && (addr < p->addr + p->length))); +} + +/* 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; + + eventfd_signal(iosignalfd->file, 1); +} + +/* reads return all zeros */ +static void +iosignalfd_read(struct kvm_io_device *this, gpa_t addr, int len, void *val) +{ + memset(val, 0, len); +} + +static void +_iosignalfd_destructor(struct _iosignalfd *iosignalfd) +{ + fput(iosignalfd->file); + list_del(&iosignalfd->list); + + kfree(iosignalfd); +} + +static void +iosignalfd_destructor(struct kvm_io_device *this) +{ + struct _iosignalfd *iosignalfd = (struct _iosignalfd *)this->private; + + _iosignalfd_destructor(iosignalfd); +} + +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 *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); + return ret; + } + + iosignalfd = kzalloc(sizeof(*iosignalfd), GFP_KERNEL); + if (!iosignalfd) { + printk(KERN_ERR "iosignalfd: memory pressure\n"); + fput(file); + return -ENOMEM; + } + + iosignalfd->dev.read = iosignalfd_read; + iosignalfd->dev.write = iosignalfd_write; + iosignalfd->dev.in_range = iosignalfd_in_range; + iosignalfd->dev.destructor = iosignalfd_destructor; + iosignalfd->dev.private = iosignalfd; + + iosignalfd->cookie = args->cookie; + iosignalfd->addr = args->addr; + iosignalfd->length = args->len; + iosignalfd->file = file; + INIT_LIST_HEAD(&iosignalfd->list); + + ret = kvm_io_bus_register_dev(bus, &iosignalfd->dev); + if (ret < 0) { + printk(KERN_ERR "iosignalfd: failed to register IODEV: %d\n", + ret); + goto fail; + } + + printk(KERN_DEBUG "registering %s iosignalfd at %llx of size %d\n", + pio ? "PIO" : "MMIO", args->addr, (int)args->len); + + mutex_lock(&kvm->lock); + list_add_tail(&iosignalfd->list, &kvm->iosignalfds); + mutex_unlock(&kvm->lock); + + return 0; + +fail: + /* + * This doesn't take a lock, but the failure case will never result + * in the list being populated anyway + */ + _iosignalfd_destructor(iosignalfd); + + 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 *iosignalfd, *tmp; + + mutex_lock(&kvm->lock); + + list_for_each_entry_safe(iosignalfd, tmp, &kvm->iosignalfds, list) { + if (iosignalfd->addr != args->addr) + continue; + + if ((args->flags & KVM_IOSIGNALFD_FLAG_COOKIE) && + (iosignalfd->cookie != args->cookie)) + continue; + + kvm_io_bus_unregister_dev(bus, &iosignalfd->dev); + _iosignalfd_destructor(iosignalfd); + } + + mutex_unlock(&kvm->lock); + + return 0; +} + +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 4c36ac8..79fdc08 100644 --- a/virt/kvm/kvm_main.c +++ b/virt/kvm/kvm_main.c @@ -983,7 +983,7 @@ static struct kvm *kvm_create_vm(void) atomic_inc(&kvm->mm->mm_count); spin_lock_init(&kvm->mmu_lock); kvm_io_bus_init(&kvm->pio_bus); - kvm_irqfd_init(kvm); + kvm_eventfd_init(kvm); mutex_init(&kvm->lock); kvm_io_bus_init(&kvm->mmio_bus); init_rwsem(&kvm->slots_lock); @@ -2221,6 +2221,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 entry; + + r = -EFAULT; + if (copy_from_user(&entry, argp, sizeof entry)) + goto out; + r = kvm_iosignalfd(kvm, &entry); + break; + } default: r = kvm_arch_vm_ioctl(filp, ioctl, arg); } ^ permalink raw reply related [flat|nested] 9+ messages in thread
* Re: [KVM PATCH v3 4/4] kvm: add iosignalfd support 2009-05-21 16:51 ` [KVM PATCH v3 4/4] kvm: add iosignalfd support Gregory Haskins @ 2009-05-22 22:05 ` Marcelo Tosatti 2009-05-23 4:57 ` Gregory Haskins 0 siblings, 1 reply; 9+ messages in thread From: Marcelo Tosatti @ 2009-05-22 22:05 UTC (permalink / raw) To: Gregory Haskins; +Cc: kvm, linux-kernel, avi On Thu, May 21, 2009 at 12:51:29PM -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 | 165 ++++++++++++++++++++++++++++++++++++++++++++++ > virt/kvm/kvm_main.c | 11 +++ > 5 files changed, 198 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c > index 98c2434..cee63ff 100644 > --- a/arch/x86/kvm/x86.c > +++ b/arch/x86/kvm/x86.c > @@ -1085,6 +1085,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: > r = 1; > break; > case KVM_CAP_COALESCED_MMIO: > diff --git a/include/linux/kvm.h b/include/linux/kvm.h > index 8f53f24..8162466 100644 > --- a/include/linux/kvm.h > +++ b/include/linux/kvm.h > @@ -292,6 +292,19 @@ struct kvm_guest_debug { > struct kvm_guest_debug_arch arch; > }; > > +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 0) > +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) > +#define KVM_IOSIGNALFD_FLAG_COOKIE (1 << 2) > + > +struct kvm_iosignalfd { > + __u64 cookie; > + __u64 addr; > + __u32 len; > + __u32 fd; > + __u32 flags; > + __u8 pad[12]; > +}; > + > #define KVM_TRC_SHIFT 16 > /* > * kvm trace categories > @@ -419,6 +432,7 @@ struct kvm_trace_rec { > #define KVM_CAP_MCE 31 > #endif > #define KVM_CAP_IRQFD 32 > +#define KVM_CAP_IOSIGNALFD 33 > > #ifdef KVM_CAP_IRQ_ROUTING > > @@ -525,6 +539,7 @@ struct kvm_irqfd { > _IOW(KVMIO, 0x74, struct kvm_assigned_msix_entry) > #define KVM_DEASSIGN_DEV_IRQ _IOW(KVMIO, 0x75, struct kvm_assigned_irq) > #define KVM_IRQFD _IOW(KVMIO, 0x76, struct kvm_irqfd) > +#define KVM_IOSIGNALFD _IOW(KVMIO, 0x77, struct kvm_iosignalfd) > > /* > * ioctls for vcpu fds > diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h > index 7dcae4b..5b2be86 100644 > --- a/include/linux/kvm_host.h > +++ b/include/linux/kvm_host.h > @@ -138,6 +138,7 @@ struct kvm { > struct kvm_io_bus pio_bus; > #ifdef CONFIG_HAVE_KVM_EVENTFD > struct list_head irqfds; > + struct list_head iosignalfds; > #endif > struct kvm_vm_stat stat; > struct kvm_arch arch; > @@ -535,19 +536,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 -EINVAL; > +} > > #endif /* CONFIG_HAVE_KVM_EVENTFD */ > > diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c > index c63ff6a..7700e39 100644 > --- a/virt/kvm/eventfd.c > +++ b/virt/kvm/eventfd.c > @@ -21,12 +21,16 @@ > */ > > #include <linux/kvm_host.h> > +#include <linux/kvm.h> > #include <linux/workqueue.h> > #include <linux/syscalls.h> > #include <linux/wait.h> > #include <linux/poll.h> > #include <linux/file.h> > #include <linux/list.h> > +#include <linux/eventfd.h> > + > +#include "iodev.h" > > /* > * -------------------------------------------------------------------- > @@ -207,9 +211,10 @@ kvm_deassign_irqfd(struct kvm *kvm, int fd, int gsi) > } > > void > -kvm_irqfd_init(struct kvm *kvm) > +kvm_eventfd_init(struct kvm *kvm) > { > INIT_LIST_HEAD(&kvm->irqfds); > + INIT_LIST_HEAD(&kvm->iosignalfds); > } > > int > @@ -232,3 +237,161 @@ kvm_irqfd_release(struct kvm *kvm) > irqfd_release(irqfd); > } > } > + > +/* > + * -------------------------------------------------------------------- > + * 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 { > + u64 cookie; > + u64 addr; > + size_t length; > + struct file *file; > + struct list_head list; > + struct kvm_io_device dev; > +}; > + > +static int > +iosignalfd_in_range(struct kvm_io_device *this, gpa_t addr, int len, > + int is_write) > +{ > + struct _iosignalfd *p = (struct _iosignalfd *)this->private; > + > + return ((addr >= p->addr && (addr < p->addr + p->length))); > +} > + > +/* 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; > + > + eventfd_signal(iosignalfd->file, 1); > +} > + > +/* reads return all zeros */ > +static void > +iosignalfd_read(struct kvm_io_device *this, gpa_t addr, int len, void *val) > +{ > + memset(val, 0, len); > +} Gregory, Can you explain the reasoning behind limiting the interface to write-only ranges, with reads returning zero. Is that because it fits the use cases in mind for iosignalfd? Not that I have a better suggestion at the moment, just trying to understand. Also, the heavy-weight exit avoidance assumes that the action signalled will be serviced by the qemu device model in a separate CPU, otherwise there is no gain, is that correct? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [KVM PATCH v3 4/4] kvm: add iosignalfd support 2009-05-22 22:05 ` Marcelo Tosatti @ 2009-05-23 4:57 ` Gregory Haskins 0 siblings, 0 replies; 9+ messages in thread From: Gregory Haskins @ 2009-05-23 4:57 UTC (permalink / raw) To: Marcelo Tosatti; +Cc: kvm, linux-kernel, avi [-- Attachment #1: Type: text/plain, Size: 12201 bytes --] Hi Marcelo, Marcelo Tosatti wrote: > On Thu, May 21, 2009 at 12:51:29PM -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 | 165 ++++++++++++++++++++++++++++++++++++++++++++++ >> virt/kvm/kvm_main.c | 11 +++ >> 5 files changed, 198 insertions(+), 4 deletions(-) >> >> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c >> index 98c2434..cee63ff 100644 >> --- a/arch/x86/kvm/x86.c >> +++ b/arch/x86/kvm/x86.c >> @@ -1085,6 +1085,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: >> r = 1; >> break; >> case KVM_CAP_COALESCED_MMIO: >> diff --git a/include/linux/kvm.h b/include/linux/kvm.h >> index 8f53f24..8162466 100644 >> --- a/include/linux/kvm.h >> +++ b/include/linux/kvm.h >> @@ -292,6 +292,19 @@ struct kvm_guest_debug { >> struct kvm_guest_debug_arch arch; >> }; >> >> +#define KVM_IOSIGNALFD_FLAG_DEASSIGN (1 << 0) >> +#define KVM_IOSIGNALFD_FLAG_PIO (1 << 1) >> +#define KVM_IOSIGNALFD_FLAG_COOKIE (1 << 2) >> + >> +struct kvm_iosignalfd { >> + __u64 cookie; >> + __u64 addr; >> + __u32 len; >> + __u32 fd; >> + __u32 flags; >> + __u8 pad[12]; >> +}; >> + >> #define KVM_TRC_SHIFT 16 >> /* >> * kvm trace categories >> @@ -419,6 +432,7 @@ struct kvm_trace_rec { >> #define KVM_CAP_MCE 31 >> #endif >> #define KVM_CAP_IRQFD 32 >> +#define KVM_CAP_IOSIGNALFD 33 >> >> #ifdef KVM_CAP_IRQ_ROUTING >> >> @@ -525,6 +539,7 @@ struct kvm_irqfd { >> _IOW(KVMIO, 0x74, struct kvm_assigned_msix_entry) >> #define KVM_DEASSIGN_DEV_IRQ _IOW(KVMIO, 0x75, struct kvm_assigned_irq) >> #define KVM_IRQFD _IOW(KVMIO, 0x76, struct kvm_irqfd) >> +#define KVM_IOSIGNALFD _IOW(KVMIO, 0x77, struct kvm_iosignalfd) >> >> /* >> * ioctls for vcpu fds >> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h >> index 7dcae4b..5b2be86 100644 >> --- a/include/linux/kvm_host.h >> +++ b/include/linux/kvm_host.h >> @@ -138,6 +138,7 @@ struct kvm { >> struct kvm_io_bus pio_bus; >> #ifdef CONFIG_HAVE_KVM_EVENTFD >> struct list_head irqfds; >> + struct list_head iosignalfds; >> #endif >> struct kvm_vm_stat stat; >> struct kvm_arch arch; >> @@ -535,19 +536,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 -EINVAL; >> +} >> >> #endif /* CONFIG_HAVE_KVM_EVENTFD */ >> >> diff --git a/virt/kvm/eventfd.c b/virt/kvm/eventfd.c >> index c63ff6a..7700e39 100644 >> --- a/virt/kvm/eventfd.c >> +++ b/virt/kvm/eventfd.c >> @@ -21,12 +21,16 @@ >> */ >> >> #include <linux/kvm_host.h> >> +#include <linux/kvm.h> >> #include <linux/workqueue.h> >> #include <linux/syscalls.h> >> #include <linux/wait.h> >> #include <linux/poll.h> >> #include <linux/file.h> >> #include <linux/list.h> >> +#include <linux/eventfd.h> >> + >> +#include "iodev.h" >> >> /* >> * -------------------------------------------------------------------- >> @@ -207,9 +211,10 @@ kvm_deassign_irqfd(struct kvm *kvm, int fd, int gsi) >> } >> >> void >> -kvm_irqfd_init(struct kvm *kvm) >> +kvm_eventfd_init(struct kvm *kvm) >> { >> INIT_LIST_HEAD(&kvm->irqfds); >> + INIT_LIST_HEAD(&kvm->iosignalfds); >> } >> >> int >> @@ -232,3 +237,161 @@ kvm_irqfd_release(struct kvm *kvm) >> irqfd_release(irqfd); >> } >> } >> + >> +/* >> + * -------------------------------------------------------------------- >> + * 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 { >> + u64 cookie; >> + u64 addr; >> + size_t length; >> + struct file *file; >> + struct list_head list; >> + struct kvm_io_device dev; >> +}; >> + >> +static int >> +iosignalfd_in_range(struct kvm_io_device *this, gpa_t addr, int len, >> + int is_write) >> +{ >> + struct _iosignalfd *p = (struct _iosignalfd *)this->private; >> + >> + return ((addr >= p->addr && (addr < p->addr + p->length))); >> +} >> + >> +/* 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; >> + >> + eventfd_signal(iosignalfd->file, 1); >> +} >> + >> +/* reads return all zeros */ >> +static void >> +iosignalfd_read(struct kvm_io_device *this, gpa_t addr, int len, void *val) >> +{ >> + memset(val, 0, len); >> +} >> > > Gregory, > > Can you explain the reasoning behind limiting the interface to > write-only ranges, with reads returning zero. > Well, a write seems more closely modeling the action of emitting something out from the guest, as opposed to a read which is technically pulling something in. Many real hardware devices work this way (e.g. writes to a specific register trigger an action (dma, etc), whereas reads return all zeros, all ones, or an undefined pattern, but either way are a no-op) so I was mimicking their design here. I guess one benefit of this approach is that errant reads (which are more probable than errant writes) do not cause unintended side-effects. That said, I do not have a strong opinion regarding this distinction, so if you prefer to see something else (like reads also triggering an event too) I am fine with that. > Is that because it fits the use cases in mind for iosignalfd? > No, not specifically. All I care about is being able to trigger the eventfd, and afaik an ioread() or iowrite() could do that equally well. I suppose the possibility exists that a read vs write may offer different latency characteristics, too. Before I could figure that out I would need to alter some of my test harnesses to quantify differences of that nature. I am guessing they are about equivalent, but that is just a guess. > Not that I have a better suggestion at the moment, just trying > to understand. > > Also, the heavy-weight exit avoidance assumes that the action signalled > will be serviced by the qemu device model in a separate CPU, otherwise > there is no gain, is that correct? > Not necessarily. For one, it doesn't have to be a qemu device model per se (for instance, it could be a vbus device model, or it could be another guests irqfd to an in-kernel LAPIC, etc). Second, there are things we can do right in the same vcpu context that do not involve a context switch (per se) or a return to userspace. For instance, we could potentially directly egress a packet (in a vbus device model), or inject an interrupt to a different guest (via irqfd). None of these things require a qemu device model or a separate CPU, yet they all avoid various overheads such as the heavy-weight exit. That said, one intended use case for this construct *is* to wake up some other thread to do something for us concurrently. In this particular application your observation is absolutely correct. E.g. if the task cannot be woken up to run in parallel to the vcpu thread, we may unavoidably still take a heavy-weight exit anyway when/if the vcpu gets preempted (and thus any gains are diminished). However, it should be noted that even when this is the case, there still may be gains in other places besides any (missed) gains from avoiding the heavy-weight exit. For instance, if the qemu MMIO/PIO handler wakes a thread on a uP box, it may still be faster to wake it from iosignalfd because we still get to the wakeup code via a shorter path, even though both paths ultimately may need a heavy-weight to actually run the thread. HTH, and thank you for the review, -Greg [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 266 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* [KVM PATCH v3 0/4] iosignalfd
@ 2009-05-21 16:49 Gregory Haskins
2009-05-21 16:49 ` [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use Gregory Haskins
0 siblings, 1 reply; 9+ messages in thread
From: Gregory Haskins @ 2009-05-21 16:49 UTC (permalink / raw)
To: kvm; +Cc: linux-kernel, avi, --cc=mtosatti
(Applies to kvm.git/master:7391a6d5)
This is v3 of the series. For more details, please see the header to
patch 4/4.
This series has been tested against the kvm-eventfd unit test, and
appears to be functioning properly. You can download this test here:
ftp://ftp.novell.com/dev/ghaskins/kvm-eventfd.tar.bz2
(Note that the test released with irqfd had a bug in it that prevented
iosignalfd from working properly. The tarball has been updated with the
fix)
This series is ready to be considered for inclusion, pending any further
review comments.
[
Changelog:
v3:
*) fixed patch 2/4 to handle error cases instead of BUG_ON
*) implemented same HAVE_EVENTFD protection mechanism as
irqfd to prevent compilation errors on unsupported arches
*) completed testing
*) rebased to kvm.git/master:7391a6d5
v2:
*) added optional data-matching capability (via cookie field)
*) changed name from iofd to iosignalfd
*) added io_bus unregister function
*) implemented deassign feature
v1:
*) original release (integrated into irqfd v7 series as "iofd")
]
---
Gregory Haskins (4):
kvm: add iosignalfd support
kvm: add io_bus unregister function
kvm: add return value to kvm_io_bus_register_dev
eventfd: export eventfd interfaces for module use
arch/x86/kvm/i8254.c | 27 +++++--
arch/x86/kvm/i8259.c | 9 ++
arch/x86/kvm/x86.c | 1
fs/eventfd.c | 3 +
include/linux/kvm.h | 15 ++++
include/linux/kvm_host.h | 18 ++++-
virt/kvm/coalesced_mmio.c | 8 ++
virt/kvm/eventfd.c | 165 +++++++++++++++++++++++++++++++++++++++++++++
virt/kvm/ioapic.c | 9 ++
virt/kvm/kvm_main.c | 60 ++++++++++++++--
10 files changed, 286 insertions(+), 29 deletions(-)
--
Signature
^ permalink raw reply [flat|nested] 9+ messages in thread* [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use 2009-05-21 16:49 [KVM PATCH v3 0/4] iosignalfd Gregory Haskins @ 2009-05-21 16:49 ` Gregory Haskins 0 siblings, 0 replies; 9+ messages in thread From: Gregory Haskins @ 2009-05-21 16:49 UTC (permalink / raw) To: kvm; +Cc: linux-kernel, avi, --cc=mtosatti We want to use eventfd from KVM which can be compiled as a module, so export the interfaces. Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- fs/eventfd.c | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-) diff --git a/fs/eventfd.c b/fs/eventfd.c index 2a701d5..3f0e197 100644 --- a/fs/eventfd.c +++ b/fs/eventfd.c @@ -16,6 +16,7 @@ #include <linux/anon_inodes.h> #include <linux/eventfd.h> #include <linux/syscalls.h> +#include <linux/module.h> struct eventfd_ctx { wait_queue_head_t wqh; @@ -56,6 +57,7 @@ int eventfd_signal(struct file *file, int n) return n; } +EXPORT_SYMBOL_GPL(eventfd_signal); static int eventfd_release(struct inode *inode, struct file *file) { @@ -197,6 +199,7 @@ struct file *eventfd_fget(int fd) return file; } +EXPORT_SYMBOL_GPL(eventfd_fget); SYSCALL_DEFINE2(eventfd2, unsigned int, count, int, flags) { ^ permalink raw reply related [flat|nested] 9+ messages in thread
end of thread, other threads:[~2009-05-26 15:23 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2009-05-21 16:51 [KVM PATCH v3 0/4] iosignalfd Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 2/4] kvm: add return value to kvm_io_bus_register_dev Gregory Haskins 2009-05-26 15:23 ` Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 3/4] kvm: add io_bus unregister function Gregory Haskins 2009-05-21 16:51 ` [KVM PATCH v3 4/4] kvm: add iosignalfd support Gregory Haskins 2009-05-22 22:05 ` Marcelo Tosatti 2009-05-23 4:57 ` Gregory Haskins -- strict thread matches above, loose matches on Subject: below -- 2009-05-21 16:49 [KVM PATCH v3 0/4] iosignalfd Gregory Haskins 2009-05-21 16:49 ` [KVM PATCH v3 1/4] eventfd: export eventfd interfaces for module use Gregory Haskins
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).