All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: kvm@vger.kernel.org
Subject: Re: [PATCHv2 RFC] kvm: deliver msix interrupts from irq handler
Date: Mon, 11 Jun 2012 14:53:23 +0300	[thread overview]
Message-ID: <4FD5DC33.3060709@redhat.com> (raw)
In-Reply-To: <20120608160120.GA2959@redhat.com>

On 06/08/2012 07:01 PM, Michael S. Tsirkin wrote:
> We can deliver certain interrupts, notably MSIX,
> from atomic context.  Add a new API kvm_set_irq_inatomic,
> that does exactly that, and use it to implement
> an irq handler for msi.
> 
> This reduces the pressure on scheduler in case
> where host and guest irq share a host cpu.
> 

Looks nice.

>  
> +/*
> + * Deliver an IRQ in an atomic context if we can, or return a failure,
> + * user can retry in a process context.
> + * Return value:
> + *  -EWOULDBLOCK - Can't deliver in atomic context: retry in a process context.
> + *  Other values - No need to retry.
> + */
> +int kvm_set_irq_inatomic(struct kvm *kvm, int irq_source_id, u32 irq, int level)
> +{
> +	struct kvm_kernel_irq_routing_entry *e;
> +	int ret = -EINVAL;
> +	struct kvm_irq_routing_table *irq_rt;
> +	struct hlist_node *n;
> +
> +	trace_kvm_set_irq(irq, level, irq_source_id);
> +
> +	/*
> +	 * We know MSI are safe in interrupt context. They are also
> +	 * easy as there's a single routing entry for these GSIs.
> +	 * So only handle MSI in an atomic context, for now.
> +	 *
> +	 * This shares some code with kvm_set_irq: this
> +	 * version is optimized for a single entry MSI only case.
> +	 */
> +	rcu_read_lock();
> +	irq_rt = rcu_dereference(kvm->irq_routing);
> +	if (irq < irq_rt->nr_rt_entries)
> +		hlist_for_each_entry(e, n, &irq_rt->map[irq], link) {
> +			if (likely(e->type == KVM_IRQ_ROUTING_MSI))
> +				ret = kvm_set_msi(e, kvm, irq_source_id, level);
> +			else
> +				ret = -EWOULDBLOCK;
> +			break;
> +		}
> +	rcu_read_unlock();
> +	return ret;
> +}
> +

kvm_set_msi() contains a loop over all vcpus to match the APIC ID (or to
broadcast).  I'd rather see a cache that contains the vcpu pointer and
vector number (assumes delivery mode of fixed and not the other junk),
if the cache is filled fire away, otherwise slow path to a thread and
fill the cache if possible.

-- 
error compiling committee.c: too many arguments to function

      reply	other threads:[~2012-06-11 11:53 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-08 16:01 [PATCHv2 RFC] kvm: deliver msix interrupts from irq handler Michael S. Tsirkin
2012-06-11 11:53 ` Avi Kivity [this message]

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=4FD5DC33.3060709@redhat.com \
    --to=avi@redhat.com \
    --cc=kvm@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 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.