This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] [PATCH 00 of 13] [RFC] p2m cleanups

To: <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] [PATCH 00 of 13] [RFC] p2m cleanups
From: Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Date: Fri, 13 May 2011 17:28:42 +0100
Delivery-date: Fri, 13 May 2011 09:31:00 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mercurial-patchbomb/1.6.4
This series is the current state of my p2m cleanups; it passes
basic smoke-tests but needs more serious testing before it's
ready to go in.  I'm posting it as an RFC for now so anyone who's
interested in it can see the way things are going and maybe even
give feedback before I get too far down this particular rabbit-hole. 

So far, it:
 - fixes a lot of locking bugs 
 - tidies up the p2m interface, mostly to stop the callers needing to know
   about internal p2m cruft. 
 - collects all the x86/mm locks together, defining and enforcing a 
   locking order. 

Next stages: 
 - Fix the ugly "need_lock" semi-recursive locking.
 - Fix the idiom where many callers of gfn_to_mfn_* immediately 
   have to page in or unshare the result by moving that logic
   into p2m code and requesting it with a flag.
 - Disentangle the page allocators from hap and shadow, and put them 
   under their own lock, which will allow me to undo some of the
   contortions the log-dirty code goes to when allocating memory.
 - Sort out the interactions between nested HAP and memory 
After all that (phew!) I should be in a position to look at
integrating the p2m code and the core typecounting code better, 
to avoid the TOCTOU races that have been pointed out in the 
memory sharing code. 



Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd.  (Company #02937203, SL9 0BG)

Xen-devel mailing list