[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Xen-devel] [PATCH 00 of 13] [RFC] p2m cleanups
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
- 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