Re: [Xen-devel] [PATCH 3/3] libxc/migrationv2: Split {start, end}_of_stream() to make checkpoint variants

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Fri, 2015-05-08 at 13:54 +0100, Andrew Cooper wrote:
> This is in preparation for supporting checkpointed streams in migration v2.
>  - For PV guests, the VCPU context is moved to end_of_checkpoint().
>  - For HVM guests, the HVM context and params are moved to 
> end_of_checkpoint().

[...]
> +    /**
> +     * Send records which need to be at the end of the checkpoint.  This is
> +     * called once, or once per checkpoint in a checkpointed stream, and is
> +     * after the memory data.
> +     */
> +    int (*end_of_checkpoint)(struct xc_sr_context *ctx);
> +
> +    /**
> +     * Send records which need to be at the end of the stream.  This is 
> called
> +     * once, before the END record is written.
>       */
>      int (*end_of_stream)(struct xc_sr_context *ctx);
[...]
> +static int x86_hvm_end_of_stream(struct xc_sr_context *ctx)
> +{
> +    int rc;
> +
> +    rc = write_tsc_info(ctx);
>      if ( rc )
>          return rc;
>  
> -    /* Write HVM_PARAMS record contains applicable HVM params. */
> -    rc = write_hvm_params(ctx);
> +#ifdef XG_LIBXL_HVM_COMPAT
> +    rc = write_toolstack(ctx);

I'm not sure about this end_of_stream thing. In a check pointing for
fault tolerance scenario (Remus or COLO) then failover happens when the
sender has died for some reason, and therefore won't get the chance to
send any end of stream stuff.

IOW I think everything in end_of_stream actually needs to be in
end_of_checkpoint unless it is just for informational purposes in a
regular migration or something (which write_toolstack surely isn't)

Ian.


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