kvm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: Avi Kivity <avi@redhat.com>,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	jan.kiszka@siemens.com
Subject: Re: [PATCH 3/4] kvm: Extend irqfd to support level interrupts
Date: Sun, 24 Jun 2012 15:59:27 -0600	[thread overview]
Message-ID: <1340575167.5076.165.camel@bling.home> (raw)
In-Reply-To: <20120624154938.GE2851@redhat.com>

On Sun, 2012-06-24 at 18:49 +0300, Michael S. Tsirkin wrote:
> On Sun, Jun 24, 2012 at 09:18:38AM -0600, Alex Williamson wrote:
> > > > @@ -242,7 +299,8 @@ kvm_irqfd_assign(struct kvm *kvm, struct kvm_irqfd *args)
> > > >  
> > > >  	ret = 0;
> > > >  	list_for_each_entry(tmp, &kvm->irqfds.items, list) {
> > > > -		if (irqfd->eventfd != tmp->eventfd)
> > > > +		if (irqfd->eventfd != tmp->eventfd &&
> > > > +		    irqfd->eventfd != tmp->eoi_eventfd)
> > > >  			continue;
> > > 
> > > So we allow duplicate irqfd with differing eoifd (or edge-triggered and
> > > level-triggered irqfd on the same context).
> > > 
> > > (why the check in the first place? just so we can have a reliable
> > > deassign or is it avoiding a deeper problem?)
> > 
> > I really wasn't sure to what extent we wanted to prevent duplicates.  My
> > guess was that we don't want to have an irqfd trigger more than one
> > thing.  That seems to be what the current code does.  I don't see any
> > problems with multiple irqfds triggering the same eventfd though.  I
> > only added a test that a new irqfd can't be triggered by an existing
> > eoi_eventfd as that could make a nasty loop.
> 
> How would that make a loop? You can have the same thing
> with e.g. ioeventfd - why isn't it a problem there?

eoi_eventfd1 -> irqfd2 [eoi] eoi_eventfd2 -> irqfd1 [eoi] eoi_eventfd1 ->...

Yes, in reality we'd need to search fds from all the interfaces and come
up with some grossly complicated truth table of what's allowed and
what's not.  The original code didn't go to that kind of extreme, so I
just added something that seemed like a reasonable case
we'd want to prevent.  Thanks,

Alex

  reply	other threads:[~2012-06-24 21:59 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-22 22:15 [PATCH 0/4] kvm: level triggered irqfd support Alex Williamson
2012-06-22 22:15 ` [PATCH 1/4] kvm: Pass kvm_irqfd to functions Alex Williamson
2012-06-22 22:15 ` [PATCH 2/4] kvm: Add missing KVM_IRQFD API documentation Alex Williamson
2012-06-24  8:34   ` Michael S. Tsirkin
2012-06-24 14:56     ` Alex Williamson
2012-06-24 15:46       ` Michael S. Tsirkin
2012-06-22 22:16 ` [PATCH 3/4] kvm: Extend irqfd to support level interrupts Alex Williamson
2012-06-24  8:28   ` Michael S. Tsirkin
2012-06-24 14:50     ` Alex Williamson
2012-06-24 15:45       ` Michael S. Tsirkin
2012-06-24 21:52         ` Alex Williamson
2012-06-24 10:29   ` Avi Kivity
2012-06-24 15:18     ` Alex Williamson
2012-06-24 15:49       ` Michael S. Tsirkin
2012-06-24 21:59         ` Alex Williamson [this message]
2012-06-24 23:02           ` Michael S. Tsirkin
2012-06-25 16:17             ` Alex Williamson
2012-06-25 20:13               ` Michael S. Tsirkin
2012-06-25 19:29       ` Alex Williamson
2012-06-22 22:16 ` [PATCH 4/4][RFC] kvm: eoi_eventfd Alex Williamson
2012-06-24  8:24   ` Michael S. Tsirkin
2012-06-24 14:47     ` Alex Williamson
2012-06-24 15:40       ` Michael S. Tsirkin
2012-06-24 21:50         ` Alex Williamson
2012-06-24 22:35           ` Michael S. Tsirkin
2012-06-25 16:09             ` Alex Williamson
2012-06-25 20:12               ` Michael S. Tsirkin
2012-06-24 12:56   ` Avi Kivity
2012-06-24 15:02     ` Alex Williamson
2012-06-28 16:27       ` Avi Kivity
2012-06-28 17:21         ` Alex Williamson

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=1340575167.5076.165.camel@bling.home \
    --to=alex.williamson@redhat.com \
    --cc=avi@redhat.com \
    --cc=jan.kiszka@siemens.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@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 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).