Re: [kvm-devel] KVM and RT
Gregory Haskins wrote: Hi Team, I don't know if anyone here also subscribes to linux-rt-users, but it seems as though Ingo et. al. rejected my modifications which ran the smp_call() in a thread (VFCIPI). It's not surprising. 650 lines including a custom memory allocator is excessive. So FYI: KVM is still broken on RT and needs to be addressed. In a nutshell, kvm_lock cannot be used as it us today. It either needs to be a raw_spinlock_t, or the locking needs to be done differently. The code currently blows up when you shut down a VM running on top of PREEMPT_RT. Just thought you might want to know. What about hoisting the lock outside the IPI as I suggested earlier? -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - 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
Re: [kvm-devel] KVM and RT
On Wed, 2007-08-01 at 09:56 +0300, Avi Kivity wrote: Gregory Haskins wrote: Hi Team, I don't know if anyone here also subscribes to linux-rt-users, but it seems as though Ingo et. al. rejected my modifications which ran the smp_call() in a thread (VFCIPI). It's not surprising. 650 lines including a custom memory allocator is excessive. Well, as a tactical solution I definitely agree. As you know, I was going for a more broadly applicable feature going way beyond KVM. Of those 650 lines, a good chunk will fall away if I incorporated some of the feedback (plist instead of custom prio_array, convert to workqueue). And the last 150 lines are a custom allocator to work around the regression of GFP_ATOMIC on PREEMPT_RT. But I digress... some of the feedback was that I was wrong and misguided or something like that...ouch. Back to the drawing board. ;) So FYI: KVM is still broken on RT and needs to be addressed. In a nutshell, kvm_lock cannot be used as it us today. It either needs to be a raw_spinlock_t, or the locking needs to be done differently. The code currently blows up when you shut down a VM running on top of PREEMPT_RT. Just thought you might want to know. What about hoisting the lock outside the IPI as I suggested earlier? I think your proposal should work fine as long as you are not atomic when you take the lock wherever it's moved to. -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
[kvm-devel] KVM and RT
Hi Team, I don't know if anyone here also subscribes to linux-rt-users, but it seems as though Ingo et. al. rejected my modifications which ran the smp_call() in a thread (VFCIPI). So FYI: KVM is still broken on RT and needs to be addressed. In a nutshell, kvm_lock cannot be used as it us today. It either needs to be a raw_spinlock_t, or the locking needs to be done differently. The code currently blows up when you shut down a VM running on top of PREEMPT_RT. Just thought you might want to know. 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
