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 12:18:25 +0200 Message-ID: <4B7D13F1.3030702@redhat.com> References: <20100217135901.331576359@linutronix.de> <4B7D0466.2030700@siemens.com> <4B7D0663.70807@redhat.com> <4B7D0AFB.4040709@siemens.com> <4B7D0C34.1060004@redhat.com> <4B7D0D7D.7040004@redhat.com> <4B7D10D2.20105@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]:25578 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751157Ab0BRKSj (ORCPT ); Thu, 18 Feb 2010 05:18:39 -0500 In-Reply-To: <4B7D10D2.20105@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/18/2010 12:05 PM, Jan Kiszka wrote: > Avi Kivity wrote: > >> 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. >> > ...or include VCPUs with KVM_REQ_IN_PROGRESS set into the IPI set even > if they already have the desired request bit set. But then we're making them take the IPI, which is pointless and expensive. My approach piggy backs multiple requesters on one IPI. > Then we should > serialize in smp_call_function_many. > Do you mean rely on s_c_f_m's internal synchronization? -- error compiling committee.c: too many arguments to function