All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: "Michael S. Tsirkin" <mst@redhat.com>
Cc: avi@redhat.com, mtosatti@redhat.com, kvm@vger.kernel.org
Subject: Re: [PATCHv0 RFC] kvm: irqfd support for level interrupts
Date: Mon, 27 Jul 2009 11:30:59 +0300	[thread overview]
Message-ID: <20090727083059.GC23816@redhat.com> (raw)
In-Reply-To: <20090727082139.GB26271@redhat.com>

On Mon, Jul 27, 2009 at 11:21:39AM +0300, Michael S. Tsirkin wrote:
> On Mon, Jul 27, 2009 at 11:13:50AM +0300, Gleb Natapov wrote:
> > On Mon, Jul 27, 2009 at 11:02:06AM +0300, Michael S. Tsirkin wrote:
> > > On Mon, Jul 27, 2009 at 10:31:38AM +0300, Gleb Natapov wrote:
> > > > On Mon, Jul 27, 2009 at 09:28:34AM +0300, Michael S. Tsirkin wrote:
> > > > > On Mon, Jul 27, 2009 at 08:33:12AM +0300, Gleb Natapov wrote:
> > > > > > On Sun, Jul 26, 2009 at 07:22:25PM +0300, Michael S. Tsirkin wrote:
> > > > > > > Here's an untested patch with partial support for level triggered
> > > > > > > interrupts in irqfd. What this patch has: support for clearing interrupt
> > > > > > > on ack. What this patch does not have: support signalling eventfd on ack
> > > > > > > so that userspace can take action and e.g. reenable interrupt.
> > > > > > > 
> > > > > > Do we want level triggered irqfd to be used only for device assignment?
> > > > > 
> > > > > generally level triggered-not only.
> > > > > But irqfd is promarily for device assignment and emulated devices.
> > > > > 
> > > > If it is for emulated device zeroing irq level on ack is not acceptable.
> > > 
> > > OK, forget about emulated devices for now. Let's focus on assigned
> > > devices.
> > > 
> > Can't. We should design interface that works for everything.
> 
> We can always add the KVM_MAKE_COFFEE ioctl later.
> 
Assigned devices are non interesting case, so we can hack something
afterwards to make it work. Emulated devices is a normal case that
should work when interface is introduced. Why assigning devices through
the kernel is not good enough? What is the reason to push it to
userspace?

> > > > > > Because if not it is not appropriate to zero irq level on ack.
> > > > > 
> > > > > The bit that is missing in this patch, is that we'll signal eventfd
> > > > > after we zero irq. Userspace polls that and re-asserts irq.
> > > > That is not needed for device emulation. Emulated device should lower
> > > > irq line by itself. It know exactly when to do it. Please don't push
> > > > broken device assignment model to emulated devices.
> > > > 
> > > > > 
> > > > > > And you
> > > > > > have no other way to zero irq level?!
> > > > > 
> > > > > The reason is interrupt sharing: device can assert interrupt
> > > > > but can not clear it by itself.
> > > > For interrupt sharing to work you need to allocate source id for each
> > > > irqfd.
> > > 
> > > BTW, current SET_IRQ_LINE interface uses a common source id for all
> > > irqs. Does this mean that interrupt sharing in guest is broken now?
> > No. It means that sharing in handled in userspace by chipset emulation.
> 
> Aha. Where's that code in qemu-kvm? I only see it forwarding to the
AFAIR in hw/pci.c and/or hw/piix_pci.c.

> ioctl call directly. And what about assigned devices? These bypass qemu.
> 
Each assigned device allocates its own source id. This is the reason
source id exists at all.

--
			Gleb.

  reply	other threads:[~2009-07-27  8:31 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-26 16:22 [PATCHv0 RFC] kvm: irqfd support for level interrupts Michael S. Tsirkin
2009-07-27  5:33 ` Gleb Natapov
2009-07-27  6:28   ` Michael S. Tsirkin
2009-07-27  7:31     ` Gleb Natapov
2009-07-27  8:02       ` Michael S. Tsirkin
2009-07-27  8:13         ` Gleb Natapov
2009-07-27  8:21           ` Michael S. Tsirkin
2009-07-27  8:30             ` Gleb Natapov [this message]
2009-08-19 12:17   ` Avi Kivity
2009-07-29 16:01 ` Gregory Haskins
2009-07-29 16:03   ` Gregory Haskins
2009-08-19 12:20 ` Avi Kivity
2009-08-19 13:09   ` Michael S. Tsirkin

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=20090727083059.GC23816@redhat.com \
    --to=gleb@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.