Support for VM generation ID save/restore and migrate
PATCH 1/1 Support for VM generation ID save/restore and migrate
This patch series adds support for preservation of the VM generation ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for migration.
The first patch modifies creation of the hvmloader key in xenstore and adds creation of a new read/write hvmloader/generation-id-addr key.
The second patch changes hvmloader to use the new key (as opposed to the old data/generation-id key).
The third patch adds the infrastructure to save and restore the VM generation ID address in xenstore and the code to increment the value.
PATCH 1/1 Make ro_paths and rw_paths dynamic
# HG changeset patch
# User Paul Durrant <[email protected]> # Date 1324035832 0
# Node ID 24fc8670dfcaa9cbdfd89532823b68feb96ca2eb # Parent 03138a08366b895d79e143119d4c9c72833cdbcd Make ro_paths and rw_paths dynamic.
The paths need to be different for the HVM and non-HVM cases as, in the HVM case, we need an 'hvmloader' key. This was previously handled by creating the hvmloader key in libxl__create_device_model(), which is only invoked for HVM guests. However, if we are to use the hvmloader key to parent the 'generation-id-address' key, the creation needs to move earlier in the sequence. Handling this by making ro_paths and rw_paths dynamic in libxl__domain_make() seems like the cleanest approach.
The read-only 'error', 'drivers', 'attr' and 'messages' keys are no longer created as they seem to be completely unused.
tools/libxl/libxl_create.c +34 -8
@@ -322,9 +322,10 @@ int libxl__domain_make(libxl__gc *gc, lilibxl_ctx *ctx =libxl__gc_owner (gc);int flags, ret, i, rc;char *uuid_string; -char *rw_paths[] = {"control/shutdown" ,"device" ,"device/suspend/event-channel" ,"data" }; -char *ro_paths[] = {"cpu" ,"memory" ,"device" ,"error" ,"drivers" , -"control" ,"attr" ,"messages" }; +char **ro_paths; +int nr_ro_paths; +char **rw_paths; +int nr_rw_paths;char *dom_path, *vm_path, *libxl_path;struct xs_permissions roperm[2 ];struct xs_permissions rwperm[1 ];
@@ -341,6 +342,31 @@ int libxl__domain_make(libxl__gc *gc, li goto out; } + nr_ro_paths =0 ; +if (info->type ==LIBXL_DOMAIN_TYPE_HVM ) { + ro_paths =libxl__calloc (gc,5 ,sizeof (char *)); + ro_paths[nr_ro_paths++] ="hvmloader" ; + }else { + ro_paths =libxl__calloc (gc,4 ,sizeof (char *)); + } + + ro_paths[nr_ro_paths++] ="cpu" ; + ro_paths[nr_ro_paths++] ="memory" ; + ro_paths[nr_ro_paths++] ="device" ; + ro_paths[nr_ro_paths++] ="control" ; + + nr_rw_paths =0 ; +if (info->type ==LIBXL_DOMAIN_TYPE_HVM ) { + rw_paths =libxl__calloc (gc,4 ,sizeof (char *)); + rw_paths[nr_rw_paths++] ="hvmloader/generation-id-address" ; + }else { + rw_paths =libxl__calloc (gc,3 ,sizeof (char *)); + } + + rw_paths[nr_rw_paths++] ="control/shutdown" ; + rw_paths[nr_rw_paths++] ="device/suspend/event-channel" ; + rw_paths[nr_rw_paths++] ="data" ; + flags =0 ;if (info->type ==LIBXL_DOMAIN_TYPE_HVM ) { flags |= XEN_DOMCTL_CDF_hvm_guest;
@@ -414,16 +440,16 @@ retry_transaction:if (rc) goto out; -for (i =0 ; i <ARRAY_SIZE (rw_paths); i++) { -char *path =libxl__sprintf (gc,"%s/%s" , dom_path, rw_paths[i]); -xs_mkdir (ctx->xsh, t, path); -xs_set_permissions (ctx->xsh, t, path, rwperm,ARRAY_SIZE (rwperm)); - }for (i =0 ; i <ARRAY_SIZE (ro_paths); i++) {char *path =libxl__sprintf (gc,"%s/%s" , dom_path, ro_paths[i]);xs_mkdir (ctx->xsh, t, path);xs_set_permissions (ctx->xsh, t, path, roperm,ARRAY_SIZE (roperm)); } +for (i =0 ; i < nr_rw_paths; i++) { +char *path =libxl__sprintf (gc,"%s/%s" , dom_path, rw_paths[i]); +xs_mkdir (ctx->xsh, t, path); +xs_set_permissions (ctx->xsh, t, path, rwperm,ARRAY_SIZE (rwperm)); + }xs_write (ctx->xsh, t,libxl__sprintf (gc,"%s/uuid" , vm_path), uuid_string,strlen (uuid_string));xs_write (ctx->xsh, t,libxl__sprintf (gc,"%s/name" , vm_path), info->name,strlen (info->name));
tools/libxl/libxl_dm.c +1 -3
@@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc goto out; } - path =libxl__sprintf (gc,"/local/domain/%d/hvmloader" , info->domid); -xs_mkdir (ctx->xsh,XBT_NULL , path); -libxl__xs_write (gc,XBT_NULL ,libxl__sprintf (gc,"%s/bios" , path), +libxl__xs_write (gc,XBT_NULL ,libxl__sprintf (gc,"/local/domain/%d/hvmloader/bios" , info->domid),"%s" ,libxl__domain_bios (gc, info)); path =libxl__sprintf (gc,"/local/domain/0/device-model/%d" , info->domid);
Re: [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
tools/libxl/libxl_create.c int libxl__domain_make(libxl__gc *gc, li · line 356
Quoted 12 lines · Paul Durrant
tools/libxl/libxl_create.c +12
-0+ nr_ro_paths =0 ; +if (info->type ==LIBXL_DOMAIN_TYPE_HVM ) { + ro_paths =libxl__calloc (gc,5 ,sizeof (char *)); + ro_paths[nr_ro_paths++] ="hvmloader" ; + }else { + ro_paths =libxl__calloc (gc,4 ,sizeof (char *)); + } + + ro_paths[nr_ro_paths++] ="cpu" ; + ro_paths[nr_ro_paths++] ="memory" ; + ro_paths[nr_ro_paths++] ="device" ; + ro_paths[nr_ro_paths++] ="control" ;
The flexarray stuff allows you do to this sort of thing without worrying about running off the end of the allocated array etc.
Part of me thinks that if the arrays aren't static any more you might as well just do the create in an open coded list, instead of open coding the creation of a list and then iterating over it.
A helper function like libxl__xs_mkdir(gc, t, path, perm) would reduce the amount of boilerplate.
Quoted 9 lines
tools/libxl/libxl_create.c +0
-5@@ -414,16 +440,16 @@ retry_transaction:if (rc) goto out; -for (i =0 ; i <ARRAY_SIZE (rw_paths); i++) { -char *path =libxl__sprintf (gc,"%s/%s" , dom_path, rw_paths[i]); -xs_mkdir (ctx->xsh, t, path); -xs_set_permissions (ctx->xsh, t, path, rwperm,ARRAY_SIZE (rwperm)); - }
tools/libxl/libxl_create.c retry_transaction: · line 452
Quoted 10 lines
tools/libxl/libxl_create.c +5
-0for (i =0 ; i <ARRAY_SIZE (ro_paths); i++) {char *path =libxl__sprintf (gc,"%s/%s" , dom_path, ro_paths[i]);xs_mkdir (ctx->xsh, t, path);xs_set_permissions (ctx->xsh, t, path, roperm,ARRAY_SIZE (roperm)); } +for (i =0 ; i < nr_rw_paths; i++) { +char *path =libxl__sprintf (gc,"%s/%s" , dom_path, rw_paths[i]); +xs_mkdir (ctx->xsh, t, path); +xs_set_permissions (ctx->xsh, t, path, rwperm,ARRAY_SIZE (rwperm)); + }
What does "xenstore-ls -fp" show before and after this re-ordering?
Quoted 8 lines
tools/libxl/libxl_create.c +0
-0xs_write (ctx->xsh, t,libxl__sprintf (gc,"%s/uuid" , vm_path), uuid_string,strlen (uuid_string));xs_write (ctx->xsh, t,libxl__sprintf (gc,"%s/name" , vm_path), info->name,strlen (info->name));diff -r
03138a08366b-r24fc8670dfcatools/libxl/libxl_dm.c
tools/libxl/libxl_dm.c Fri Dec 16 11:43:52 2011 +0000 int libxl__create_device_model(libxl__gc · line 827
Quoted 10 lines
tools/libxl/libxl_dm.c Fri Dec 16 11:43:52 2011 +0000 renamed from tools/libxl/libxl_dm.c Fri Dec 09 16:19:36 2011 +0000 +1
-3@@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc goto out; } - path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info->domid); - xs_mkdir(ctx->xsh, XBT_NULL, path); - libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios", path), + libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "/local/domain/%d/hvmloader/bios", info->domid), "%s", libxl__domain_bios(gc, info)); path = libxl__sprintf(gc, "/local/domain/0/device-model/%d", info->domid);
Pre-existing problem but this should be libxl__xs_get_dompath.
Ian.
Re: [PATCH 1 of 3] Make ro_paths and rw_paths dynamic
Quoted 25 lines
-----Original Message-----
From: Ian Campbell
Sent: 16 December 2011 12:02
To: Paul Durrant
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 1 of 3] Makero_pathsandrw_pathsdynamictools/libxl/libxl_create.c int libxl__domain_make(libxl__gc *gc, li · line 356
Quoted 12 lines · Paul Durrant
tools/libxl/libxl_create.c +12
-0+ nr_ro_paths =0 ; +if (info->type ==LIBXL_DOMAIN_TYPE_HVM ) { + ro_paths =libxl__calloc (gc,5 ,sizeof (char *)); + ro_paths[nr_ro_paths++] ="hvmloader" ; + }else { + ro_paths =libxl__calloc (gc,4 ,sizeof (char *)); + } + + ro_paths[nr_ro_paths++] ="cpu" ; + ro_paths[nr_ro_paths++] ="memory" ; + ro_paths[nr_ro_paths++] ="device" ; + ro_paths[nr_ro_paths++] ="control" ;The flexarray stuff allows you do to this sort of thing without worrying about running off the end of the allocated array etc.
Quoted 7 lines
Part of me thinks that if the arrays aren't static any more you might as well just do the create in an open coded list, instead of open coding the creation of a list and then iterating over it.
A helper function like
libxl__xs_mkdir(gc, t, path, perm)would reduce the amount of boilerplate.
Actually, yes, the helper function would be a much neater solution. I'll go for that.
Paul
Quoted 57 lines
tools/libxl/libxl_create.c retry_transaction: · line 418
Quoted 6 lines
tools/libxl/libxl_create.c +0
-2@@ -414,16 +440,16 @@ retry_transaction:if (rc) goto out; -for (i =0 ; i <ARRAY_SIZE (rw_paths); i++) { - char *path = libxl__sprintf(gc, "%s/%s", dom_path,rw_paths[i]);
Review retry_transaction: · line 420
Quoted 2 lines
(quoted diff) +0
-2- xs_mkdir(ctx->xsh, t, path); - xs_set_permissions(ctx->xsh, t, path, rwperm,
ARRAY_SIZE(rwperm));tools/libxl/libxl_create.c retry_transaction:
Quoted 3 lines
tools/libxl/libxl_create.c +0
-1- }for (i =0 ; i <ARRAY_SIZE (ro_paths); i++) { char *path = libxl__sprintf(gc, "%s/%s", dom_path,ro_paths[i]);
Review retry_transaction: · line 446
Quoted 2 lines
(quoted diff) +0
-0xs_mkdir(ctx->xsh, t, path); xs_set_permissions(ctx->xsh, t, path, roperm,
ARRAY_SIZE(roperm));tools/libxl/libxl_create.c retry_transaction:
Quoted 3 lines
tools/libxl/libxl_create.c +2
-0} +for (i =0 ; i < nr_rw_paths; i++) { + char *path = libxl__sprintf(gc, "%s/%s", dom_path,rw_paths[i]);
Review retry_transaction: · line 451
Quoted 2 lines
(quoted diff) +2
-0+ xs_mkdir(ctx->xsh, t, path); + xs_set_permissions(ctx->xsh, t, path, rwperm,
ARRAY_SIZE(rwperm));Review retry_transaction: · line 452
Quoted 1 line
(quoted diff) +1
-0+ }What does "xenstore-ls -fp" show before and after this re-ordering?
Review retry_transaction: · line 453
Quoted 1 line
(quoted diff) +0
-0xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/uuid", vm_path),
uuid_string,strlen(uuid_string));Quoted 8 lines
(quoted diff) +0
-0xs_write(ctx->xsh, t, libxl__sprintf(gc, "%s/name", vm_path), info->name, strlen(info->name));diff -r
03138a08366b-r24fc8670dfcatools/libxl/libxl_dm.ctools/libxl/libxl_dm.c Fri Dec 16 11:43:52 2011 +0000 int libxl__create_device_model(libxl__gc · line 827
Quoted 7 lines
tools/libxl/libxl_dm.c Fri Dec 16 11:43:52 2011 +0000 renamed from tools/libxl/libxl_dm.c Fri Dec 09 16:19:36 2011 +0000 +0
-3@@ -821,9 +821,7 @@ int libxl__create_device_model(libxl__gc goto out; } - path = libxl__sprintf(gc, "/local/domain/%d/hvmloader", info- domid); - xs_mkdir(ctx->xsh, XBT_NULL, path); - libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, "%s/bios",path),
Quoted 6 lines
tools/libxl/libxl_dm.c Fri Dec 16 11:43:52 2011 +0000 renamed from tools/libxl/libxl_dm.c Fri Dec 09 16:19:36 2011 +0000 +2
-0+ libxl__xs_write(gc, XBT_NULL, libxl__sprintf(gc, + "/local/domain/%d/hvmloader/bios", info->domid), "%s", libxl__domain_bios(gc, info)); path = libxl__sprintf(gc, "/local/domain/0/device-model/%d",
info->domid);Pre-existing problem but this should be
libxl__xs_get_dompath.Ian.
PATCH 1/1 Re-name xenstore key used to save VM generation ID buffer address
In reply to Paul Durrant# HG changeset patch
# User Paul Durrant <[email protected]>
# Date 1324035832 0
# Node ID d44e885e0389e1e2cad544d098f47c37f2d5a755
# Parent 24fc8670dfcaa9cbdfd89532823b68feb96ca2eb Re-name xenstore key used to save VM generation ID buffer address.
tools/firmware/hvmloader/acpi/build.c +1 -1
@@ -309,7 +309,7 @@ unsigned long new_vm_gid(void)if (snprintf (addr,sizeof (addr),"0x%lx" ,virt_to_phys (buf)) >=sizeof (addr) )return 0 ; -xenstore_write ("data/generation-id" , addr); +xenstore_write ("hvmloader/generation-id-address" , addr); gid =strtoll (xenstore_read ("platform/generation-id" ,"0" ),NULL ,0 ); *(uint64_t *)buf = gid;
PATCH 1/1 VM generation ID save/restore and migrate
In reply to Paul Durrant# HG changeset patch
# User Paul Durrant <[email protected]> # Date 1324035833 0
# Node ID e745cfbe7e114cb8a8c331cb6b9c711462300c1f # Parent d44e885e0389e1e2cad544d098f47c37f2d5a755 VM generation ID save/restore and migrate.
Add code to track the address of the VM generation ID buffer across a save/restore or migrate, and increment it as necessary. The address of the buffer is written into xenstore by hvmloader at boot time. It must be read from xenstore by the caller of xc_domain_save() and then written back again by the caller of xc_domain_restore().
tools/libxc/ia64/xc_ia64_linux_restore.c +3 -1
@@ -548,7 +548,9 @@ int xc_domain_restore(xc_interface *xch, int io_fd, uint32_t dom, unsigned int store_evtchn, unsigned long *store_mfn, unsigned int console_evtchn, unsigned long *console_mfn, - unsigned int hvm, unsigned int pae, int superpages) + unsigned int hvm, unsigned int pae, int superpages, + int no_incr_generationid, + unsigned long *vm_generationid_addr) {DECLARE_DOMCTL ;int rc =1 ;
tools/libxc/ia64/xc_ia64_linux_save.c +2 -1
@@ -382,7 +382,8 @@ out: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) +struct save_callbacks * callbacks,int hvm, +unsigned long vm_generationid_addr) {DECLARE_DOMCTL ;xc_dominfo_t info;
tools/libxc/xc_domain_restore.c +48 -1
73 lines not on this page · raw message
tools/libxc/xc_domain_save.c +12 -1
@@ -804,7 +804,8 @@ static int save_tsc_info(xc_interface *xint 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) +struct save_callbacks * callbacks,int hvm, +unsigned long vm_generationid_addr) {xc_dominfo_t info;DECLARE_DOMCTL ;
@@ -1616,6 +1617,16 @@ int xc_domain_save(xc_interface *xch, inuint64_t data; } chunk = { 0, }; + chunk.id =XC_SAVE_ID_HVM_GENERATION_ID_ADDR ; + chunk.data = vm_generationid_addr; + +if ( (chunk.data !=0 ) && +wrexact (io_fd, &chunk,sizeof (chunk)) ) + { +PERROR ("Error when writing the generation id buffer location for guest" ); + goto out; + } + chunk.id =XC_SAVE_ID_HVM_IDENT_PT ; chunk.data =0 ; xc_get_hvm_param(xch, dom, HVM_PARAM_IDENT_PT,
tools/libxc/xenguest.h +7 -2
@@ -58,7 +58,8 @@ struct save_callbacks {*/ int xc_domain_save (xc_interface *xch,int io_fd,uint32_t dom,uint32_t max_iters,uint32_t max_factor,uint32_t flags/* XCFLAGS_xxx */ , -struct save_callbacks * callbacks,int hvm); +struct save_callbacks * callbacks,int hvm, +unsigned long vm_generationid_addr);/**
@@ -72,12 +73,16 @@ int xc_domain_save(xc_interface *xch, in* @parm hvm non-zero if this is a HVM restore * @parm pae non-zero if this HVM domain has PAE support enabled * @parm superpages non-zero to allocate guest memory with superpages +* @parm no_incr_generationid non-zero if generation id is NOT to be incremented +* @parm vm_generationid_addr returned with the address of the generation id buffer * @return 0 on success, -1 on failure */ int xc_domain_restore (xc_interface *xch,int io_fd,uint32_t dom,unsigned int store_evtchn,unsigned long *store_mfn,unsigned int console_evtchn,unsigned long *console_mfn, -unsigned int hvm,unsigned int pae,int superpages); +unsigned int hvm,unsigned int pae,int superpages, +int no_incr_generationid, +unsigned long *vm_generationid_addr);/** * xc_domain_restore writes a file to disk that contains the device * model saved state.
tools/libxc/xg_save_restore.h +1 -0
@@ -253,6 +253,7 @@#define XC_SAVE_ID_HVM_VIRIDIAN -11#define XC_SAVE_ID_COMPRESSED_DATA -12/* Marker to indicate arrival of compressed data */ #define XC_SAVE_ID_ENABLE_COMPRESSION -13/* Marker to enable compression logic at receiver side */ +#define XC_SAVE_ID_HVM_GENERATION_ID_ADDR -14/* ** We process save/restore/migrate in batches of pages; the below
tools/libxl/libxl_create.c +1 -0
@@ -99,6 +99,7 @@ int libxl_init_build_info(libxl_ctx *ctx b_info->u.hvm.vpt_align =1 ; b_info->u.hvm.timer_mode =1 ; b_info->u.hvm.nested_hvm =0 ; + b_info->u.hvm.no_incr_generationid =0 ;break ;case LIBXL_DOMAIN_TYPE_PV : b_info->u.pv.slack_memkb =8 *1024 ;
tools/libxl/libxl_dom.c +31 -4
@@ -106,6 +106,7 @@ int libxl__build_pre(libxl__gc *gc, uint state->store_port =xc_evtchn_alloc_unbound (ctx->xch, domid,0 ); state->console_port =xc_evtchn_alloc_unbound (ctx->xch, domid,0 ); + state->vm_generationid_addr =0 ;return 0 ; }
@@ -117,7 +118,7 @@ int libxl__build_post(libxl__gc *gc, uinlibxl_ctx *ctx =libxl__gc_owner (gc);char *dom_path, *vm_path;xs_transaction_t t; -char **ents; +char **ents, **hvm_ents;int i;libxl_cpuid_apply_policy (ctx, domid);
@@ -143,6 +144,13 @@ int libxl__build_post(libxl__gc *gc, uin ?"offline" :"online" ; } + hvm_ents =NULL ; +if (info->type ==LIBXL_DOMAIN_TYPE_HVM ) { + hvm_ents =libxl__calloc (gc,3 ,sizeof (char *)); + hvm_ents[0 ] ="hvmloader/generation-id-address" ; + hvm_ents[1 ] =libxl__sprintf (gc,"0x%lx" , state->vm_generationid_addr); + } + dom_path =libxl__xs_get_dompath (gc, domid);if (!dom_path) {return ERROR_FAIL ;
@@ -153,6 +161,9 @@ retry_transaction: t =xs_transaction_start (ctx->xsh);libxl__xs_writev (gc, t, dom_path, ents); +if (info->type ==LIBXL_DOMAIN_TYPE_HVM ) +libxl__xs_writev (gc, t, dom_path, hvm_ents); +libxl__xs_writev (gc, t, dom_path, local_ents);libxl__xs_writev (gc, t, vm_path, vms_ents);
@@ -356,16 +367,19 @@ int libxl__domain_restore_common(libxl__/* read signature */ int rc;int hvm, pae, superpages; +int no_incr_generationid;switch (info->type) {case LIBXL_DOMAIN_TYPE_HVM : hvm =1 ; superpages =1 ; pae = info->u.hvm.pae; + no_incr_generationid = info->u.hvm.no_incr_generationid;break ;case LIBXL_DOMAIN_TYPE_PV : hvm =0 ; superpages =0 ; pae =1 ; + no_incr_generationid =0 ;break ;default :return ERROR_INVAL ;
@@ -373,7 +387,8 @@ int libxl__domain_restore_common(libxl__ rc =xc_domain_restore (ctx->xch, fd, domid, state->store_port, &state->store_mfn, state->console_port, &state->console_mfn, - hvm, pae, superpages); + hvm, pae, superpages, no_incr_generationid, + &state->vm_generationid_addr);if ( rc ) {LIBXL__LOG_ERRNO (ctx,LIBXL__LOG_ERROR ,"restoring domain" );return ERROR_FAIL ;
@@ -539,12 +554,23 @@ int libxl__domain_suspend_common(libxl__struct save_callbacks callbacks;struct suspendinfo si;int hvm, rc =ERROR_FAIL ; +unsigned long vm_generationid_addr;switch (type) { -case LIBXL_DOMAIN_TYPE_HVM : +case LIBXL_DOMAIN_TYPE_HVM : { +char *path; +char *addr; + + path =libxl__sprintf (gc,"%s/hvmloader/generation-id-address" , +libxl__xs_get_dompath (gc, domid)); + addr =libxl__xs_read (gc,XBT_NULL , path); + + vm_generationid_addr = (addr) ?strtoul (addr,NULL ,0 ) :0 ; hvm =1 ;break ; + }case LIBXL_DOMAIN_TYPE_PV : + vm_generationid_addr =0 ; hvm =0 ;break ;default :
@@ -582,7 +608,8 @@ int libxl__domain_suspend_common(libxl__ callbacks.switch_qemu_logdirty = libxl__domain_suspend_common_switch_qemu_logdirty; callbacks.data = &si; - rc =xc_domain_save (ctx->xch, fd, domid,0 ,0 , flags, &callbacks, hvm); + rc =xc_domain_save (ctx->xch, fd, domid,0 ,0 , flags, &callbacks, + hvm, vm_generationid_addr);if ( rc ) { LIBXL__LOG_ERRNO(ctx, LIBXL__LOG_ERROR, "saving domain: %s", si.guest_responded ?
tools/libxl/libxl_internal.h +1 -0
@@ -218,6 +218,7 @@ typedef struct {uint32_t console_port;unsigned long console_mfn; +unsigned long vm_generationid_addr; } libxl__domain_build_state; _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid,
tools/libxl/libxl_types.idl +1 -0
@@ -184,6 +184,7 @@ libxl_domain_build_info = Struct("domain ("vpt_align", bool), ("timer_mode", integer), ("nested_hvm", bool), + ("no_incr_generationid", bool), ])), ("pv", Struct(None, [("kernel", libxl_file_reference), ("slack_memkb", uint32),
tools/libxl/xl_cmdimpl.c +6 -0
@@ -360,6 +360,8 @@ static void printf_info(int domid,printf ("\t\t\t(vpt_align %d)\n" , b_info->u.hvm.vpt_align);printf ("\t\t\t(timer_mode %d)\n" , b_info->u.hvm.timer_mode);printf ("\t\t\t(nestedhvm %d)\n" , b_info->u.hvm.nested_hvm); +printf ("\t\t\t(no_incr_generationid %d)\n" , + b_info->u.hvm.no_incr_generationid);printf ("\t\t\t(device_model %s)\n" , dm_info->device_model ? :"default" );printf ("\t\t\t(videoram %d)\n" , dm_info->videoram);
@@ -1362,6 +1364,7 @@ struct domain_create {const char *restore_file;int migrate_fd;/* -1 means none */ char **migration_domname_r;/* from malloc */ +int no_incr_generationid; };static int freemem (libxl_domain_build_info *b_info,libxl_device_model_info *dm_info)
@@ -1575,6 +1578,8 @@ static int create_domain(struct domain_c } } + d_config.b_info.u.hvm.no_incr_generationid = dom_info->no_incr_generationid; +if (debug || dom_info->dryrun)printf_info (-1 , &d_config, &d_config.dm_info);
@@ -2800,6 +2805,7 @@ static void migrate_receive(int debug, i dom_info.restore_file ="incoming migration stream" ; dom_info.migrate_fd =0 ;/* stdin */ dom_info.migration_domname_r = &migration_domname; + dom_info.no_incr_generationid =1 ; rc =create_domain (&dom_info);if (rc <0 ) {
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c +14 -1
@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s {int hvm, rc;int flags =XCFLAGS_LIVE ; +unsigned long vm_generationid_addr;if (!s->domid) { s->errstr ="checkpoint state not opened" ;
@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s hvm = s->domtype > dt_pv;if (hvm) { +char path[128 ]; +char *addr; + +sprintf (path,"/local/domain/%u/hvmloader/generation-id-address" , s->domid); + addr =xs_read (s->xsh,XBT_NULL , path,NULL ); + + vm_generationid_addr = (addr) ?strtoul (addr,NULL ,0 ) :0 ; +free (addr); + flags |=XCFLAGS_HVM ;if (switch_qemu_logdirty (s,1 ))return -1 ; + }else { + vm_generationid_addr =0 ; }if (remus_flags &CHECKPOINT_FLAGS_COMPRESSION ) flags |=XCFLAGS_CHECKPOINT_COMPRESS ; callbacks->switch_qemu_logdirty = noop_switch_logdirty; - rc =xc_domain_save (s->xch, fd, s->domid,0 ,0 , flags, callbacks, hvm); + rc =xc_domain_save (s->xch, fd, s->domid,0 ,0 , flags, callbacks, hvm, + vm_generationid_addr);if (hvm)switch_qemu_logdirty (s,0 );
tools/xcutils/xc_restore.c +13 -5
@@ -23,11 +23,13 @@ main(int argc, char **argv)xc_interface *xch;int io_fd, ret;int superpages; -unsigned long store_mfn, console_mfn; +unsigned long store_mfn, console_mfn, vm_generationid_addr; +int no_incr_generationid; -if ( (argc !=8 ) && (argc !=9 ) ) +if ( (argc <8 ) || (argc >10 ) )errx (1 ,"usage: %s iofd domid store_evtchn " -"console_evtchn hvm pae apic [superpages]" , argv[0 ]); +"console_evtchn hvm pae apic " +"[superpages [no_incr_generationid]]" , argv[0 ]); xch =xc_interface_open (0 ,0 ,0 );if ( !xch )
@@ -40,19 +42,25 @@ main(int argc, char **argv) hvm =atoi (argv[5 ]); pae =atoi (argv[6 ]); apic =atoi (argv[7 ]); -if ( argc ==9 ) +if ( argc >=9 ) superpages =atoi (argv[8 ]);else superpages = !!hvm; +if ( argc ==10 ) + no_incr_generationid = !atoi (argv[9 ]); +else + no_incr_generationid =0 ; ret =xc_domain_restore (xch, io_fd, domid, store_evtchn, &store_mfn, - console_evtchn, &console_mfn, hvm, pae, superpages); + console_evtchn, &console_mfn, hvm, pae, superpages, + no_incr_generationid, &vm_generationid_addr);if ( ret ==0 ) {printf ("store-mfn %li\n" , store_mfn);if ( !hvm )printf ("console-mfn %li\n" , console_mfn); +printf ("generation-id-address %lx\n" , vm_generationid_addr);fflush (stdout); }
tools/xcutils/xc_save.c +19 -1
@@ -169,6 +169,10 @@ main(int argc, char **argv)unsigned int maxit, max_f;int io_fd, ret, port;struct save_callbacks callbacks; +char path[128 ]; +struct xs_handle *xs; +char *addr; +unsigned long vm_generationid_addr;if (argc !=6 )errx (1 ,"usage: %s iofd domid maxit maxf flags" , argv[0 ]);
@@ -207,8 +211,22 @@ main(int argc, char **argv)memset (&callbacks,0 ,sizeof (callbacks)); callbacks.suspend = suspend; callbacks.switch_qemu_logdirty = switch_qemu_logdirty; + +sprintf (path,"/local/domain/%d/hvmloader/generation-id-address" , si.domid); + +if ((xs =xs_daemon_open ()) ==NULL ) +errx (1 ,"Couldn't contact xenstore" ); + + addr =xs_read (xs,XBT_NULL , path,NULL ); + +xs_daemon_close (xs); + + vm_generationid_addr = (addr) ?strtoul (addr,NULL ,0 ) :0 ; +free (addr); + ret =xc_domain_save (si.xch, io_fd, si.domid, maxit, max_f, si.flags, - &callbacks, !!(si.flags &XCFLAGS_HVM )); + &callbacks, !!(si.flags &XCFLAGS_HVM ), + vm_generationid_addr);if (si.suspend_evtchn >0 )xc_suspend_evtchn_release (si.xch, si.xce, si.domid, si.suspend_evtchn);
Re: [PATCH 3 of 3] VM generation ID save/restore and migrate
Quoted 12 lines · Paul Durrant
diff -r
d44e885e0389-re745cfbe7e11tools/python/xen/lowlevel/checkpoint/libcheckpoint.ctools/python/xen/lowlevel/checkpoint/libcheckpoint.c Fri Dec 16 11:43:53 2011 +0000 renamed from tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Fri Dec 16 11:43:52 2011 +0000 +1
-0@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s { int hvm, rc; int flags = XCFLAGS_LIVE; + unsigned long vm_generationid_addr; if (!s->domid) { s->errstr = "checkpoint state not opened";
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Fri Dec 16 11:43:53 2011 +0000 int checkpoint_start(checkpoint_state* s · line 192
Quoted 7 lines
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Fri Dec 16 11:43:53 2011 +0000 renamed from tools/python/xen/lowlevel/checkpoint/libcheckpoint.c Fri Dec 16 11:43:52 2011 +0000 +4
-0@@ -185,16 +186,28 @@ int checkpoint_start(checkpoint_state* s hvm = s->domtype > dt_pv; if (hvm) { + char path[128]; + char *addr; + + sprintf(path, "/local/domain/%u/hvmloader/generation-id-address", s->domid);
xs_get_domain_path() gives you the correct base path (I saw at least one more of these).
Quoted 3 lines
diff -r
d44e885e0389-re745cfbe7e11tools/xcutils/xc_restore.ctools/xcutils/xc_restore.c Fri Dec 16 11:43:53 2011 +0000 renamed from tools/xcutils/xc_restore.c Fri Dec 16 11:43:52 2011 +0000 +0
-0
[...]
tools/xcutils/xc_save.c Fri Dec 16 11:43:53 2011 +0000
Quoted 3 lines
diff -r
d44e885e0389-re745cfbe7e11tools/xcutils/xc_save.ctools/xcutils/xc_save.c Fri Dec 16 11:43:53 2011 +0000 renamed from tools/xcutils/xc_save.c Fri Dec 16 11:43:52 2011 +0000 +0
-0
[...]
AFAIK these two are only used by xend so unless you are adding support for this stuff there (it's deprecated so no need) this isn't necessary, also I think xend reads the stdout of one or both and you've added to what gets printed, running the risk of breaking things.
Ian.
Re: [PATCH 3 of 3] VM generation ID save/restore and migrate
Quoted 33 lines
-----Original Message-----
From: Ian Campbell
Sent: 16 December 2011 12:08
To: Paul Durrant
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and migrateQuoted 1 line · Paul Durrant
diff -r
d44e885e0389-re745cfbe7e11
tools/python/xen/lowlevel/checkpoint/libcheckpoint.cQuoted 1 line
---
a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.cFri Dec 16 11:43:52 2011 +0000
Quoted 1 line
+++
b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.cFri Dec 16 11:43:53 2011 +0000
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c int checkpoint_start(checkpoint_state* s { · line 180
Quoted 7 lines
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c +1
-0@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s {int hvm, rc;int flags =XCFLAGS_LIVE ; +unsigned long vm_generationid_addr;if (!s->domid) { s->errstr = "checkpoint state not opened"; @@ -185,16+186,28
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c int checkpoint_start(checkpoint_state* s
Quoted 9 lines
@@ int checkpoint_start(checkpoint_state* s
hvm = s->domtype > dt_pv; if (hvm) {tools/python/xen/lowlevel/checkpoint/libcheckpoint.c +5
-0+char path[128 ]; +char *addr; + +sprintf (path, +"/local/domain/%u/hvmloader/generation-id-address" , s->domid);
Quoted 3 lines
xs_get_domain_path()gives you the correct base path (I saw at least one more of these).
Does that save me anything? I'd end up having to
sprintf(path, "%s/hvmloader/generation-id-address", xs_get_domain_path(s->xsh, s->domid))
since xs_read() just takes a path rather than a (prefix, node) couple.
Paul
Quoted 19 lines
Quoted 2 lines
diff -r
d44e885e0389-re745cfbe7e11tools/xcutils/xc_restore.c
---a/tools/xcutils/xc_restore.cFri Dec 16 11:43:52 2011+0000
Quoted 1 line
+++
b/tools/xcutils/xc_restore.cFri Dec 16 11:43:53 2011+0000
[...]tools/xcutils/xc_save.c Fri Dec 16 11:43:53 2011 +0000
Quoted 3 lines
diff -r
d44e885e0389-re745cfbe7e11tools/xcutils/xc_save.ctools/xcutils/xc_save.c Fri Dec 16 11:43:53 2011 +0000 renamed from tools/xcutils/xc_save.c Fri Dec 16 11:43:52 2011 +0000 +0
-0[...]
AFAIK these two are only used by xend so unless you are adding support for this stuff there (it's deprecated so no need) this isn't necessary, also I think xend reads the stdout of one or both and you've added to what gets printed, running the risk of breaking things.
Ian.
Re: [PATCH 3 of 3] VM generation ID save/restore and migrate
Quoted 33 lines · Paul Durrant
Quoted 33 lines
-----Original Message-----
From: Ian Campbell
Sent: 16 December 2011 12:08
To: Paul Durrant
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 3 of 3] VM generation ID save/restore and migrateQuoted 1 line · Paul Durrant
diff -r
d44e885e0389-re745cfbe7e11
tools/python/xen/lowlevel/checkpoint/libcheckpoint.cQuoted 1 line
---
a/tools/python/xen/lowlevel/checkpoint/libcheckpoint.cFri Dec 16 11:43:52 2011 +0000
Quoted 1 line
+++
b/tools/python/xen/lowlevel/checkpoint/libcheckpoint.cFri Dec 16 11:43:53 2011 +0000
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c int checkpoint_start(checkpoint_state* s { · line 180
Quoted 7 lines
tools/python/xen/lowlevel/checkpoint/libcheckpoint.c +1
-0@@ -175,6 +175,7 @@ int checkpoint_start(checkpoint_state* s {int hvm, rc;int flags =XCFLAGS_LIVE ; +unsigned long vm_generationid_addr;if (!s->domid) { s->errstr = "checkpoint state not opened"; @@ -185,16+186,28
Quoted 9 lines
@@ int checkpoint_start(checkpoint_state* s
hvm = s->domtype > dt_pv; if (hvm) {tools/python/xen/lowlevel/checkpoint/libcheckpoint.c +5
-0+char path[128 ]; +char *addr; + +sprintf (path, +"/local/domain/%u/hvmloader/generation-id-address" , s->domid);
Quoted 5 lines
Quoted 3 lines
xs_get_domain_path()gives you the correct base path (I saw at least one more of these).Does that save me anything?
Probably not much, other than avoiding hardcoding something. I guess /local/domain/%d is fair game in a toolstack.
Quoted 5 lines
I'd end up having to
sprintf(path, "%s/hvmloader/generation-id-address", xs_get_domain_path(s->xsh, s->domid))since
xs_read()just takes a path rather than a (prefix, node) couple.
xs_chdir() would actually be quite useful for this sort of thing, but it doesn't exist so nevermind.
Ian.
Quoted 23 lines
Paul
Quoted 19 lines
Quoted 2 lines
diff -r
d44e885e0389-re745cfbe7e11tools/xcutils/xc_restore.c
---a/tools/xcutils/xc_restore.cFri Dec 16 11:43:52 2011+0000
Quoted 1 line
+++
b/tools/xcutils/xc_restore.cFri Dec 16 11:43:53 2011+0000
[...]tools/xcutils/xc_save.c Fri Dec 16 11:43:53 2011 +0000
Quoted 3 lines
diff -r
d44e885e0389-re745cfbe7e11tools/xcutils/xc_save.ctools/xcutils/xc_save.c Fri Dec 16 11:43:53 2011 +0000 renamed from tools/xcutils/xc_save.c Fri Dec 16 11:43:52 2011 +0000 +0
-0[...]
AFAIK these two are only used by xend so unless you are adding support for this stuff there (it's deprecated so no need) this isn't necessary, also I think xend reads the stdout of one or both and you've added to what gets printed, running the risk of breaking things.
Ian.
Quoted 4 lines · Paul Durrant
This patch series adds support for preservation of the VM generation ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for migration.
Sorry for a stupid question, but what's the usecase for this 'generation ID' ?
-- Pasi
Quoted 13 lines
The first patch modifies creation of the hvmloader key in xenstore and adds creation of a new read/write hvmloader/generation-id-addr key.
The second patch changes hvmloader to use the new key (as opposed to the old data/generation-id key).
The third patch adds the infrastructure to save and restore the VM generation ID address in xenstore and the code to increment the value._______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 10 lines
-----Original Message-----
From: Pasi Kärkkäinen [mailto:[email protected]]
Sent: 16 December 2011 13:26
To: Paul Durrant
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID save/restore and migrateQuoted 1 line · Paul Durrant
This patch series adds support for preservation of the VM
Quoted 9 lines
generation
Quoted 2 lines
ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for
migration.
Quoted 1 line
Sorry for a stupid question, but what's the usecase for this 'generation ID' ?
Pasi,
I did mention this before on 1st December. Here's what I said then:
"I already know there is one OS that consumes this interface and another hypervisor that produces it but unfortunately I'm not at liberty to say much more because I'm under NDA. Hopefully a spec. will be forthcoming at some point."
That really is all I believe I'm at liberty to say :-(
Paul
Quoted 19 lines
-- Pasi
Quoted 1 line
The first patch modifies creation of the hvmloader key in xenstore
and
Quoted 1 line
adds creation of a new read/write hvmloader/generation-id-addr
key.
Quoted 1 line
The second patch changes hvmloader to use the new key (as opposed
to
Quoted 3 lines
the old data/generation-id key).
The third patch adds the infrastructure to save and restore the VM generation ID address in xenstore and the code to increment thevalue.
Quoted 7 lines
_______________________________________________
Xen-devel mailing list
[email protected]
http://lists.xensource.com/xen-devel
Quoted 22 lines · Paul Durrant
Quoted 10 lines
-----Original Message-----
From: Pasi Kärkkäinen [mailto:[email protected]]
Sent: 16 December 2011 13:26
To: Paul Durrant
Cc: [email protected]
Subject: Re: [Xen-devel] [PATCH 0 of 3] Support for VM generation ID save/restore and migrateQuoted 1 line · Paul Durrant
This patch series adds support for preservation of the VM
Quoted 9 lines
generation
Quoted 2 lines
ID buffer address in xenstore across save/restore and migrate, and also code to increment the value in all cases except for
migration.
Quoted 1 line
Sorry for a stupid question, but what's the usecase for this 'generation ID' ?
Pasi,
Quoted 9 lines
I did mention this before on 1st December. Here's what I said then:
"I already know there is one OS that consumes this interface and another hypervisor that produces it but unfortunately I'm not at liberty to say much more because I'm under NDA. Hopefully a spec. will be forthcoming at some point."
That really is all I believe I'm at liberty to say :-(
Oh, OK. I missed that comment..
Thanks for the info :)
-- Pasi