Re: [Xen-devel] [RFC PATCH V3 1/2] xen: pass kernel initrd to qemu

["Chun Yan Liu" <cyliu@xxxxxxxx>]

>>> On 6/23/2014 at 10:22 PM, in message
<21416.14398.695327.278606@xxxxxxxxxxxxxxxxxxxxxxxx>, Ian Jackson
<Ian.Jackson@xxxxxxxxxxxxx> 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 
> Xen-devel@xxxxxxxxxxxxx 
> http://lists.xen.org/xen-devel 
>  
>  


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel