Re: [Xen-devel] [RFC PATCH 04/17] libxl: Build the domain with a Linux based stubdomain

[Jason Andryuk <jandryuk@xxxxxxxxx>]

On Mon, Jul 30, 2018 at 11:56 PM, Marek Marczykowski-Górecki
<marmarek@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> From: Eric Shelton <eshelton@xxxxxxxxx>
>
> This will build a Linux-based stubdomain with QEMU upstream.
>
> Signed-off-by: Eric Shelton <eshelton@xxxxxxxxx>
>
> Simon:
>  * use initramfs instead of disk with rootfs
>  * don't initialize qmp (unused in Qubes)
>  * Make libxl_domain_need_memory consistent with actual stubdoma build
>    code (bugfix relevant also for non-linux case)
>  * Make stubdomain memory size configurable
> Signed-off-by: Simon Gaiser <simon@xxxxxxxxxxxxxxxxxxxxxx>
>
> Marek:
>  * Make kernel and ramdisk paths configurable.
> Signed-off-by: Marek Marczykowski-Górecki <marmarek@xxxxxxxxxxxxxxxxxxxxxx>
> ---

<snip>

> @@ -1983,10 +1997,8 @@ void libxl__spawn_stub_dm(libxl__egc *egc, 
> libxl__stub_dm_spawn_state *sdss)
>          dm_config->num_vkbs = 1;
>      }
>
> -    stubdom_state->pv_kernel.path
> -        = libxl__abs_path(gc, "ioemu-stubdom.gz", 
> libxl__xenfirmwaredir_path());
> -    stubdom_state->pv_cmdline = GCSPRINTF(" -d %d", guest_domid);

This dropped line isn't restored anywhere else, afaics.  Does this
break mini-os stubdoms?

> -    stubdom_state->pv_ramdisk.path = "";
> +    stubdom_state->pv_kernel.path = guest_config->b_info.stubdomain_kernel;
> +    stubdom_state->pv_ramdisk.path = guest_config->b_info.stubdomain_ramdisk;
>
>      /* fixme: this function can leak the stubdom if it fails */
>      ret = libxl__domain_make(gc, dm_config, stubdom_state,

Regards,
Jason

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel