From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: [PATCH] KVM: Start lock documentation Date: Wed, 16 Feb 2011 11:03:59 +0200 Message-ID: <4D5B92FF.1050208@redhat.com> References: <4D52A090.5010308@siemens.com> <20110215164414.GA12410@amt.cnet> <4D5AB2FA.5060408@siemens.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Marcelo Tosatti , kvm To: Jan Kiszka Return-path: Received: from mx1.redhat.com ([209.132.183.28]:17425 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752579Ab1BPJEE (ORCPT ); Wed, 16 Feb 2011 04:04:04 -0500 In-Reply-To: <4D5AB2FA.5060408@siemens.com> Sender: kvm-owner@vger.kernel.org List-ID: On 02/15/2011 07:08 PM, Jan Kiszka wrote: > On 2011-02-15 17:44, Marcelo Tosatti wrote: > > On Wed, Feb 09, 2011 at 03:11:28PM +0100, Jan Kiszka wrote: > >> The goal of this document shall be > >> - overview of all locks used in KVM core > >> - provide details on the scope of each lock > >> - explain the lock type, specifically of a raw spin locks > >> - provide a lock ordering guide > >> > >> Start with one dependency chain and two locks. > >> > >> Signed-off-by: Jan Kiszka > >> --- > >> Documentation/kvm/locking.txt | 30 ++++++++++++++++++++++++++++++ > >> 1 files changed, 30 insertions(+), 0 deletions(-) > >> create mode 100644 Documentation/kvm/locking.txt > >> > >> diff --git a/Documentation/kvm/locking.txt b/Documentation/kvm/locking.txt > >> new file mode 100644 > >> index 0000000..23f9092 > >> --- /dev/null > >> +++ b/Documentation/kvm/locking.txt > >> @@ -0,0 +1,30 @@ > >> +KVM Lock Overview > >> +================= > >> + > >> +1. Acquisition Orders > >> +--------------------- > >> + > >> +kvm_lock > >> ++-> kvm::srcu / kvm::lock > >> + +-> kvm::slots_lock > >> + +-> kvm::mmu_lock > >> +... > > > > Its not easy to understand what you mean here. What kvm_lock has to do > > with the ordering described below it? > > kvm_lock is the head of this chain, i.e. there are code paths where it > is taken first, then kvm::lock, etc. > Right, but it is not mandatory for most fields protected by the lock. So we have - which locks _may_ nest, and how - which locks _must_ nest, and how, to access a particular field (may depend on type of access for rcu) -- error compiling committee.c: too many arguments to function