Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Sun, Feb 28, 2016 at 08:10:33AM +0300, Andrei Borzenkov wrote:
> 27.02.2016 23:33, Konrad Rzeszutek Wilk пишет:
> > On Fri, Feb 26, 2016 at 07:15:52PM +0800, Fu Wei wrote:
> >> Hi Andrei,
> >>
> >> On 26 February 2016 at 18:50, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
> >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> wrote:
> >>>>>>>> +@subsection xen_module
> >>>>>>>>
> >>>>>>>> -@deffn Command xen_linux file [arguments]
> >>>>>>>> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
> >>>>>>>> +@deffn Command xen_module [--nounzip] file [arguments]
> >>>>>>>> +Load a module for xen hypervisor at the booting process of xen.
> >>>>>>>> The rest of the line is passed verbatim as the module command line.
> >>>>>>>> +Each module will be identified by the order in which the modules are added.
> >>>>>>>> +The 1st module: dom0 kernel image
> >>>>>>>> +The 2nd module: dom0 ramdisk
> >>>>>>>> +All subsequent modules: UNKNOW
> >>>>>>>> @end deffn
> >>>>>>>
> >>>>>>> Hmm ... from previous discussion I gathered that Xen can detect module
> >>>>>>> type. What if there is no initrd for dom0? How can subsequent modules be
> >>>>>>
> >>>>>> Now , Xen detect module type by the order. (at least on ARM64).
> >>>>>> I think i386 is using Multiboot(2) protocol, so maybe this order is
> >>>>>> nothing to do with i386.
> >>>>>>
> >>>>>
> >>>>> Then we have obvious problem with your XSM patch (http://savannah.gnu.org/bugs/?43420) - XSM may land as the first module. That's actually something to solve on Xen side I think. It's just that so far we had just kernel and initrd, so that was non issue.
> >>>>
> >>>> Oh, did you mean Wei Liu's patch?
> >>>>
> >>>> I guess XSM may land as the third module (or the module after linux
> >>>> kernel, if you don't have initrd)
> >>>>
> >>>> Yes, agree. (That's actually something to solve on Xen side)
> >>>>
> >>>> I guess xen can get xsm from a special initrd. so for now there is not
> >>>> big problem on xsm.
> >>>>
> >>>> Please correct me if I misunderstand something. :-)
> >>>>
> >>>> Thanks!
> >>>>
> >>>> Back to this patch, is that OK for you, or any suggestion?  Thanks !
> >>>>
> >>>
> >>> Yes, as this is dedicated Xen loader we should document this mandatory
> >>> order - first module must be kernel image, second module must be
> >>> initrd. I do not think we need to mention possibility to load more
> >>> than two modules until there is clear understanding how it can be done
> >>> without initrd.
> >>
> >> Great thanks for your review, I have updated and sent the v3 patchset,
> >> Hope I understood your suggestion correctly, Please check.  :-)
> > 
> > What if the initrd is catted to the kernel image (which you can
> > do on x86)? And then the 1st module is your XSM?
> > 
> 
> On x86 Xen can detect microcode and xsm modules; the first unknown

'can'. If you use 'ucode=scan' on the Xen command line. Otherwise it has
no clue.

It actually would be just much nicer if Multiboot2 had some tag describing
this and Xen (or any other OS) could just parse it like that. But that is
just hand-waving, nice-to-do.


> module after that is assumed to be initrd (dom0 kernel always must be
> the very first module provided).

That is true.
> 
> On arm there is no detection - module type is taken from FDT; if no
> module type is provided, the first unknown module is assumed to be
> kernel, the second - initrd.
> 
> See also http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00333.html
> 
> > Is this .. order dependency written somewhere in a document? In the
> > Xen code-base that is?
> > 
> 

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