[Xen-devel] [PATCH 0 of 9] [RFC] p2m fine-grained concurrency control

[Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>]

This patch series is an RFC on p2m fine-grained locking.

The p2m (in x86) is accessed today in an unsafe manner. Lookups
do not hold any locks or refs, and things like paging or sharing
can change their entries under their feet. Even the pages that 
may have been mapped as a result of a lookup may disappear.

This is an attempt at a solution. The gist is to lock 2MB aligned
ranges, exclusively, both for lookups and modifications. Callers
external to the p2m also get a ref on the underlying mfn. This 
prevents modifications to the p2m from happening while the caller
is relying on the translation, and ensures liveness of the 
underlying page. This also creates protected critical regions
whithin which the caller can bump the ref count of a page
(e.g. while establishing a mapping) without being exposed to 
races.

Locking of 2MB ranges is recursive, and we also allow a global 
lock on the full p2m for heavy handed operations like log-dirty.

There are plenty of design choices to discuss. The hope is to 
foster some input and progress on this. Some of the questions
below will make sense once you go through the patches:
- is locking on a 4kb basis necessary? (guess: no)
- we do some ugly things to fit 512 spinlocks in a page...
- can we hold a entry "captive" for the lifetime of a 
  foreign mapping? will that not collide against globally-
  locking p2m operations such as log dirty? We've decided
  no and yes, so far.
- is our current implementation for holding the global
  p2m lock in a non-exclusive manner too heavy handed on
  barriers and spinlocks? Could we just get away with atomics?
- we've considered read/writer locks. But many code paths
  require promotions not known a priori, and a deadlock-free
  promotion is risky to achieve. The semantics of exclusive
  locking simply make it easier (hah!) to reason.
- I'm unclear on the lifespan of some pointers in the nested 
  hvm code (e.g. nv_vvmcx). For p2m purposes, the entries are
  locked and unlocked in different functions, that I'm not sure
  happen in pair within the same scheduler slice. Would that 
  violate in_atomic()?
- note the last patch is massive. There is no way around 
  modifying all callers of p2m queries.

Signed-off-by: Andres Lagar-Cavilla <andres@xxxxxxxxxxxxxxxx>

 xen/arch/x86/mm/mm-locks.h         |   27 +-
 xen/arch/x86/mm/mm-locks.h         |   27 +
 xen/arch/x86/mm/mm-locks.h         |   11 +
 xen/arch/x86/mm/p2m-pod.c          |   40 +-
 xen/include/asm-x86/p2m.h          |    5 +
 xen/arch/x86/mm/mm-locks.h         |    9 +
 xen/arch/x86/mm/p2m-pod.c          |  145 +++++---
 xen/arch/x86/mm/p2m-pt.c           |    3 +
 xen/arch/x86/mm/p2m.c              |    7 +-
 xen/include/asm-x86/p2m.h          |   25 +-
 xen/arch/x86/mm/hap/private.h      |    1 +
 xen/arch/x86/mm/mm-locks.h         |   20 +-
 xen/arch/x86/mm/p2m-ept.c          |    1 +
 xen/arch/x86/mm/p2m-lock.h         |  613 +++++++++++++++++++++++++++++++++++++
 xen/arch/x86/mm/p2m-pod.c          |    1 +
 xen/arch/x86/mm/p2m-pt.c           |    1 +
 xen/arch/x86/mm/p2m.c              |   24 +-
 xen/include/asm-x86/p2m.h          |    3 +-
 xen/arch/x86/mm/p2m-ept.c          |   15 +-
 xen/arch/x86/mm/p2m-lock.h         |   11 +-
 xen/arch/x86/mm/p2m-pt.c           |   82 +++-
 xen/arch/x86/mm/p2m.c              |   38 ++
 xen/include/asm-x86/p2m.h          |   40 +--
 xen/arch/x86/mm/hap/hap.c          |    2 +-
 xen/arch/x86/mm/hap/nested_hap.c   |   21 +-
 xen/arch/x86/mm/p2m-ept.c          |   26 +-
 xen/arch/x86/mm/p2m-pod.c          |   42 +-
 xen/arch/x86/mm/p2m-pt.c           |   20 +-
 xen/arch/x86/mm/p2m.c              |  185 +++++++----
 xen/include/asm-ia64/mm.h          |    5 +
 xen/include/asm-x86/p2m.h          |   45 ++-
 xen/arch/x86/cpu/mcheck/vmce.c     |    7 +-
 xen/arch/x86/debug.c               |    7 +-
 xen/arch/x86/domain.c              |   24 +-
 xen/arch/x86/domctl.c              |    9 +-
 xen/arch/x86/hvm/emulate.c         |   25 +-
 xen/arch/x86/hvm/hvm.c             |  126 ++++++-
 xen/arch/x86/hvm/mtrr.c            |    2 +-
 xen/arch/x86/hvm/nestedhvm.c       |    2 +-
 xen/arch/x86/hvm/stdvga.c          |    4 +-
 xen/arch/x86/hvm/svm/nestedsvm.c   |   12 +-
 xen/arch/x86/hvm/svm/svm.c         |   11 +-
 xen/arch/x86/hvm/viridian.c        |    4 +
 xen/arch/x86/hvm/vmx/vmx.c         |   13 +-
 xen/arch/x86/hvm/vmx/vvmx.c        |   11 +-
 xen/arch/x86/mm.c                  |  126 ++++++-
 xen/arch/x86/mm/guest_walk.c       |   11 +
 xen/arch/x86/mm/hap/guest_walk.c   |   15 +-
 xen/arch/x86/mm/mem_event.c        |   28 +-
 xen/arch/x86/mm/mem_sharing.c      |   23 +-
 xen/arch/x86/mm/shadow/common.c    |    4 +-
 xen/arch/x86/mm/shadow/multi.c     |   67 +++-
 xen/arch/x86/physdev.c             |    9 +
 xen/arch/x86/traps.c               |   17 +-
 xen/common/grant_table.c           |   27 +-
 xen/common/memory.c                |    9 +
 xen/common/tmem_xen.c              |   21 +-
 xen/include/asm-x86/hvm/hvm.h      |    5 +-
 xen/include/asm-x86/hvm/vmx/vvmx.h |    1 +
 59 files changed, 1714 insertions(+), 401 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel