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:50:53 +0200 Message-ID: <4B7D0D7D.7040004@redhat.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; format=flowed Content-Transfer-Encoding: 7bit Cc: Thomas Gleixner , KVM To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:41431 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754921Ab0BRJvA (ORCPT ); Thu, 18 Feb 2010 04:51:00 -0500 In-Reply-To: <4B7D0C34.1060004@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/18/2010 11:45 AM, 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. One way out would be to have a KVM_REQ_IN_PROGRESS, set it in make_request, clear it in the IPI function. If a second make_request sees it already set, it can simply busy wait until it is cleared, without sending the IPI. Of course the busy wait means we can't enable preemption (or we may busy wait on an unscheduled task), but at least the requests can proceed in parallel instead of serializing. -- error compiling committee.c: too many arguments to function