Gregory Haskins wrote:
KVM provides a complete virtual system environment for guests, including
support for injecting interrupts modeled after the real exception/interrupt
facilities present on the native platform (such as the IDT on x86).
Virtual interrupts can come from a variety of sources (emulated devices,
pass-through devices, etc) but all must be injected to the guest via
the KVM infrastructure. This patch adds a new mechanism to inject a specific
interrupt to a guest using a decoupled eventfd mechnanism: Any legal signal
on the irqfd (using eventfd semantics from either userspace or kernel) will
translate into an injected interrupt in the guest at the next available
interrupt window.
r = 1;
break;
case KVM_CAP_COALESCED_MMIO:
diff --git a/include/linux/kvm.h b/include/linux/kvm.h
index 3db5d8d..dfc4bcc 100644
--- a/include/linux/kvm.h
+++ b/include/linux/kvm.h
@@ -415,6 +415,7 @@ struct kvm_trace_rec {
#define KVM_CAP_ASSIGN_DEV_IRQ 29
/* Another bug in KVM_SET_USER_MEMORY_REGION fixed: */
#define KVM_CAP_JOIN_MEMORY_REGIONS_WORKS 30
+#define KVM_CAP_EVENTFD 31
Let's keep a fine granularity and call it IRQFD.
+
+int
+kvm_deassign_irqfd(struct kvm *kvm, int fd)
+{
+ struct _irqfd *irqfd, *tmp;
+
+ mutex_lock(&kvm->lock);
+
+ /*
+ * linear search isn't brilliant, but this should be a infrequent
+ * operation and the list should not grow very large
+ */
+ list_for_each_entry_safe(irqfd, tmp, &kvm->irqfds, list) {
+ if (irqfd->fd != fd)
+ continue;
Please fget() the new fd and compare the filps; fds aren't meaningful in
the kernel. You can also drop _irqfd::fd.
It may also be useful to compare the gsi, this allows a
"make-before-break" switchover:
- guest reroutes irq to a different gsi
- associate irqfd with new gsi
- disassociate irqfd from old gsi
+
+ irqfd_release(irqfd);
+ mutex_unlock(&kvm->lock);
+ return 0;
Don't return, userspace may have multiple associations?
--
error compiling committee.c: too many arguments to function
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
