Re: [patch 4/4] KVM: switch irq injection/acking to irq_lock

Marcelo Tosatti
2009-05-20T14:19:20Z

On Wed, May 20, 2009 at 08:15:55AM -0400, Gregory Haskins wrote:
> Marcelo Tosatti wrote:
> > Switch irq injection/acking to irq_lock, and change PIO/MMIO paths
> > so that the device search is protected by kvm->lock, but not the
> > read/write callbacks (which is responsability of the device).
> >
> > Fix for http://article.gmane.org/gmane.comp.emulators.kvm.devel/32286.
> >
> > Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
> >
> > Index: kvm/arch/x86/kvm/i8254.c
> > ===================================================================
> > --- kvm.orig/arch/x86/kvm/i8254.c
> > +++ kvm/arch/x86/kvm/i8254.c
> > @@ -634,10 +634,10 @@ static void __inject_pit_timer_intr(stru
> > struct kvm_vcpu *vcpu;
> > int i;
> >
> > - mutex_lock(&kvm->lock);
> > + mutex_lock(&kvm->irq_lock);
> >
>
> There would be advantages to having irq_lock be
> interrupt/nonpreempt-friendly design, such as s/mutex/spinlock. For
> instance, irqfd could inject the interrupt directly without deferring to
> a workqueue. I'm not sure if this is possible/easy, but its something
> to consider.

It is possible to convert to a spinlock (and required to switch
bus->devs[] to be protected by RCU as discussed).

Now if its worth to make it interrupt safe depends on how bad disabling
interrupts on the non-interrupt-disabled paths is. I've seen kvm_set_irq
relatively high in profiling yesterday, BTW, but this is just
hand-waving..