All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0 of 9] [RFC] p2m fine-grained concurrency control
@ 2011-10-27  4:33 Andres Lagar-Cavilla
  2011-10-27  4:33 ` [PATCH 1 of 9] Refactor mm-lock ordering constructs Andres Lagar-Cavilla
                   ` (8 more replies)
  0 siblings, 9 replies; 31+ messages in thread
From: Andres Lagar-Cavilla @ 2011-10-27  4:33 UTC (permalink / raw)
  To: xen-devel; +Cc: andres, keir.xen, tim, olaf, adin

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@lagarcavilla.org>

 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(-)

^ permalink raw reply	[flat|nested] 31+ messages in thread

end of thread, other threads:[~2011-11-03 15:20 UTC | newest]

Thread overview: 31+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-10-27  4:33 [PATCH 0 of 9] [RFC] p2m fine-grained concurrency control Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 1 of 9] Refactor mm-lock ordering constructs Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 2 of 9] Declare an order-enforcing construct for external locks used in the mm layer Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 3 of 9] Enforce ordering constraints for the page alloc lock in the PoD code Andres Lagar-Cavilla
2011-10-27 13:36   ` Tim Deegan
2011-11-02 13:59     ` andres
2011-11-03 13:49       ` Tim Deegan
2011-10-27  4:33 ` [PATCH 4 of 9] Rework locking in the PoD layer Andres Lagar-Cavilla
2011-10-27 13:55   ` Tim Deegan
2011-11-02 14:04     ` andres
2011-11-02 22:30   ` George Dunlap
2011-11-03 14:57     ` Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 5 of 9] Fine-grained concurrency control structure for the p2m Andres Lagar-Cavilla
2011-10-27 14:43   ` Tim Deegan
2011-11-02 14:20     ` andres
2011-11-03 14:29       ` Tim Deegan
2011-11-03 14:46         ` Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 6 of 9] Protect superpage splitting in implementation-dependent traversals Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 7 of 9] Refactor p2m get_entry accessor Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 8 of 9] Modify all internal p2m functions to use the new fine-grained locking Andres Lagar-Cavilla
2011-10-27 14:57   ` Tim Deegan
2011-11-02 14:24     ` andres
2011-11-03 14:33       ` Tim Deegan
2011-11-03 15:16         ` Andres Lagar-Cavilla
2011-11-02 23:00   ` George Dunlap
2011-11-03 15:14     ` Andres Lagar-Cavilla
2011-10-27  4:33 ` [PATCH 9 of 9] Modify all call sites of queries into the p2m " Andres Lagar-Cavilla
2011-10-27 15:02   ` Tim Deegan
2011-11-02 14:32     ` andres
2011-11-03 14:38       ` Tim Deegan
2011-11-03 15:20         ` Andres Lagar-Cavilla

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.