From: Alex Williamson <alex.williamson@redhat.com>
To: avi@redhat.com, mst@redhat.com
Cc: gleb@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, jan.kiszka@siemens.com
Subject: [PATCH v6 0/2] kvm: level irqfd and new eoifd
Date: Fri, 20 Jul 2012 10:33:34 -0600 [thread overview]
Message-ID: <20120720161841.15119.29653.stgit@bling.home> (raw)
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(-)
next reply other threads:[~2012-07-20 16:33 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-20 16:33 Alex Williamson [this message]
2012-07-20 16:33 ` [PATCH v6 1/2] kvm: Extend irqfd to support level interrupts Alex Williamson
2012-07-20 16:33 ` [PATCH v6 2/2] kvm: KVM_EOIFD, an eventfd for EOIs Alex Williamson
2012-07-23 22:50 ` [PATCH v6 0/2] kvm: level irqfd and new eoifd Alex Williamson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120720161841.15119.29653.stgit@bling.home \
--to=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=gleb@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mst@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox