Re: [Xen-devel] [PATCH 4/6] libxc, libxl, hvmloader: strip out outdated VM generation ID implementation

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2014-05-27 at 18:31 +0100, David Vrabel wrote:
> The VM generation ID support in libxc/libxl was based on a draft
> specification which subsequently changed considerably.  Remove much of
> the code in anticipation of introducing something simpler that
> conforms to the current specification from Microsoft.
> 
> Switch to using a HVM param (HVM_PARAM_VM_GENERATION_ID_ADDR) instead
> of the hvmloader/generation-id-address XenStore key.  This simplifies
> save/restore since it only needs to transfer the value of this param.
> 
> Signed-off-by: David Vrabel <david.vrabel@xxxxxxxxxx>
> ---
>  tools/firmware/hvmloader/acpi/build.c |    9 +++----
>  tools/libxc/xc_domain_restore.c       |   44 
> +++------------------------------
>  tools/libxc/xc_domain_save.c          |    5 ++--
>  tools/libxc/xenguest.h                |    8 ++----
>  tools/libxl/libxl_create.c            |   12 +++------
>  tools/libxl/libxl_dom.c               |   25 ++-----------------
>  tools/libxl/libxl_internal.h          |    8 ++----
>  tools/libxl/libxl_save_callout.c      |   10 +++-----
>  tools/libxl/libxl_save_helper.c       |    9 +++----
>  tools/libxl/libxl_save_msgs_gen.pl    |    3 +--

I've forgotten how this existing stuff works, but since there is no
touching of libxl_types.idl or libxl.h here I think there was no
application facing nob for the existing stuff, right? (the relevant
libxc parameter is hardcoded in libxl).

Hence nothing to remove and nothing to add a comment about.

> diff --git a/tools/libxc/xc_domain_save.c b/tools/libxc/xc_domain_save.c
> index 71f9b59..42094e8 100644
> --- a/tools/libxc/xc_domain_save.c
> +++ b/tools/libxc/xc_domain_save.c
> @@ -802,8 +802,7 @@ static int save_tsc_info(xc_interface *xch, uint32_t dom, 
> int io_fd)
>  
>  int xc_domain_save(xc_interface *xch, int io_fd, uint32_t dom, uint32_t 
> max_iters,
>                     uint32_t max_factor, uint32_t flags,
> -                   struct save_callbacks* callbacks, int hvm,
> -                   unsigned long vm_generationid_addr)
> +                   struct save_callbacks* callbacks, int hvm)
>  {
>      xc_dominfo_t info;
>      DECLARE_DOMCTL;
> @@ -1634,7 +1633,7 @@ int xc_domain_save(xc_interface *xch, int io_fd, 
> uint32_t dom, uint32_t max_iter
>          } chunk = { 0, };
>  
>          chunk.id = XC_SAVE_ID_HVM_GENERATION_ID_ADDR;
> -        chunk.data = vm_generationid_addr;
> +        xc_get_hvm_param(xch, dom, HVM_PARAM_VM_GENERATION_ID_ADDR, 
> &chunk.data);

Are there any N->N+1 migration concerns here?

I don't think so, since the stream always contains the address and what
happens to it is entirely internal to the given host. Is that correct?

Ian.


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