From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH 4/6] kvm tools: Add rwlock wrapper Date: Sun, 29 May 2011 09:47:33 +0300 Message-ID: <4DE1EC05.3040001@redhat.com> References: <20110526180518.GA3572@elte.hu> <4DDE97CE.4000302@redhat.com> <1306436223.3065.36.camel@lappy> <20110526230923.GB15983@Krystal> <1306491547.3217.9.camel@lappy> <20110527103657.GA25748@elte.hu> <1306511560.3217.23.camel@lappy> <20110527171040.GC4356@elte.hu> <1306527578.3217.26.camel@lappy> <20110528152408.GA27104@elte.hu> <1306611908.3282.7.camel@lappy> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Ingo Molnar , Mathieu Desnoyers , Pekka Enberg , john@jfloren.net, kvm@vger.kernel.org, asias.hejun@gmail.com, gorcunov@gmail.com, prasadjoshi124@gmail.com, "Paul E. McKenney" To: Sasha Levin Return-path: Received: from mx1.redhat.com ([209.132.183.28]:60886 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751241Ab1E2GsB (ORCPT ); Sun, 29 May 2011 02:48:01 -0400 In-Reply-To: <1306611908.3282.7.camel@lappy> Sender: kvm-owner@vger.kernel.org List-ID: On 05/28/2011 10:45 PM, Sasha Levin wrote: > On Sat, 2011-05-28 at 17:24 +0200, Ingo Molnar wrote: > > * Sasha Levin wrote: > > > > > So the basic plan here is to allocate a futex(?) for each VCPU > > > thread, and have the writer thread lock all futexes when it needs > > > to write? > > > > > > If we assume we only have one writer thread, it can stay pretty > > > simple. > > > > We can use an even simpler and more scalable method: > > > > - writers can 'stop' all other threads, by sending them a > > threadpool signal and waiting for each thread to have completed > > processing their current work and notifying the writer back that > > they have stopped running. > > > > This means that the read-side lock is _zero instructions_, basically > > just a barrier() to make sure the compiler does not move instructions > > across threadpool functions (it wont). > > > > This method requires that we know about every worker thread - i.e. > > no-one does a stray pthread_create() and uses data structures from > > there. It also requires that each worker thread can 'stop' within a > > reasonable amount of time. > > In this case, maybe instead of implementing it as a 'lock', we can > implement it as a way to stop all vcpu threads from reentering the > kernel (KVM_RUN): > > 1. Set a 'vcpu-stop' flag. > 2. Signal all VCPUs to exit KVM_RUN. > 3. VCPU threads now wait on our lock before reentering into KVM_RUN - > the writer thread waits until waiting threads = VCPU count. > 4. Writer thread writes, releases lock. > > So instead of it being a lock in MMIO, IO-ports, etc - it's a method to > stop the entire guest which could be used during configuration updates > (and anything else we might think of). It could also be used as a method > for users to 'pause' the guest. Yes, this is equivalent to the kernel's stop_machine_run(). It's a heavyweight method but it should work just fine. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.