From: Wei Liu <liuw@liuw.name>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>
Subject: Re: [PATCH] libxl: enabling upstream qemu as pure pv backend.
Date: Wed, 08 Jun 2011 17:53:45 +0800 [thread overview]
Message-ID: <1307526825.31359.38.camel@limbo> (raw)
In-Reply-To: <1307523318.775.703.camel@zakaz.uk.xensource.com>
On Wed, 2011-06-08 at 09:55 +0100, Ian Campbell wrote:
> On Wed, 2011-06-08 at 04:19 +0100, Wei Liu wrote:
> > commit 02cf9f9cfdf720c636c6ba08f795e49b5eb1f03e
> > Author: Wei Liu <liuw@liuw.name>
> > 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@liuw.name>
> >
> > @@ -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?
>
Because we are reusing the dm_info passed by ancestor callers, which has
already been filled with useful contents.
> > + 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.
>
Ah, yes. The dmargs parsing can be pulled out.
But the WARNING statements parts are different, so I duplicate some
code. I will make it cleaner and resend.
> 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).
>
Haven't come across such use case yet. Does libxl supports specifying
two DMs for one domain? What's the syntax?
> I'm not sure what the best solution here is, we could obviously
> duplicate up all the options but that seems unpleasant.
>
Agreed.
> 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.
>
> 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}.
>
Well, we already have device_model_args_{old,new} which handle qemu-xen
and upstream qemu respectively. And the main goal of my patch is to
enable using upstream qemu as pv backend, so device_model_args_{pv,fv}
may not be sufficient -- we have two qemus for pv. The handling logic
will be complicated.
> Ian.
>
>
next prev parent reply other threads:[~2011-06-08 9:53 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-08 3:19 [PATCH] libxl: enabling upstream qemu as pure pv backend Wei Liu
2011-06-08 8:55 ` Ian Campbell
2011-06-08 9:53 ` Wei Liu [this message]
2011-06-08 12:23 ` Ian Campbell
2011-06-08 10:20 ` Wei Liu
2011-06-08 12:24 ` Ian Campbell
2011-06-08 11:09 ` Stefano Stabellini
2011-06-08 14:07 ` Konrad Rzeszutek Wilk
2011-06-08 11:33 ` Stefano Stabellini
2011-06-08 12:27 ` Ian Campbell
2011-06-08 13:00 ` Stefano Stabellini
2011-06-08 13:13 ` Ian Campbell
2011-06-08 13:43 ` Stefano Stabellini
2011-06-08 13:51 ` Ian Campbell
2011-06-08 15:51 ` Stefano Stabellini
2011-06-08 15:53 ` Ian Campbell
2011-06-08 16:09 ` Stefano Stabellini
2011-06-09 7:07 ` Wei Liu
2011-06-09 8:52 ` Ian Campbell
2011-06-09 9:49 ` Wei Liu
2011-06-09 10:15 ` Ian Campbell
2011-06-09 10:47 ` Wei Liu
2011-06-09 15:20 ` Stefano Stabellini
2011-06-09 15:49 ` Wei Liu
2011-06-09 16:00 ` Stefano Stabellini
2011-06-10 5:47 ` Wei Liu
2011-06-10 11:05 ` Stefano Stabellini
-- strict thread matches above, loose matches on Subject: below --
2011-07-16 6:06 Wei Liu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1307526825.31359.38.camel@limbo \
--to=liuw@liuw.name \
--cc=Ian.Campbell@citrix.com \
--cc=Stefano.Stabellini@eu.citrix.com \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).