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:49:56 +0100 Message-ID: <4B7D0D44.6080107@siemens.com> References: <20100217135901.331576359@linutronix.de> <4B7D0466.2030700@siemens.com> <4B7D0663.70807@redhat.com> <4B7D0AFB.4040709@siemens.com> <4B7D0C34.1060004@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 david.siemens.de ([192.35.17.14]:18669 "EHLO david.siemens.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754392Ab0BRJuT (ORCPT ); Thu, 18 Feb 2010 04:50:19 -0500 In-Reply-To: <4B7D0C34.1060004@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Avi Kivity wrote: > On 02/18/2010 11:40 AM, Jan Kiszka wrote: >>> 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. >> > > It's more difficult. > > vcpu 0: sets request bit on vcpu 2 > vcpu 1: test_and_set request bit on vcpu 2, returns already set > vcpu 1: returns > vcpu 0: sends IPI > vcpu 0: returns > > so vcpu 1 returns before the IPI was performed. If the request was a > tlb flush, for example, vcpu 1 may free a page that is still in vcpu 2's > tlb. So the requests bits we are interested in are exclusively set in this function under requests_lock? Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux