[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120713192625.5474.60777.stgit@bling.home>
Date: Fri, 13 Jul 2012 13:40:48 -0600
From: Alex Williamson <alex.williamson@...hat.com>
To: avi@...hat.com, mst@...hat.com
Cc: gleb@...hat.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
jan.kiszka@...mens.com
Subject: [PATCH v4 0/3] kvm: level irqfd and new eoifd
v4:
- KVM_IRQFD_FLAG_LEVEL flag now documented and coded to only be
necessary on assign.
- Lock added to struct _irq_source to maintain the source ID assertion
state to avoid repeat assertions or spurious EOIs. I couldn't figure
out a way to make this work w/o races using atomics and don't see any
way to make use of kvm_irq_line_state.
- GSI support in KVM_EOIFD is dropped since it's not immediately used
and I don't seem to be able to explain why it's useful. It makes it
optional though, which may be a good thing if other archs try to use
this interface.
- eoifd switch to mutex from spinlock (all tested as lockdep safe)
- _irqfd_fdget_lock/_irqfd_put_unlock replaces _irqfd_fdget/_irqfd_put
so we hold the lock for the irqfds ensuring the one we're binding to
doesn't go away while we get a reference to the _irq_source.
- We also pull the GSI off the irqfd rather than specifying it for eoifd.
- eoifd_deactivate renamed to eoifd_destroy to make it blindingly
obvious what it does.
Patch 3/3 is not for commit and not meant to be ready for commit, it's
just an FYI on what adding back support for a GSI based, non-de-asserting
eoifd will look like. Thanks,
Alex
---
Alex Williamson (3):
kvm: Add a GSI specification for KVM_EOIFD
kvm: KVM_EOIFD, an eventfd for EOIs
kvm: Extend irqfd to support level interrupts
Documentation/virtual/kvm/api.txt | 27 +++
arch/x86/kvm/x86.c | 3
include/linux/kvm.h | 24 +++
include/linux/kvm_host.h | 13 +
virt/kvm/eventfd.c | 349 +++++++++++++++++++++++++++++++++++++
virt/kvm/kvm_main.c | 11 +
6 files changed, 423 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists