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
