[Xen-devel] [PATCH 0 of 8 [RFC]] Move all the memory of a domain

[Dario Faggioli <dario.faggioli@xxxxxxxxxx>]

Hi everyone,

It's been a while now since I started working on trying to implement a
mechanism for moving all the memory of a domain from one NUMA node to another.
Yes, that is part of the more general work about improving Xen NUMA support I'm
carrying on... For more details, see here:

 http://wiki.xen.org/wiki/Xen_NUMA_Roadmap.

The approach I decided to take is to mimic a sort of back-to-back save/restore.
In some more details, I'm suspending a domain, deallocating all its memory,
reallocating it to different places (especially, for instance, if the NUMA
node-affinity changed in the meanwhile), update the domain's and the Xen's
address translation tables, and resume the domain back. Easy eh? :-D

All the above happens at the libxc level, although the patch series provides
all the glue code needed to interact with the new feature from both libxl and
xl.

Also, consider that this fisrt series focuses on PV guests. For HVM, some "if
(hvm)" here and there will do the trick, together, of course, with the proper
updating of HAP tables, etc. ... Still much less work than all the tweaking
required by PV-guests! I'll include more HVM bits in future releases of this
series, but, in case you have, do feel free to  provide you comments on that
aspect too, even right now.

I got sidetracked and distracted many times, and I have to admit, this is not
quite a done job yet. However, I reached the point where, at least part of what
I have can be shown here, so that you can provide some early feedback on it,
and help me proceed further, with future design choices and implementation
steps.

I have to say I find it quite challenging as, especially for PV, it touches and
exercises a lot of code paths and features I'm not yet so much familiar with.
That is why feedback is really important, even if the thing is still at an
early stage. For instances, discussing how to properly deal with things like
grant tables, or TMEM, or how to make sure we do not mess up vCPU contexts,
would be really great. Despite the RFC status, I did my best in trying to
facilitate that, both when writing the code and the comments/changelogs for
each patch... For instance, I've put some 'XXX' marked spots where I thought
something was missing and/or commenting is most needed. If you find 5 minutes
to look into them, that would be much appreciated. :-)

I know we're in a very particular moment, due to 4.3 freeze, so I understand if
people are busy finalizing the existing and proposed features, instead of
reviewing RFCs for new ones, but I still felt like it would be worthwhile to
send this out. Let's see if anyone take this chance of telling me how bad it
looks! ;-P

About the series, the patches on which to concentrate on are, especially at
this stage:

 6/8 libxc: introduce xc_domain_move_memory
 7/8 libxl: introduce libxl_domain_move_memory

The others are introducing minor changes, ancillary to the two above.

Thanks in advance and Regards,
Dario

--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel