Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1293214 > unrolled thread

Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device Paolo Bonzini <pbonzini@redhat.com> - 2015-12-16 19:00 +0100
    Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device Alex Williamson <alex.williamson@redhat.com> - 2015-12-16 20:20 +0100
      Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device Paolo Bonzini <pbonzini@redhat.com> - 2015-12-16 23:00 +0100

#1293214 — Re: [PATCH 0/5] Threaded MSI interrupt for VFIO PCI device

Alex,

can you take a look at the extension to the irq bypass interface in
patch 2?  I'm not sure I understand what is the case where you have
multiple consumers for the same token.

Paolo

On 03/12/2015 19:22, Yunhong Jiang wrote:
> When assigning a VFIO device to a KVM guest with low latency requirement, it  
> is better to handle the interrupt in the hard interrupt context, to reduce 
> the context switch to/from the IRQ thread.
> 
> Based on discussion on https://lkml.org/lkml/2015/10/26/764, the VFIO msi 
> interrupt is changed to use request_threaded_irq(). The primary interrupt 
> handler tries to set the guest interrupt atomically. If it fails to achieve 
> it, a threaded interrupt handler will be invoked.
> 
> The irq_bypass manager is extended for this purpose. The KVM eventfd will 
> provide a irqbypass consumer to handle the interrupt at hard interrupt 
> context. The producer will invoke the consumer's handler then.
> 
> Yunhong Jiang (5):
>   Extract the irqfd_wakeup_pollin/irqfd_wakeup_pollup
>   Support runtime irq_bypass consumer
>   Support threaded interrupt handling on VFIO
>   Add the irq handling consumer
>   Expose x86 kvm_arch_set_irq_inatomic()
> 
>  arch/x86/kvm/Kconfig              |   1 +
>  drivers/vfio/pci/vfio_pci_intrs.c |  39 ++++++++++--
>  include/linux/irqbypass.h         |   8 +++
>  include/linux/kvm_host.h          |  19 +++++-
>  include/linux/kvm_irqfd.h         |   1 +
>  virt/kvm/Kconfig                  |   3 +
>  virt/kvm/eventfd.c                | 131 ++++++++++++++++++++++++++------------
>  virt/lib/irqbypass.c              |  82 ++++++++++++++++++------
>  8 files changed, 214 insertions(+), 70 deletions(-)
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1293318

On Wed, 2015-12-16 at 18:56 +0100, Paolo Bonzini wrote:
> Alex,
> 
> can you take a look at the extension to the irq bypass interface in
> patch 2?  I'm not sure I understand what is the case where you have
> multiple consumers for the same token.

The consumers would be, for instance, Intel PI + the threaded handler
added in this series.  These run independently, the PI bypass simply
makes the interrupt disappear from the host when it catches it, but if
the vCPU isn't running in the right place at the time of the interrupt,
it gets delivered to the host, in which case the secondary consumer
implementing handle_irq() provides a lower latency injection than the
eventfd path.  If PI isn't supported, only this latter consumer is
registered.

On the surface it seems like a reasonable solution, though having
multiple consumers implementing handle_irq() seems problematic.  Do we
get multiple injections if we call them all?  Should we have some way
to prioritize one handler versus another?  Perhaps KVM should have a
single unified consumer that can provide that sort of logic, though we
still need the srcu code added here to protect against registration and
irq_handler() races.  Thanks,

Alex

> On 03/12/2015 19:22, Yunhong Jiang wrote:
> > When assigning a VFIO device to a KVM guest with low latency
> > requirement, it  
> > is better to handle the interrupt in the hard interrupt context, to
> > reduce 
> > the context switch to/from the IRQ thread.
> > 
> > Based on discussion on https://lkml.org/lkml/2015/10/26/764, the
> > VFIO msi 
> > interrupt is changed to use request_threaded_irq(). The primary
> > interrupt 
> > handler tries to set the guest interrupt atomically. If it fails to
> > achieve 
> > it, a threaded interrupt handler will be invoked.
> > 
> > The irq_bypass manager is extended for this purpose. The KVM
> > eventfd will 
> > provide a irqbypass consumer to handle the interrupt at hard
> > interrupt 
> > context. The producer will invoke the consumer's handler then.
> > 
> > Yunhong Jiang (5):
> >   Extract the irqfd_wakeup_pollin/irqfd_wakeup_pollup
> >   Support runtime irq_bypass consumer
> >   Support threaded interrupt handling on VFIO
> >   Add the irq handling consumer
> >   Expose x86 kvm_arch_set_irq_inatomic()
> > 
> >  arch/x86/kvm/Kconfig              |   1 +
> >  drivers/vfio/pci/vfio_pci_intrs.c |  39 ++++++++++--
> >  include/linux/irqbypass.h         |   8 +++
> >  include/linux/kvm_host.h          |  19 +++++-
> >  include/linux/kvm_irqfd.h         |   1 +
> >  virt/kvm/Kconfig                  |   3 +
> >  virt/kvm/eventfd.c                | 131
> > ++++++++++++++++++++++++++------------
> >  virt/lib/irqbypass.c              |  82 ++++++++++++++++++------
> >  8 files changed, 214 insertions(+), 70 deletions(-)
> > 

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

[toc] | [prev] | [next] | [standalone]

#1293358

On 16/12/2015 20:15, Alex Williamson wrote:
> The consumers would be, for instance, Intel PI + the threaded handler
> added in this series.  These run independently, the PI bypass simply
> makes the interrupt disappear from the host when it catches it, but if
> the vCPU isn't running in the right place at the time of the interrupt,
> it gets delivered to the host, in which case the secondary consumer
> implementing handle_irq() provides a lower latency injection than the
> eventfd path.  If PI isn't supported, only this latter consumer is
> registered.

I would implement the two in a single consumer, knowing that only one of
the two parts would effectively run.  But because of the possibility of
multiple consumers implementing handle_irq(), I am not sure if this is
feasible.

> On the surface it seems like a reasonable solution, though having
> multiple consumers implementing handle_irq() seems problematic.  Do we
> get multiple injections if we call them all?

Indeed.

> Should we have some way
> to prioritize one handler versus another?  Perhaps KVM should have a
> single unified consumer that can provide that sort of logic, though we
> still need the srcu code added here to protect against registration and
> irq_handler() races.  Thanks,

I'm happy to see that we have the same doubts. :)

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web