[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu
From: |
Ian Jackson |
Subject: |
Re: [Qemu-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu |
Date: |
Mon, 23 Jun 2014 15:22:54 +0100 |
Chunyan Liu writes ("[RFC PATCH V3 1/2] xen: pass kernel initrd to qemu"):
> xen side patch to support xen HVM direct kernel boot:
> support 'kernel', 'ramdisk', 'cmdline' (and 'root', 'extra' as well
> which would be deprecated later) in HVM config file, parse config file,
> pass -kernel, -initrd, -append parameters to qemu.
...
> +Currently, direct kernel boot can be supported by PV guests, and HVM guests
> +with limitations. For HVM guests, in case of stubdom-dm and old rombios,
> +direct kernel boot is not supported.
What does "PV guests" mean here ? Do you mean guest kernels which
support the Xen PV environment ?
If so, what is the benefit of booting them "direct" but HVM, rather
than simply booting them PV ?
> =item B<bootloader="PROGRAM">
>
> Run C<PROGRAM> to find the kernel image and ramdisk to use. Normally
> C<PROGRAM> would be C<pygrub>, which is an emulation of
> -grub/grub2/syslinux.
> +grub/grub2/syslinux. Either B<kernel> or B<bootloader> must be specified
> +for PV guests.
Surely using this should be possible for direct kernel boot too.
> +/*
> + * LIBXL_HAVE_BUILDINFO_HVM_DIRECT_KERNEL_BOOT
> + *
> + * If this is defined, then the libxl_domain_build_info structure will
> + * contain hvm.kernel, hvm.cmdline and hvm.ramdisk. hvm.kernel is a string
> + * to indicate kernel image location, hvm.ramdisk is a string to indicate
> + * ramdisk location, hvm.cmdline is a string to indicate the paramters which
> + * would be appened to kernel image.
If we are going to do this then I think the kernel, cmdline and
ramdisk (and bootloader) parameters shoudl be moved into the main part
of the domain_build_info struct. This will involve a compatibility
layer: temporarily (for at least one release) both will be supported
so the IDL will have to have both and code inside libxl will have to
honour either.
The #define should then be
LIBXL_HAVE_BUILD_INFO_CMDLINE
or some such - because all libxl callers will want to update to the
new API eventually.
> +static char *parse_cmdline(XLU_Config *config)
> +{
> + char *cmdline = NULL;
> + const char *root = NULL, *extra = NULL, *buf = NULL;
> +
> + xlu_cfg_get_string (config, "cmdline", &buf, 0);
> + xlu_cfg_get_string (config, "root", &root, 0);
> + xlu_cfg_get_string (config, "extra", &extra, 0);
> +
> + if (buf) {
> + cmdline = strdup(buf);
> + if (root || extra)
> + fprintf(stderr, "Warning: ignoring deprecated root= and extra= "
> + "in favour of cmdline=\n");
Why are you deprecating root= and extra= ?
They seem likely to be a useful distinction if we decide to add
further default options in the future.
If you do want to deprecate them, you should make this very clear -
probably by putting that change in a separate patch in your series.
Thanks,
Ian.