[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] Add code to track the address of the VM generation id buffer across a
On Wed, 2011-11-30 at 20:58 +0000, Paul Durrant wrote: > diff -r 3c4c29899d8a -r 94a17182f386 > tools/libxc/ia64/xc_ia64_linux_restore.c > --- a/tools/libxc/ia64/xc_ia64_linux_restore.c Wed Nov 30 07:18:11 > 2011 -0800 > +++ b/tools/libxc/ia64/xc_ia64_linux_restore.c Wed Nov 30 20:51:07 > 2011 +0000 > @@ -548,7 +548,8 @@ 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, > + uint64_t gid) This is a uint64_t * in the non-ia64 case. is that right? > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_internal.h > --- a/tools/libxl/libxl_internal.h Wed Nov 30 07:18:11 2011 -0800 > +++ b/tools/libxl/libxl_internal.h Wed Nov 30 20:51:07 2011 +0000 > @@ -199,6 +199,8 @@ typedef struct { > > uint32_t console_port; > unsigned long console_mfn; > + > + unsigned long vm_gid_addr; Is this large enough for a 64 bit guest even with 32 bit tools? > } libxl__domain_build_state; > > _hidden int libxl__build_pre(libxl__gc *gc, uint32_t domid, > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/libxl_types.idl > --- a/tools/libxl/libxl_types.idl Wed Nov 30 07:18:11 2011 -0800 > +++ b/tools/libxl/libxl_types.idl Wed Nov 30 20:51:07 2011 +0000 > @@ -183,6 +183,7 @@ libxl_domain_build_info = Struct("domain > ("vpt_align", bool), > ("timer_mode", integer), > ("nested_hvm", bool), > + ("generation_id", uint64), > ])), > ("pv", Struct(None, [("kernel", libxl_file_reference), > ("slack_memkb", uint32), > diff -r 3c4c29899d8a -r 94a17182f386 tools/libxl/xl_cmdimpl.c > --- a/tools/libxl/xl_cmdimpl.c Wed Nov 30 07:18:11 2011 -0800 > +++ b/tools/libxl/xl_cmdimpl.c Wed Nov 30 20:51:07 2011 +0000 > @@ -573,6 +573,7 @@ static void parse_config_data(const char > { > const char *buf; > long l; > + long long ll; > XLU_Config *config; > XLU_ConfigList *vbds, *nics, *pcis, *cvfbs, *cpuids; > int pci_power_mgmt = 0; > @@ -764,6 +765,8 @@ static void parse_config_data(const char > b_info->u.hvm.timer_mode = l; > if (!xlu_cfg_get_long (config, "nestedhvm", &l, 0)) > b_info->u.hvm.nested_hvm = l; > + if (!xlu_cfg_get_long_long (config, "generation_id", &ll, 0)) > + b_info->u.hvm.nested_hvm = ll; Are you you tested this? Also please patch docs/man/xl.cfg.pod.5 with a description of this new key. > diff -r 3c4c29899d8a -r 94a17182f386 tools/xcutils/xc_restore.c > --- a/tools/xcutils/xc_restore.c Wed Nov 30 07:18:11 2011 -0800 > +++ b/tools/xcutils/xc_restore.c Wed Nov 30 20:51:07 2011 +0000 > @@ -23,7 +23,8 @@ 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_gid_addr; > + uint64_t gid; > > if ( (argc != 8) && (argc != 9) ) > errx(1, "usage: %s iofd domid store_evtchn " > @@ -40,19 +41,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 ) > + gid = strtoll(argv[9], NULL, 0); > + else > + gid = 0; I don't think you need to do anything more complex than pass vm_gid_addr as NULL here unless you are also going to patch xend. I didn't see anywhere which cranked the value on restore, it seems to just propagate the value from the cfg file. Is that actually useful? Does the user really need to be able to specify the initial value? Would it not be easier to just generate a new value somehow when creating the domain? No ones going to edit their cfg each time they start the vm. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |