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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Wed, 8 Jun 2011, Ian Campbell wrote:
> On Wed, 2011-06-08 at 04:19 +0100, Wei Liu wrote:
> > commit 02cf9f9cfdf720c636c6ba08f795e49b5eb1f03e
> > 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.
> >     
> >     Signed-off-by: Wei Liu <liuw@xxxxxxxxx>
> > 
> > @@ -909,8 +909,8 @@ static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
> >                                          libxl_device_model_info *info)
> >  {
> >      libxl_ctx *ctx = libxl__gc_owner(gc);
> > -    memset(info, 0x00, sizeof(libxl_device_model_info));
> 
> Why do you remove this memset?
> 
> > +    info->vnc = 0;
> >      if (vfb != NULL) {
> >          info->vnc = vfb->vnc;
> >          if (vfb->vnclisten)
> > @@ -927,9 +927,12 @@ static int libxl__build_xenpv_qemu_args(libxl__gc *gc,
> >          info->nographic = 1;
> >      info->domid = domid;
> >      info->dom_name = libxl_domid_to_name(ctx, domid);
> > -    info->device_model_version = 
> > LIBXL_DEVICE_MODEL_VERSION_QEMU_XEN_TRADITIONAL;
> > -    info->device_model = NULL;
> > -    info->type = LIBXL_DOMAIN_TYPE_PV;
> > +    info->target_ram = 0;
> > +    info->videoram = 0;
> > +    info->acpi = 0;
> > +    info->vcpus = 0;
> > +    info->vcpu_avail = 0;
> > +    info->xen_platform_pci = 0;
> >      return 0;
> >  }
> > diff --git a/tools/libxl/xl_cmdimpl.c b/tools/libxl/xl_cmdimpl.c
> > index 5415bc5..74a77a7 100644
> > --- a/tools/libxl/xl_cmdimpl.c
> > +++ b/tools/libxl/xl_cmdimpl.c
> > @@ -626,6 +626,8 @@ static void parse_config_data(const char 
> > *configfile_filename_report,
> >      int pci_power_mgmt = 0;
> >      int pci_msitranslate = 1;
> >      int e;
> > +    XLU_ConfigList *dmargs;
> > +    int nr_dmargs = 0;
> >  
> >      libxl_domain_create_info *c_info = &d_config->c_info;
> >      libxl_domain_build_info *b_info = &d_config->b_info;
> > @@ -1075,14 +1077,10 @@ skip_vfb:
> >          break;
> >      }
> >  
> > -    if (c_info->hvm == 1) {
> > -        XLU_ConfigList *dmargs;
> > -        int nr_dmargs = 0;
> > -
> > -        /* init dm from c and b */
> > -        libxl_init_dm_info(dm_info, c_info, b_info);
> > +    /* init dm from c and b */
> > +    libxl_init_dm_info(dm_info, c_info, b_info);
> >  
> > -        /* then process config related to dm */
> > +    if (c_info->hvm == 1) {
> >          if (!xlu_cfg_get_string (config, "device_model", &buf)) {
> >              fprintf(stderr,
> >                      "WARNING: ignoring device_model directive.\n"
> > @@ -1147,6 +1145,42 @@ skip_vfb:
> >                  dm_info->extra[i] = a ? strdup(a) : NULL;
> >              }
> >          }
> > +    } else {
> > +        if (!xlu_cfg_get_string (config, "device_model", &buf)) {
> > +            fprintf(stderr,
> > +                    "WARNING: ignoring device_model directive.\n"
> > +                    "WARNING: Use \"device_model_override\" instead if you 
> > really want a non-default device_model\n");
> > +        }
> [...]
> > +        if (!xlu_cfg_get_list(config, "device_model_args", &dmargs, 
> > &nr_dmargs, 0))
> > +        {
> > +            int i;
> > +            dm_info->extra = xmalloc(sizeof(char *) * (nr_dmargs + 1));
> > +            dm_info->extra[nr_dmargs] = NULL;
> > +            for (i=0; i<nr_dmargs; i++) {
> > +                const char *a = xlu_cfg_get_listitem(dmargs, i);
> > +                dm_info->extra[i] = a ? strdup(a) : NULL;
> > +            }
> > +        }
> 
> There is no need to duplicate all this code, is there?
> 
> Just pull the relevant stuff from above out of the c_info->hvm == 1
> case.
> 
> One general concern I have is there are cases where we want 2 DM
> instances. In particular we can have an FV instance running in a stub
> domain which uses a PV instance running in dom0 for certain
> functionality (e.g. emulated VGA in the FV stub domain qemu goes to an
> xenfb frontend talking to a xenfb backend running in a PV qemu in domain
> 0).
> 
> I'm not sure what the best solution here is, we could obviously
> duplicate up all the options but that seems unpleasant.
> 
> I guess for the most part we should treat both qemu's in this case as
> the same logical entity split into two brains, so most of the options
> are common to both (and e.g. the versions are matched etc) with libxl
> taking care of directing the individual options to the right instance
> (or both). Yeah, that sounds like the answer.

Yes, if the user chooses new qemu for simplicity's sake libxl should use
new qemu for everything.


> Only exception is the device_model_args option where I can see that
> passing different extra args to each instance would be useful and it is
> unlikely that libxl will understand them enough to choose where to send
> them, in fact we probably want 3 varialbe, device_model_args and
> device_model_args_{pv,fv}.
 
Yes, that would be the best solution.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel