All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kiszka <jan.kiszka@siemens.com>
To: Avi Kivity <avi@redhat.com>
Cc: Alex Williamson <alex.williamson@redhat.com>,
	"mtosatti@redhat.com" <mtosatti@redhat.com>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"mst@redhat.com" <mst@redhat.com>
Subject: Re: [RFC PATCH] kvm: Extend irqfd to support level interrupts
Date: Mon, 18 Jun 2012 10:52:34 +0200	[thread overview]
Message-ID: <4FDEEC52.8080806@siemens.com> (raw)
In-Reply-To: <4FDEE0A3.80900@redhat.com>

On 2012-06-18 10:02, Avi Kivity wrote:
> 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.

As it's level triggered and we unmask the physical source, another
host-side interrupt will be triggered and then reported to the guest.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux

  reply	other threads:[~2012-06-18  8:52 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
2012-06-18  8:52   ` Jan Kiszka [this message]
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=4FDEEC52.8080806@siemens.com \
    --to=jan.kiszka@siemens.com \
    --cc=alex.williamson@redhat.com \
    --cc=avi@redhat.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 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.