Re: [PATCH] KVM: Start lock documentation

[Avi Kivity <avi@redhat.com>]

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<jan.kiszka@siemens.com>
> >>  ---
> >>   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