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

[Tim Deegan <Tim.Deegan@xxxxxxxxxx>]

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 
   sharing/paging. 
 
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. 

Cheers,

Tim.

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

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