Re: [Xen-devel] early_savevm

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Tue, 13 Dec 2011, Jan Kiszka wrote:
> On 2011-12-13 12:55, Stefano Stabellini wrote:
> > On Mon, 12 Dec 2011, Stefano Stabellini wrote:
> >>> Really, I think this is something inherently incompatible with the
> >>> current memory API. If Xen has this unfixable special "requirement"
> >>> (it's rather a design issue IMHO), adjust the API and adapt all devices.
> >>> Hot-fixing only a single one this way is no good idea long term.
> >>
> >> Fair enough.
> >> What about introducing a type of savevm state that is going to be
> >> restored before machine->init?
> >> This way we could save and restore our physmap and we could handle
> >> memory maps and allocations transparently.
> >>
> > 
> > A bit more context to my suggestion:
> > 
> > - we open the save state file and check the magic number and the
> > version number before machine->init();
> > 
> > - we add a new set of entries to the save state file that contains
> > early_savevm functions: they are called before machine->init();
> > 
> > - after reaching the end of the early_savevm functions we stop parsing
> > the save state file and we call machine->init();
> > 
> > - after machine->init() is completed we continue parsing the save state
> > file as usual.
> 
> Hmm, just wondering if another use case for this early incoming
> migration step is transferring the machine configuration so that the
> receiver need not worry about synchronizing it out of band. That may
> help motivating this likely not trivial change.

Actually I was thinking the same thing. I am sure that if we had such a
thing as early_savevm, a few other use cases will certainly show up.

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