Re: [UNTESTED] KVM: do not call kvm_set_irq from irq disabled section

[Avi Kivity <avi@redhat.com>]

On 04/22/2010 10:55 PM, Gleb Natapov wrote:
>
>
>>> What about converting PIC/IOAPIC mutexes into spinlocks?
>>>        
>> Works for me, but on large guests the spinning will be noticeable.
>> I believe.
>>      
> For interrupts going through IOPIC, but we know this is not scalable
> anyway.
>    

Yes.  We also wanted to convert the ioapic/pic to spinlocks so we could 
queue the interrupt from the PIT directly instead of using 
KVM_REQ_PENDING_TIMER which keeps confusing me.  Chris Lalancette posted 
a patchset for this a while back but it was never completed.

I'm not really happy with adding lots of spin_lock_irqsave()s though, 
especially on the ioapic which may iterate over all vcpus (not worried 
about scaling, but about a malicious guest hurting host latency).

An alternative is make kvm_set_irq() irq safe: if msi, do things 
immediately, otherwise post a work item.  So we can call kvm_set_irq() 
directly from the interrupt.

Alternative alternative (perhaps better for short term): switch 
assigned_dev_lock to a mutex (we're already in a work handler, no need 
for spinlock).  The race between the irq and removal of an assigned 
device is closed by free_irq():


  lock
  mark assigned device as going away
  unlock
  free_irq()
  actually kill it

like invalid mmu pages.

-- 

Do not meddle in the internals of kernels, for they are subtle and quick to panic.