On Wed, 2007-07-25 at 06:20 +0300, Avi Kivity wrote: > > I'd rather wait for the real fix, especially as this is an experimental > branch. Can you provide details of the issue? >
Sure. Keep in mind I am working with the RT kernel, so things might be tighter and/or different than the vanilla kernel w.r.t. what I am about to say: But in a nutshell, the current code calls vcpu_clear() during a sched-in operation. If the vcpu is simply uninitialized, no problem. We clear it inline in the handler. However, if the vcpu is migrating we have an issue. A synchronous smp_call_function_single() is invoked to vcpu_clear the remote pCPU, but you must have interrupts enabled to call this function to avoid a deadlock in the IPI handshake. sched-in() handlers are (and should be) called with interrupts and preemption disabled. One solution is the one in which I provided already: Hobble migration while the vcpu is locked. Not very elegant, but it works. Another solution (of which I am very close to getting working now) still allows for a high degree of preemption _and_ migration. It accomplishes this by essentially deferring the migration to a workqueue and taking itself off the run-queue all from inside the sched-in handler. This is all very tricky since the sched-X handlers are more or less like IRQ context, but I think I have a suitable solution. Stay tuned. Regards, -Greg ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
