KVM and RT

KVM and RT

[Gregory Haskins]

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/

Re: KVM and RT

[Avi Kivity]

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/

Re: KVM and RT

[Gregory Haskins]

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/