On 04/17/2012 12:31 PM, Gleb Natapov wrote: > On Mon, Apr 16, 2012 at 06:33:26PM +0200, Jan Kiszka wrote: > > On 2010-06-16 23:11, Chris Lalancette wrote: > > > We really want to "kvm_set_irq" during the hrtimer callback, > > > but that is risky because that is during interrupt context. > > > Instead, offload the work to a workqueue, which is a bit safer > > > and should provide most of the same functionality. > > > > Unfortunately, workqueues do not have fixed kthread associations (and > > "kvm-pit-wq" would be too unspecific when running multiple VMs). So I > > just realized that this subtly breaks the ability to run KVM guests with > > RT priority (boot managers with timeouts hang as the workqueue starves). > > > > Before throwing some kthread_worker at this, could someone help me > > recalling what was "risky" here? That the PIT IRQ may have to be > > broadcast to a large number of VCPUs? I would offer to include this > > information in my changelog. ;) > > > ioapic and pic irq_set functions uses spinlocks, but not irqsave > variants. Also I am always forget whether is is safe to kick vcpu from > irq context. It isn't, since you need to send an IPI. -- error compiling committee.c: too many arguments to function -- 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
