From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: [patch] x86: kvm: Convert i8254/i8259 locks to raw_spinlocks Date: Thu, 18 Feb 2010 10:40:11 +0100 Message-ID: <4B7D0AFB.4040709@siemens.com> References: <20100217135901.331576359@linutronix.de> <4B7D0466.2030700@siemens.com> <4B7D0663.70807@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Thomas Gleixner , KVM To: Avi Kivity Return-path: Received: from goliath.siemens.de ([192.35.17.28]:24034 "EHLO goliath.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753656Ab0BRJkd (ORCPT ); Thu, 18 Feb 2010 04:40:33 -0500 In-Reply-To: <4B7D0663.70807@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 02/18/2010 11:12 AM, Jan Kiszka wrote: >> Thomas Gleixner wrote: >> >>> The i8254/i8259 locks need to be real spinlocks on preempt-rt. Convert >>> them to raw_spinlock. No change for !RT kernels. >>> >> Last time I ran KVM over RT, I also had to convert requests_lock (struct >> kvm): make_all_cpus_request assumes that this lock prevents migration. >> >> > > True. Will commit something to that effect. > > Meanwhile, if anyone has any idea how to kill this lock, I'd love to see it. > What concurrency does it resolve in the end? On first glance, it only synchronize the fiddling with pre-VCPU request bits, right? What forces us to do this? Wouldn't it suffice to disable preemption (thus migration) and the let concurrent requests race for setting the bits? I mean if some request bit was already set on entry, we don't include the related VCPU in smp_call_function_many anyway. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux