Re: [PATCH v8 0/6] kvm: level irqfd support

[Alex Williamson]

On Wed, 2012-08-15 at 17:28 +0300, Michael S. Tsirkin wrote:
> On Fri, Aug 10, 2012 at 04:37:08PM -0600, Alex Williamson wrote:
> > v8:
> > 
> > Trying a new approach.  Nobody seems to like the internal IRQ
> > source ID object and the interactions it implies between irqfd
> > and eoifd, so let's get rid of it.  Instead, simply expose
> > IRQ source IDs to userspace.  This lets the user be in charge
> > of freeing them or hanging onto a source ID for later use.
> 
> In the end it turns out source ID is an optimization for shared
> interrupts, isn't it?  Can't we apply the optimization transparently to
> the user?  E.g. if we have some spare source IDs, allocate them, if we
> run out, use a shared source ID?

Let's think about shared source IDs a bit more.  I think it's wrong that
irqfd uses KVM_USERSPACE_IRQ_SOURCE_ID, but I'm questioning whether all
irqfd users can share a source ID.  We do not get the logical OR of all
users by putting them on the same source ID, we get "last set wins".
KVM_USERSPACE_IRQ_SOURCE_ID is used for multiple inputs because the
logical OR happens in userspace.  How would we not starve a user if we
define KVM_IRQFD_SOURCE_ID?  What am I missing?

So I'm inclined to say source IDs are a requirement for shared
interrupts.  That means the re-use scheme becomes complicated (ex. we
run out of IRQ source IDs, so we start looking for sharing by re-using a
source ID used by a different GSI).  Do we want to do that in kernel or
userspace?  This series allows userspace to deal with that complexity.
Please let me know if I'm thinking incorrectly about source ID re-use.
Thanks,

Alex


> > They
> > can also detach and re-attach components at will.  It also opens
> > up the possibility that userspace might want to use each IRQ
> > source ID for more than one GSI (and avoids the kernel needing
> > to manage that).  Per suggestions, EOIFD is now IRQ_ACKFD.
> > 
> > I really wanted to add a de-assert-only option to irqfd so the
> > irq_ackfd could be fed directly into an irqfd, but I'm dependent
> > on the ordering of de-assert _then_ signal an eventfd.  Keeping
> > that ordering doesn't seem to be possible, especially since irqfd
> > uses a workqueue, if I attempt to make that connection.  Thanks,
> > 
> > Alex
> > ---
> > 
> > Alex Williamson (6):
> >       kvm: Add de-assert option to KVM_IRQ_ACKFD
> >       kvm: KVM_IRQ_ACKFD
> >       kvm: Add assert-only option to KVM_IRQFD
> >       kvm: Add IRQ source ID option to KVM_IRQFD
> >       kvm: Expose IRQ source IDs to userspace
> >       kvm: Allow filtering of acked irqs
> > 
> > 
> >  Documentation/virtual/kvm/api.txt |   53 ++++++
> >  arch/x86/kvm/Kconfig              |    1 
> >  arch/x86/kvm/i8254.c              |    1 
> >  arch/x86/kvm/i8259.c              |    8 +
> >  arch/x86/kvm/x86.c                |    8 +
> >  include/linux/kvm.h               |   39 ++++-
> >  include/linux/kvm_host.h          |   18 ++
> >  virt/kvm/Kconfig                  |    3 
> >  virt/kvm/assigned-dev.c           |    1 
> >  virt/kvm/eventfd.c                |  315 +++++++++++++++++++++++++++++++++++++
> >  virt/kvm/ioapic.c                 |    5 -
> >  virt/kvm/irq_comm.c               |   28 +++
> >  virt/kvm/kvm_main.c               |   26 +++
> >  13 files changed, 496 insertions(+), 10 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/