kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Avi Kivity <avi@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: mtosatti@redhat.com, kvm@vger.kernel.org, mst@redhat.com,
	jan.kiszka@siemens.com
Subject: Re: [RFC PATCH] kvm: Extend irqfd to support level interrupts
Date: Mon, 18 Jun 2012 11:02:43 +0300	[thread overview]
Message-ID: <4FDEE0A3.80900@redhat.com> (raw)
In-Reply-To: <20120616163230.15204.61075.stgit@bling.home>

On 06/16/2012 07:34 PM, Alex Williamson wrote:
> I'm looking for opinions on this approach.  For vfio device assignment
> we minimally need a way to get EOIs from the in-kernel irqchip out to
> userspace.  Getting that out via an eventfd would allow us to bounce
> all level interrupts out to userspace, where we would de-assert the
> device interrupt in qemu and unmask the physical device.  Ideally we
> could deassert the interrupt in KVM, which allows us to send the EOI
> directly to vfio.  To do that, we need to use a new IRQ source ID so
> the guest sees the logical OR of qemu requested state and external
> device state.  This allows external devices to share interrupts with
> emulated devices, just like KVM assignment.  That means the means we
> also need to use a new source ID when injecting the interrupt via
> irqfd.
> 
> Rather than creating a source ID allocation interface, extending irqfd
> to support a user supplied source ID, and creating another new
> interface to get the EOI out, I think it works out better to bundle
> these all together as just a level irqfd interface.  This way we don't
> allow users to create unbalanced states where a level interrupt is
> asserted, but has no way of being deasserted.  I believe the below
> does this, but needs testing and validation with an implementation in
> qemu.
> 

Missing documentation, which helps at least one reviewer review.  It's
not just for a commit.

>  
> +static void
> +irqfd_inject_level(struct work_struct *work)
> +{
> +	struct _irqfd *irqfd = container_of(work, struct _irqfd, inject);
> +
> +	kvm_set_irq(irqfd->kvm, irqfd->irq_source_id, irqfd->gsi, 1);
> +}
> +
> +static void
> +irqfd_ack_level(struct kvm_irq_ack_notifier *notifier)
> +{
> +	struct _irqfd *irqfd  = container_of(notifier, struct _irqfd, notifier);
> +
> +	kvm_set_irq(irqfd->kvm, irqfd->irq_source_id, irqfd->gsi, 0);
> +	eventfd_signal(irqfd->eoi_eventfd, 1);
> +}
> +

I don't understand how this works.  A level IRQ isn't de-asserted by the
EOI, it's de-asserted by its source.

Consider the following sequence:

device        guest

  event
   assert
              interrupt
               interrupt handler
                handle event
                clear ISR bit
   deassert
  event
    assert
               EOI

What should happen is that the interrupt will be redelivered
immmediately after the EOI, but that won't happen with your API since
the EOI ack notifier will deassert the interrupt and nothing will
re-assert it.


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



  parent reply	other threads:[~2012-06-18  8:02 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-16 16:34 [RFC PATCH] kvm: Extend irqfd to support level interrupts Alex Williamson
2012-06-17 11:17 ` Jan Kiszka
2012-06-17 18:44 ` Michael S. Tsirkin
2012-06-17 21:38   ` Alex Williamson
2012-06-17 22:15     ` Alex Williamson
2012-06-18  6:00       ` Michael S. Tsirkin
2012-06-18 14:00         ` Alex Williamson
2012-06-18  5:51     ` Michael S. Tsirkin
2012-06-18 14:06       ` Alex Williamson
2012-06-18  8:02 ` Avi Kivity [this message]
2012-06-18  8:52   ` Jan Kiszka
2012-06-18  9:33     ` Avi Kivity
2012-06-18 10:11       ` Michael S. Tsirkin
2012-06-18 10:14         ` Avi Kivity
2012-06-18 10:55           ` Michael S. Tsirkin
2012-06-18 11:03             ` Avi Kivity
2012-06-18 11:17               ` Michael S. Tsirkin
2012-06-18 14:32                 ` Alex Williamson
2012-06-18 14:27           ` Alex Williamson
2012-06-18 14:33             ` Avi Kivity
2012-06-18 16:47               ` Alex Williamson
2012-06-18 14:23         ` Alex Williamson
2012-06-18 14:18   ` Alex Williamson
2012-06-18 14:35     ` Avi Kivity

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=4FDEE0A3.80900@redhat.com \
    --to=avi@redhat.com \
    --cc=alex.williamson@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=mst@redhat.com \
    --cc=mtosatti@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;
as well as URLs for NNTP newsgroup(s).