[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd
From: |
Chun Yan Liu |
Subject: |
Re: [Qemu-devel] [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu |
Date: |
Mon, 23 Jun 2014 21:24:03 -0600 |
>>> On 6/23/2014 at 10:22 PM, in message
<address@hidden>, Ian Jackson
<address@hidden> wrote:
> 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 ?
Yes. I mean Paravirtualized Guest.
Since before this patch these options are supported by PV guest only (to do
direct kernel boot), now HVM guest also supports them, so I move them to the
general options. What I want to say here is:
PV guests can support direct kernel boot (as always), now HVM guests can
support direct kernel boot too but with limitations (qemu-xen with default
seabios).
>
> 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.
I see.
>
> 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= ?
Just following Ian Campbell's suggestion:
http://lists.gnu.org/archive/html/qemu-devel/2014-06/msg02909.html
Now, cmdline is actually 'root' plus 'extra', if there is no special future
usage,
one 'cmdline' seems to be better.
>
> They seem likely to be a useful distinction if we decide to add
> further default options in the future.
Don't know how they will be used. But it we do need them, sure we can keep
the current way.
Thanks,
Chunyan
>
> 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.
>
> _______________________________________________
> Xen-devel mailing list
> address@hidden
> http://lists.xen.org/xen-devel
>
>