From: "Michael S. Tsirkin" <mst@redhat.com>
To: Gregory Haskins <ghaskins@novell.com>
Cc: kvm@vger.kernel.org, alacrityvm-devel@lists.sourceforge.net,
linux-kernel@vger.kernel.org
Subject: Re: [KVM PATCH v3 2/3] KVM: export lockless GSI attribute
Date: Wed, 28 Oct 2009 09:46:23 +0200 [thread overview]
Message-ID: <20091028074623.GB22784@redhat.com> (raw)
In-Reply-To: <20091026162202.23704.8727.stgit@dev.haskins.net>
On Mon, Oct 26, 2009 at 12:22:03PM -0400, Gregory Haskins wrote:
> Certain GSI's support lockless injecton, but we have no way to detect
> which ones at the GSI level. Knowledge of this attribute will be
> useful later in the series so that we can optimize irqfd injection
> paths for cases where we know the code will not sleep. Therefore,
> we provide an API to query a specific GSI.
>
> Signed-off-by: Gregory Haskins <ghaskins@novell.com>
> ---
>
> include/linux/kvm_host.h | 2 ++
> virt/kvm/irq_comm.c | 35 ++++++++++++++++++++++++++++++++++-
> 2 files changed, 36 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/kvm_host.h b/include/linux/kvm_host.h
> index 1fe135d..01151a6 100644
> --- a/include/linux/kvm_host.h
> +++ b/include/linux/kvm_host.h
> @@ -119,6 +119,7 @@ struct kvm_memory_slot {
> struct kvm_kernel_irq_routing_entry {
> u32 gsi;
> u32 type;
> + bool lockless;
So lockless is the same as type == MSI from below?
If the idea is to make it extensible for the future,
let's just add an inline function, we don't need a field for this.
> int (*set)(struct kvm_kernel_irq_routing_entry *e,
> struct kvm *kvm, int irq_source_id, int level);
> union {
> @@ -420,6 +421,7 @@ void kvm_get_intr_delivery_bitmask(struct kvm_ioapic *ioapic,
> unsigned long *deliver_bitmask);
> #endif
> int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 irq, int level);
> +int kvm_irq_check_lockless(struct kvm *kvm, u32 irq);
> void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin);
> void kvm_register_irq_ack_notifier(struct kvm *kvm,
> struct kvm_irq_ack_notifier *kian);
> diff --git a/virt/kvm/irq_comm.c b/virt/kvm/irq_comm.c
> index db2553f..a7fd487 100644
> --- a/virt/kvm/irq_comm.c
> +++ b/virt/kvm/irq_comm.c
> @@ -173,6 +173,35 @@ int kvm_set_irq(struct kvm *kvm, int irq_source_id, u32 irq, int level)
> return ret;
> }
>
> +int kvm_irq_check_lockless(struct kvm *kvm, u32 irq)
> +{
> + struct kvm_kernel_irq_routing_entry *e;
> + struct kvm_irq_routing_table *irq_rt;
> + struct hlist_node *n;
> + int ret = -ENOENT;
> + int idx;
> +
> + idx = srcu_read_lock(&kvm->irq_routing.srcu);
> + irq_rt = rcu_dereference(kvm->irq_routing.table);
> + if (irq < irq_rt->nr_rt_entries)
> + hlist_for_each_entry(e, n, &irq_rt->map[irq], link) {
> + if (!e->lockless) {
> + /*
> + * all destinations need to be lockless to
> + * declare that the GSI as a whole is also
> + * lockless
> + */
> + ret = 0;
> + break;
> + }
> +
> + ret = 1;
> + }
> + srcu_read_unlock(&kvm->irq_routing.srcu, idx);
> +
> + return ret;
> +}
> +
> void kvm_notify_acked_irq(struct kvm *kvm, unsigned irqchip, unsigned pin)
> {
> struct kvm_irq_ack_notifier *kian;
> @@ -310,18 +339,22 @@ static int setup_routing_entry(struct kvm_irq_routing_table *rt,
> int delta;
> struct kvm_kernel_irq_routing_entry *ei;
> struct hlist_node *n;
> + bool lockless = ue->type == KVM_IRQ_ROUTING_MSI;
>
> /*
> * Do not allow GSI to be mapped to the same irqchip more than once.
> * Allow only one to one mapping between GSI and MSI.
> + * Do not allow mixed lockless vs locked variants to coexist.
Userspace has no idea which entries are lockless and which are not:
this is an implementation detail - so it might not be able to avoid
illegal combinations.
Since this is called on an ioctl, can the rule be formulated in a way
that makes sense for userspace?
> */
> hlist_for_each_entry(ei, n, &rt->map[ue->gsi], link)
> if (ei->type == KVM_IRQ_ROUTING_MSI ||
> - ue->u.irqchip.irqchip == ei->irqchip.irqchip)
> + ue->u.irqchip.irqchip == ei->irqchip.irqchip ||
> + ei->lockless != lockless)
So this check seems like it does nothing, because lockless is same as
MSI, and MSI is always 1:1? Intentional?
> return r;
>
> e->gsi = ue->gsi;
> e->type = ue->type;
> + e->lockless = lockless;
> switch (ue->type) {
> case KVM_IRQ_ROUTING_IRQCHIP:
> delta = 0;
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2009-10-28 7:49 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-26 16:21 [KVM PATCH v3 0/3] irqfd enhancements, and irq_routing fixes Gregory Haskins
2009-10-26 16:21 ` [KVM PATCH v3 1/3] KVM: fix race in irq_routing logic Gregory Haskins
2009-10-27 3:36 ` Paul E. McKenney
2009-10-27 13:34 ` Gregory Haskins
2009-10-27 17:01 ` Paul E. McKenney
2009-10-27 6:45 ` Gleb Natapov
2009-10-27 13:39 ` Gregory Haskins
2009-10-27 14:00 ` Gregory Haskins
2009-10-27 14:05 ` Gleb Natapov
2009-10-27 14:50 ` Gregory Haskins
2009-10-27 15:04 ` Gleb Natapov
2009-10-27 15:42 ` Gregory Haskins
2009-10-27 14:02 ` Gleb Natapov
2009-10-27 14:47 ` Gregory Haskins
2009-10-27 15:30 ` Gleb Natapov
2009-10-27 16:53 ` Gregory Haskins
2009-10-27 14:49 ` Paul E. McKenney
2009-10-27 15:02 ` Gregory Haskins
2009-10-27 16:14 ` Paul E. McKenney
2009-10-26 16:22 ` [KVM PATCH v3 2/3] KVM: export lockless GSI attribute Gregory Haskins
2009-10-28 7:46 ` Michael S. Tsirkin [this message]
2009-10-28 13:24 ` Gregory Haskins
2009-10-26 16:22 ` [KVM PATCH v3 3/3] KVM: Directly inject interrupts if they support lockless operation Gregory Haskins
2009-10-27 17:45 ` Michael S. Tsirkin
2009-10-27 18:54 ` Gregory Haskins
2009-10-28 7:35 ` Michael S. Tsirkin
2009-10-28 13:20 ` Gregory Haskins
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=20091028074623.GB22784@redhat.com \
--to=mst@redhat.com \
--cc=alacrityvm-devel@lists.sourceforge.net \
--cc=ghaskins@novell.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.