From: "Michael S. Tsirkin" <mst@redhat.com>
To: Alex Williamson <alex.williamson@redhat.com>
Cc: avi@redhat.com, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, jan.kiszka@siemens.com
Subject: Re: [PATCH v2 4/6] kvm: Extend irqfd to support level interrupts
Date: Thu, 28 Jun 2012 11:29:23 +0300 [thread overview]
Message-ID: <20120628082923.GA12447@redhat.com> (raw)
In-Reply-To: <1340855572.1207.300.camel@bling.home>
On Wed, Jun 27, 2012 at 09:52:52PM -0600, Alex Williamson wrote:
> On Thu, 2012-06-28 at 01:28 +0300, Michael S. Tsirkin wrote:
> > On Wed, Jun 27, 2012 at 03:28:19PM -0600, Alex Williamson wrote:
> > > On Thu, 2012-06-28 at 00:14 +0300, Michael S. Tsirkin wrote:
> > > > On Wed, Jun 27, 2012 at 02:59:09PM -0600, Alex Williamson wrote:
> > > > > On Wed, 2012-06-27 at 12:51 +0300, Michael S. Tsirkin wrote:
> > > > > > On Tue, Jun 26, 2012 at 11:09:46PM -0600, Alex Williamson wrote:
> > > > > > > In order to inject an interrupt from an external source using an
> > > > > > > irqfd, we need to allocate a new irq_source_id. This allows us to
> > > > > > > assert and (later) de-assert an interrupt line independently from
> > > > > > > users of KVM_IRQ_LINE and avoid lost interrupts.
> > > > > > >
> > > > > > > We also add what may appear like a bit of excessive infrastructure
> > > > > > > around an object for storing this irq_source_id. However, notice
> > > > > > > that we only provide a way to assert the interrupt here. A follow-on
> > > > > > > interface will make use of the same irq_source_id to allow de-assert.
> > > > > > >
> > > > > > > Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
> > > > > > > ---
> > > > > > >
> > > > > > > Documentation/virtual/kvm/api.txt | 5 ++
> > > > > > > arch/x86/kvm/x86.c | 1
> > > > > > > include/linux/kvm.h | 3 +
> > > > > > > virt/kvm/eventfd.c | 95 +++++++++++++++++++++++++++++++++++--
> > > > > > > 4 files changed, 99 insertions(+), 5 deletions(-)
> > > > > > >
> > > > > > > diff --git a/Documentation/virtual/kvm/api.txt b/Documentation/virtual/kvm/api.txt
> > > > > > > index ea9edce..b216709 100644
> > > > > > > --- a/Documentation/virtual/kvm/api.txt
> > > > > > > +++ b/Documentation/virtual/kvm/api.txt
> > > > > > > @@ -1981,6 +1981,11 @@ the guest using the specified gsi pin. The irqfd is removed using
> > > > > > > the KVM_IRQFD_FLAG_DEASSIGN flag, specifying both kvm_irqfd.fd
> > > > > > > and kvm_irqfd.gsi.
> > > > > > >
> > > > > > > +With KVM_IRQFD_FLAG_LEVEL KVM_IRQFD allocates a new IRQ source ID for
> > > > > > > +the requested irqfd. This is necessary to share level triggered
> > > > > > > +interrupts with those injected through KVM_IRQ_LINE. IRQFDs created
> > > > > > > +with KVM_IRQFD_FLAG_LEVEL must also set this flag when de-assiging.
> > > > > > > +KVM_IRQFD_FLAG_LEVEL support is indicated by KVM_CAP_IRQFD_LEVEL.
> > > > > >
> > > > > > Note that if my patch removing auto-deassert gets accepted,
> > > > > > this is not needed at all: we can just look at the GSI
> > > > > > to see if it's level or edge.
> > > > >
> > > > > I'm not sure this is a good idea. I know from vfio that I'm injecting a
> > > > > level interrupt regardless of how the guest has the pic/ioapic
> > > > > programmed at the time I'm calling this ioctl. Peeking across address
> > > > > spaces to get to the right pin on the right pic/ioapic and see how it's
> > > > > currently programmed seems fragile. Thanks,
> > > > >
> > > > > Alex
> > > >
> > > > Fragile? If you set eventfd as LEVEL but GSI is really edge then
> > > > it all explodes, right? So why give users the option to shoot
> > > > themselves in the foot?
> > >
> > > If the guest has the ioapic rte set to edge at the time I call KVM_IRQFD
> > > to register my level interrupt then it all explodes, right? I'd rather
> > > let the user shoot themselves than play Russian roulette with the guest.
> > > Am I misunderstanding what you mean by looking that the GSI to see if
> > > it's level or edge?
> >
> > Not sure.
> > I simply mean this: if eventfd is bound to irqfd, set level from irqfd
> > and clear from eventfd ack notifier.
>
> Are you simply saying assert (kvm_set_irq(,,,1)) from irqfd trigger and
> de-assert (kvm_set_irq(,,,0)) from eventfd ack notifier (aka KVM_EOIFD)?
Yes.
> > There's no need for a special IRQ_LEVEL for this.
>
> That ignores the whole problem of when do we need to allocate a new
> irq_source_id and when do we inject using KVM_USERSPACE_IRQ_SOURCE_ID.
> We've already discussed that a level triggered, externally fired
> interrupt must use a separate source ID from Qemu userspace. Therefore
> when you say "look at the GSI to see if it's level or edge", I assume
> you mean trace the gsi back to the pic/ioapic pin and look at the
> trigger mode. That trigger mode is configured by the guest, so that
> means that at the point in time when we call KVM_IRQFD we make a
> determination based on how the _guest_ has programmed the ioapic. That
> may not match the interrupt we expect to inject. On the other hand, the
> user calling KVM_IRQFD absolutely knows the type of interrupt provided
> by their device. I think we need a flag regardless of whether your
> patch is accepted. We may be able to share the inject handler if it is
> accepted, but it doesn't change the user API. Thanks,
>
> Alex
This has merit, I am just looking for a way out
without adding LEVEL flag which seems to duplicate
what guest does, especially now it turns out
we can't add new flags to IRQFD.
How about this: allocate source id when eventfd is mapped?
--
MST
next prev parent reply other threads:[~2012-06-28 8:29 UTC|newest]
Thread overview: 64+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-27 5:08 [PATCH v2 0/6] kvm: level triggered irqfd support Alex Williamson
2012-06-27 5:09 ` [PATCH v2 1/6] kvm: Pass kvm_irqfd to functions Alex Williamson
2012-06-27 9:35 ` Michael S. Tsirkin
2012-06-27 14:30 ` Alex Williamson
2012-06-27 14:24 ` Cornelia Huck
2012-06-28 8:38 ` Michael S. Tsirkin
2012-06-28 9:03 ` Cornelia Huck
2012-06-28 9:34 ` Michael S. Tsirkin
2012-06-28 12:00 ` Cornelia Huck
2012-06-28 12:09 ` Michael S. Tsirkin
2012-06-28 16:51 ` Cornelia Huck
2012-06-28 16:56 ` Michael S. Tsirkin
2012-06-29 15:14 ` Alex Williamson
2012-06-27 5:09 ` [PATCH v2 2/6] kvm: Add missing KVM_IRQFD API documentation Alex Williamson
2012-06-27 9:53 ` Michael S. Tsirkin
2012-06-27 5:09 ` [PATCH v2 3/6] kvm: Sanitize KVM_IRQFD flags Alex Williamson
2012-06-27 9:21 ` Michael S. Tsirkin
2012-06-27 20:12 ` Alex Williamson
2012-06-27 20:22 ` Michael S. Tsirkin
2012-06-28 12:35 ` Avi Kivity
2012-06-27 5:09 ` [PATCH v2 4/6] kvm: Extend irqfd to support level interrupts Alex Williamson
2012-06-27 9:34 ` Michael S. Tsirkin
2012-06-27 21:19 ` Alex Williamson
2012-06-28 12:41 ` Avi Kivity
2012-06-27 9:51 ` Michael S. Tsirkin
2012-06-27 20:59 ` Alex Williamson
2012-06-27 21:14 ` Michael S. Tsirkin
2012-06-27 21:28 ` Alex Williamson
2012-06-27 22:28 ` Michael S. Tsirkin
2012-06-28 3:52 ` Alex Williamson
2012-06-28 8:29 ` Michael S. Tsirkin [this message]
2012-06-29 15:13 ` Alex Williamson
2012-06-27 15:26 ` Michael S. Tsirkin
2012-06-27 22:04 ` Alex Williamson
2012-06-27 22:31 ` Michael S. Tsirkin
2012-06-28 6:34 ` Gleb Natapov
2012-06-28 8:34 ` Michael S. Tsirkin
2012-06-28 8:35 ` Gleb Natapov
2012-06-28 8:41 ` Michael S. Tsirkin
2012-06-28 8:46 ` Gleb Natapov
2012-06-28 8:48 ` Michael S. Tsirkin
2012-06-28 8:53 ` Gleb Natapov
2012-06-29 22:27 ` Alex Williamson
2012-07-01 7:34 ` Gleb Natapov
2012-06-27 5:10 ` [PATCH v2 5/6] kvm: KVM_EOIFD, an eventfd for EOIs Alex Williamson
2012-06-27 9:49 ` Michael S. Tsirkin
2012-06-27 13:58 ` Gleb Natapov
2012-06-27 14:29 ` Alex Williamson
2012-06-27 14:51 ` Gleb Natapov
2012-06-28 3:55 ` Alex Williamson
2012-06-28 13:11 ` Michael S. Tsirkin
2012-06-28 14:08 ` Gleb Natapov
2012-06-28 16:55 ` Michael S. Tsirkin
2012-06-27 15:20 ` Michael S. Tsirkin
2012-06-28 19:29 ` Michael S. Tsirkin
2012-06-29 15:09 ` Alex Williamson
2012-06-29 15:12 ` Alex Williamson
2012-06-27 5:10 ` [PATCH v2 6/6] kvm: Level IRQ de-assert for KVM_IRQFD Alex Williamson
2012-06-28 12:59 ` Avi Kivity
2012-06-29 15:39 ` Alex Williamson
2012-06-27 9:15 ` [PATCH v2 0/6] kvm: level triggered irqfd support Michael S. Tsirkin
2012-06-27 9:58 ` Michael S. Tsirkin
2012-06-27 14:33 ` Alex Williamson
2012-06-28 8:42 ` 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=20120628082923.GA12447@redhat.com \
--to=mst@redhat.com \
--cc=alex.williamson@redhat.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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.