From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: avi@redhat.com, gleb@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, jan.kiszka@siemens.com
Subject: Re: [PATCH v4 2/3] kvm: KVM_EOIFD, an eventfd for EOIs
Date: Sun, 15 Jul 2012 19:32:39 +0300 [thread overview]
Message-ID: <20120715163238.GB17995@redhat.com> (raw)
In-Reply-To: <20120713194103.5474.54352.stgit@bling.home>
On Fri, Jul 13, 2012 at 01:41:05PM -0600, Alex Williamson wrote:
> +static int kvm_assign_eoifd(struct kvm *kvm, struct kvm_eoifd *args)
> +{
> + struct eventfd_ctx *level_irqfd = NULL, *eventfd = NULL;
> + struct _eoifd *eoifd = NULL;
> + struct _irq_source *source = NULL;
> + unsigned gsi;
> + int ret;
> +
> + eventfd = eventfd_ctx_fdget(args->fd);
> + if (IS_ERR(eventfd)) {
> + ret = PTR_ERR(eventfd);
> + goto fail;
> + }
> +
> + eoifd = kzalloc(sizeof(*eoifd), GFP_KERNEL);
> + if (!eoifd) {
> + ret = -ENOMEM;
> + goto fail;
> + }
> +
> + if (args->flags & KVM_EOIFD_FLAG_LEVEL_IRQFD) {
> + struct _irqfd *irqfd = _irqfd_fdget_lock(kvm, args->irqfd);
> + if (IS_ERR(irqfd)) {
> + ret = PTR_ERR(irqfd);
> + goto fail;
> + }
> +
> + gsi = irqfd->gsi;
> + level_irqfd = eventfd_ctx_get(irqfd->eventfd);
> + source = _irq_source_get(irqfd->source);
> + _irqfd_put_unlock(irqfd);
> + if (!source) {
> + ret = -EINVAL;
> + goto fail;
> + }
> + } else {
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> + INIT_LIST_HEAD(&eoifd->list);
> + eoifd->kvm = kvm;
> + eoifd->eventfd = eventfd;
> + eoifd->source = source;
> + eoifd->level_irqfd = level_irqfd;
> + eoifd->notifier.gsi = gsi;
> + eoifd->notifier.irq_acked = eoifd_event;
> +
> + mutex_lock(&kvm->eoifds.lock);
> +
> + list_add_tail(&eoifd->list, &kvm->eoifds.items);
Do we want to disallow multiple eventfds mapping the same irqfd?
No strong opinions but preventing this might make it possible to cache
the callback in the irqfd in the future.
This will also help limit the number of eoifd-s to 1024 GSIs * 32 source ids.
As it is userspace can apparently consume unlimited kernel memory.
next prev parent reply other threads:[~2012-07-15 16:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-07-13 19:40 [PATCH v4 0/3] kvm: level irqfd and new eoifd Alex Williamson
2012-07-13 19:40 ` [PATCH v4 1/3] kvm: Extend irqfd to support level interrupts Alex Williamson
2012-07-13 19:41 ` [PATCH v4 2/3] kvm: KVM_EOIFD, an eventfd for EOIs Alex Williamson
2012-07-15 16:23 ` Michael S. Tsirkin
2012-07-15 16:32 ` Michael S. Tsirkin [this message]
2012-07-16 15:01 ` Alex Williamson
2012-07-13 19:41 ` [PATCH v4 3/3] kvm: Add a GSI specification for KVM_EOIFD Alex Williamson
2012-07-15 16:45 ` [PATCH v4 0/3] kvm: level irqfd and new eoifd Michael S. Tsirkin
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=20120715163238.GB17995@redhat.com \
--to=mst@redhat.com \
--cc=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 \
/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