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

[Marcelo Tosatti <mtosatti@redhat.com>]

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..