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.
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
