From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: KVM and RT Date: Wed, 01 Aug 2007 09:56:32 +0300 Message-ID: <46B02EA0.7080100@qumranet.com> References: <1185910192.9513.57.camel@ghaskins-t60p.haskins.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Cc: kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org To: Gregory Haskins Return-path: In-Reply-To: <1185910192.9513.57.camel-5CR4LY5GPkvLDviKLk5550HKjMygAv58XqFh9Ls21Oc@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org Errors-To: kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org List-Id: kvm.vger.kernel.org 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/