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.
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}.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home