[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] Re: [PATCH] libxl: enabling upstream qemu as pure pv backend.



On Thu, 2011-06-09 at 16:20 +0100, Stefano Stabellini wrote:
> On Thu, 9 Jun 2011, Wei Liu wrote:
> > The dm creating logic is as followed:
> > 
> > if hvm
> >   libxl__create_device_model
> >     if stubdom
> >       libxl__create_stubdom -> libxl__create_xenpv_qemu
> >                                 |
> >                                 --> libxl__create_device_model
> >     else
> >       spawn and exec qemu
> > else /* pv */
> >   if need_qemu
> >     libxl__create_xenpv_qemu
> >      |
> >      --> libxl__create_device_model
> > 
> > *
> > I think adding device_model_args_{pv,fv} is a good idea.
> > 
> > *
> > Since libxl__create_stubdom receives a dm_info structure, I think it is
> > ok for libxl__create_xenpv_qemu to receive one, too. This dm_info is key
> > structure to indicate xenpv qemu's type (traditional or upstream). But
> > once we enter libxl__create_xenpv_qemu, we lost knowledge of whether we
> > are creating a stubdom/qemu-xen or upstream qemu. So the caller should
> > be responsible for filling in a new dm_info for
> > libxl__create_xenpv_qemu.
> 
> Agreed.
> 
> 
> > *
> > vfb is derive from d_config (libxl_domain_config), which is a domain
> > property. Currently, the existing code either use
> > libxl__vfb_and_vkb_from_device_model_info (if we are using stubdom) or
> > direct parsing (if we are using xenpv_qemu). Though the code is
> > redundent, the parsing is just the same essentially. What's the point of
> > moving vnc and sdl out of vfb?
> 
> I don't feel strongly about it so you can leave it out this patch.
> However if we removed the sdl and vnc settings from vfb and used the
> same fields in device_model_info instead, we wouldn't need to "convert"
> the vfb settings into device_model settings anymore
> (libxl__build_xenpv_qemu_args would go away).
> 
> 
> > *
> > Configure two DMs for one domain? Haven't thought about that. I doubt
> > that if it really necessary if we are moving towards a unified DM --
> > upstream qemu -- wouldn't that be sufficient in the long run?
> > 
> > *
> > To my understanding, stubdom is minios+qemu-xen. If I (the user) am
> > using stubdom and specify device model args, these args should go to
> > xenpv qemu, not xenfv in stubdom, right? What I see in the code is that
> > we only need a few args (e.g. disks, vifs) to start stubdom. The
> > internal setup to connect to domU is done within stubdom.
> > 
> > To summarize, I give a second prototype of my patch. Please review.
> > 
> > libxl__build_xenpv_qemu_args handles common options to both xenpv qemu
> > and upstream qemu, while libxl__build_device_model_args distinguish
> > between old and new qemu's and build args respectively.
> > 
> > libxl__create_xenpv_qemu is not allocating a struct
> > libxl_device_model_info anymore, because at this point, it doesn't know
> > if it is building a stubdom/qemu-xen (traditional type) or upstream
> > qemu. The allocating and filling becomes caller's responsibility.
> > 
> > This patch has been tested with pv guest creating, fv guest creating and
> > fv-stubdom guest creating.
> > 
> > -----------8<------------------
> > 
> > commit e7ca429c34bd1f306f0819d447456dbe48e53e6e
> > Author: Wei Liu <liuw@xxxxxxxxx>
> > Date:   Wed Jun 8 11:13:25 2011 +0800
> > 
> >     libxl: enabling upstream qemu as pure pv backend.
> > 
> >     This patch makes device_model_{version,override} work for pure pv
> >     guest, so that users can specify upstream qemu as pure pv backend
> >     other than traditional qemu-xen.
> > 
> >     This patch also add device_model_args_{pv,fv} options for pv and
> >     fv guest respectively.
> > 
> >     Internally, original libxl__create_xenpv_qemu allocates a new empty
> >     dm_info (struct libxl_device_model_info) for every xenpv qemu created.
> >     Now the caller of libxl__create_xenpv_qemu is responsible for
> >     allocating this dm_info.
> > 
> >     Signed-off-by: Wei Liu <liuw@xxxxxxxxx>
> > 
> > diff --git a/tools/libxl/libxl_create.c b/tools/libxl/libxl_create.c
> > index 62294b2..92550bb 100644
> > --- a/tools/libxl/libxl_create.c
> > +++ b/tools/libxl/libxl_create.c
> > @@ -486,6 +486,7 @@ static int do_domain_create(libxl__gc *gc, 
> > libxl_domain_config *d_config,
> >      } else {
> >          int need_qemu = 0;
> >          libxl_device_console console;
> > +        libxl_device_model_info xenpv_dm_info;
> > 
> >          for (i = 0; i < d_config->num_vfbs; i++) {
> >              libxl_device_vfb_add(ctx, domid, &d_config->vfbs[i]);
> > @@ -506,8 +507,15 @@ static int do_domain_create(libxl__gc *gc, 
> > libxl_domain_config *d_config,
> >          libxl__device_console_add(gc, domid, &console, &state);
> >          libxl_device_console_destroy(&console);
> > 
> > +        /* only copy those useful configs */
> > +        memset((void*)&xenpv_dm_info, 0x00, 
> > sizeof(libxl_device_model_info));
> > +        xenpv_dm_info.device_model_version =
> > +            d_config->dm_info.device_model_version;
> > +        xenpv_dm_info.type = d_config->dm_info.type;
> > +        xenpv_dm_info.device_model = d_config->dm_info.device_model;
> >          if (need_qemu)
> > -            libxl__create_xenpv_qemu(gc, domid, d_config->vfbs, 
> > &dm_starting);
> > +            libxl__create_xenpv_qemu(gc, domid, &xenpv_dm_info,
> > +                                     d_config->vfbs, &dm_starting);
> >      }
> > 
> >      if (dm_starting) {
> > diff --git a/tools/libxl/libxl_dm.c b/tools/libxl/libxl_dm.c
> > index 47a51c8..473e3e4 100644
> > --- a/tools/libxl/libxl_dm.c
> > +++ b/tools/libxl/libxl_dm.c
> > @@ -207,9 +207,13 @@ static char ** 
> > libxl__build_device_model_args_old(libxl__gc *gc,
> >      switch (info->type) {
> >      case LIBXL_DOMAIN_TYPE_PV:
> >          flexarray_append(dm_args, "xenpv");
> > +        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
> > +            flexarray_append(dm_args, info->extra_pv[i]);
> >          break;
> >      case LIBXL_DOMAIN_TYPE_FV:
> >          flexarray_append(dm_args, "xenfv");
> > +        for (i = 0; info->extra_fv && info->extra_fv[i] != NULL; i++)
> > +            flexarray_append(dm_args, info->extra_fv[i]);
> >          break;
> >      }
> >      flexarray_append(dm_args, NULL);
> > @@ -364,9 +368,13 @@ static char ** 
> > libxl__build_device_model_args_new(libxl__gc *gc,
> >      switch (info->type) {
> >      case LIBXL_DOMAIN_TYPE_PV:
> >          flexarray_append(dm_args, "xenpv");
> > +        for (i = 0; info->extra_pv && info->extra_pv[i] != NULL; i++)
> > +            flexarray_append(dm_args, info->extra_pv[i]);
> >          break;
> >      case LIBXL_DOMAIN_TYPE_FV:
> >          flexarray_append(dm_args, "xenfv");
> > +        for (i = 0; info->extra_fv && info->extra_fv[i] != NULL; i++)
> > +            flexarray_append(dm_args, info->extra_fv[i]);
> >          break;
> >      }
> > 
> > @@ -575,6 +583,7 @@ static int libxl__create_stubdom(libxl__gc *gc,
> >      struct xs_permissions perm[2];
> >      xs_transaction_t t;
> >      libxl__device_model_starting *dm_starting = 0;
> > +    libxl_device_model_info xenpv_dm_info;
> > 
> >      if (info->device_model_version != 
> > LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL) {
> >          ret = ERROR_INVAL;
> > @@ -608,6 +617,7 @@ static int libxl__create_stubdom(libxl__gc *gc,
> > 
> >      /* fixme: this function can leak the stubdom if it fails */
> > 
> > +    domid = 0;
> >      ret = libxl__domain_make(gc, &c_info, &domid);
> >      if (ret)
> >          goto out_free;
> > @@ -702,7 +712,15 @@ retry_transaction:
> >          if (ret)
> >              goto out_free;
> >      }
> > -    if (libxl__create_xenpv_qemu(gc, domid, vfb, &dm_starting) < 0) {
> > +
> > +    memset((void*)&xenpv_dm_info, 0x00, sizeof(libxl_device_model_info));
> > +    xenpv_dm_info.device_model_version =
> > +        LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
> > +    xenpv_dm_info.type = LIBXL_DOMAIN_TYPE_PV;
> > +    xenpv_dm_info.device_model = NULL;
> > +    if (libxl__create_xenpv_qemu(gc, domid,
> > +                                 &xenpv_dm_info,
> > +                                 vfb, &dm_starting) < 0) {
> >          ret = ERROR_FAIL;
> >          goto out_free;
> >      }
> 
> You should set device_model_version, type and device_model from the same
> fields in info, so that the device model version running in the stubdom
> is the same as the one running in dom0.
> We don't want to mismatch the two of them.
> 

I re-check this part and find that the xenpv_dm_info.type is necessary
to be hardcoded.

Things are a bit different in stubdom creation compared to pv creation.
In pv creation, copying is ok, because there is only one qemu we need to
pay attention to.

In fv with stubdom case. There are two qemu's.

xenpv qemu <--> stubdom (pv) with xenfv qemu <--> hvm domU

That's the relationship between them.

To my understanding, the `type` field in dm_info represents which type
of domain the qemu is supporting.

The original device model info (which is the `info` passed in
libxl__create_stubdom) is filled with user config. It represents user's
domU DM config, which has type LIBXL_DOMAIN_TYPE_FV (supports a fv
domain), while the xenpv supporting stubdom is expecting type
LIBXL_DOMAIN_TYPE_PV (stubdom is pv).

If I directly copy this field from info, libxl__create_xenpv_qemu (which
calls general creating function libxl__create_device_model) will create
a FV stubdom.

And the qemu running in stubdom is hardcoded with '-M xenfv' option in
libxl_dm.c:libxl__write_dmargs. So I think hardcode `type` is
acceptable.

To summarize:
these two qemu's are by design of two different types.
copying device_model_version and device_model fields is ok. 

> Apart from Ian's comments, the rest is fine.



_______________________________________________
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®.