[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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.