[PATCH v6 0/2] kvm: level irqfd and new eoifd

From: Alex Williamson
Date: Fri Jul 20 2012 - 12:34:22 EST


v6:

So we're back to just the first two patches, unfortunately the
diffstat got bigger though. The reason for that is that I discovered
we don't do anything on release of an eoifd. We cleanup if the kvm
vm is released, but we're dealing with a constrained resource of irq
source IDs, so I think it's best that we cleanup to make sure those
are returned. To do that we need nearly the same infrastructure as
irqfd, we just only watch for POLLHUP. So while there's more code
here, the structure and function names line up identically to irqfd.

The other big change here is that KVM_IRQFD returns a token when
setting up a level irqfd. We use this token to associate the eoifd
with the right source. This means we have to put the struct
_source_ids on a list so we can find them. This removes the weird
interaction we were headed to where the eoifd is associated with
the eventfd of the irqfd. There's potentially more flexibility for
the future here too as we might come up with other interfaces that
can return a source ID "key". Perhaps some future KVM_IRQFD will
allow specifying a key for re-attaching. Anyway, the sequence
Michael pointed out where an irqfd is de-assigned then re-assigned
now results in a new key instead of leaving the user wondering if
it re-associates back to the eoifd.

Also added workqueue flushes on assign since releasing either
object now results in a lazy release via workqueue. This ensures
we re-claim any source IDs we can. Thanks,

Alex
---

Alex Williamson (2):
kvm: KVM_EOIFD, an eventfd for EOIs
kvm: Extend irqfd to support level interrupts


Documentation/virtual/kvm/api.txt | 32 ++-
arch/x86/kvm/x86.c | 3
include/linux/kvm.h | 18 +
include/linux/kvm_host.h | 17 +
virt/kvm/eventfd.c | 463 ++++++++++++++++++++++++++++++++++++-
virt/kvm/kvm_main.c | 11 +
6 files changed, 536 insertions(+), 8 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/