From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [patch] x86: kvm: Convert i8254/i8259 locks to raw_spinlocks Date: Thu, 18 Feb 2010 11:45:24 +0200 Message-ID: <4B7D0C34.1060004@redhat.com> References: <20100217135901.331576359@linutronix.de> <4B7D0466.2030700@siemens.com> <4B7D0663.70807@redhat.com> <4B7D0AFB.4040709@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Gleixner , KVM To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:1026 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753709Ab0BRJpe (ORCPT ); Thu, 18 Feb 2010 04:45:34 -0500 In-Reply-To: <4B7D0AFB.4040709@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: 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. -- error compiling committee.c: too many arguments to function