Re: [Xen-devel] [PATCH 1 of 3] tools/libxl: QEMU device model suspend/resume

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2012-01-25 at 23:07 +0000, Shriram Rajagopalan wrote:
> On Wed, Jan 25, 2012 at 3:08 AM, Ian Campbell 

>         > -        libxl__xs_write(gc, XBT_NULL, path, "save");
>         > -        libxl__wait_for_device_model(gc, domid, "paused",
>         NULL, NULL, NULL);
>         > +        /* For Remus,we issue suspend_qemu call separately
>         */
>         
>         
>         Why?
>         
> 
> In remus, save and transmit device model phases are decoupled. This
> code (sending the saved device model to the target) is executed after
> the domain is resumed.
> 
> The control flow in current Remus is like this:
> 1 suspend vm
>   1.1 suspend qemu (save command, that saves the device model to a
> file)
> 2 copy out dirty memory into a buffer
> 3 resume vm 
>   3.1 resume qemu
> 4 send the data in the buffer
> 5  send the saved device model
>     (xc_domain_restore extracts this from the tailbuf)

Is this basic flow incompatible with regular save? Isn't it equivalent
to to omitting phase 3? (I know regular save is structured a bit
different right now, but it could be done this way to minimise the
amount of Remus specific code).

Which "struct save_callbacks" members do each of these stages correspond
to?

I think a high level overview of the ordering of operations and the
usage of these hooks would make an ideal comment just above the
definition of "struct save_callbacks", what do you think?

>         How does this interact with Stefano's XC_SAVEID_TOOLSTACK
>         patches?
>         
> 
>  I couldnt find anything online by this name. Can you point me to the
> patch series? 

"libxl: save/restore qemu physmap" posted last Friday.

We would also like to see the qemu restore done in a callback hook for
symmetry with the save hook.

Ian.



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