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

[Andrei Borzenkov]

08.03.2016 19:37, Fu Wei пишет:
> Hi Andrei,
> 
> On 8 March 2016 at 14:54, Andrei Borzenkov <address@hidden> wrote:
>> 07.03.2016 11:22, Fu Wei пишет:
>>> Hi Andrei,
>>>
>>> On 28 February 2016 at 00:44, Fu Wei <address@hidden> wrote:
>>>> Hi Andrei
>>>>
>>>> On 28 February 2016 at 01:26, Andrei Borzenkov <address@hidden> wrote:
>>>>> 26.02.2016 14:13, address@hidden пишет:
>>>>>> From: Fu Wei <address@hidden>
>>>>>>
>>>>>> delete: xen_linux, xen_initrd, xen_xsm
>>>>>> add: xen_module
>>>>>>
>>>>>> This update bases on
>>>>>>     commit 0edd750e50698854068358ea53528100a9192902
>>>>>>     Author: Vladimir Serbinenko <address@hidden>
>>>>>>     Date:   Fri Jan 22 10:18:47 2016 +0100
>>>>>>
>>>>>>         xen_boot: Remove obsolete module type distinctions.
>>>>>>
>>>>>> Signed-off-by: Fu Wei <address@hidden>
>>>>>> ---
>>>>>>  docs/grub.texi | 33 ++++++++++-----------------------
>>>>>>  1 file changed, 10 insertions(+), 23 deletions(-)
>>>>>>
>>>>>> diff --git a/docs/grub.texi b/docs/grub.texi
>>>>>> index 82f6fa4..3fbdd99 100644
>>>>>> --- a/docs/grub.texi
>>>>>> +++ b/docs/grub.texi
>>>>>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command 
>>>>>> @command{help}
>>>>>>  * videoinfo::                   List available video modes
>>>>>>  @comment * xen_*::              Xen boot commands
>>>>>>  * xen_hypervisor::              Load xen hypervisor binary
>>>>>> -* xen_linux::                   Load dom0 kernel for xen hypervisor
>>>>>> -* xen_initrd::                  Load dom0 initrd for dom0 kernel
>>>>>> -* xen_xsm::                     Load xen security module for xen 
>>>>>> hypervisor
>>>>>> +* xen_module::                  Load xen modules for xen hypervisor
>>>>>>  @end menu
>>>>>>
>>>>>>
>>>>>> @@ -5141,30 +5139,19 @@ verbatim as the @dfn{kernel command-line}. Any 
>>>>>> other binaries must be
>>>>>>  reloaded after using this command.
>>>>>>  @end deffn
>>>>>>
>>>>>> address@hidden xen_linux
>>>>>> address@hidden xen_linux
>>>>>> address@hidden xen_module
>>>>>> address@hidden xen_module
>>>>>>
>>>>>> address@hidden Command xen_linux file [arguments]
>>>>>> -Load a dom0 kernel image for xen hypervisor at the booting process of 
>>>>>> xen.
>>>>>> address@hidden 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.
>>>>>
>>>>> ==
>>>>>> +On i386,  the modules will be identified by Multiboot(2) protocol.
>>>>>> +On arm64, each module will be identified by the order in which the
>>>>>> +modules are added.
>>>>>
>>>>> I think it is better to skip it entirely. It is not really correct -
>>>>> neither multiboot protocol provides any module identification (Xen
>>>>> probes module types), nor is i386 using multiboot2, nor can all modules
>>>>> be probed, so order still matters. To avoid confusion I'd simply
>>>>> replaced the above three lines with
>>>>>
>>>>> Modules should be loaded in the following order:
>>>>>
>>>>>> +The 1st module: dom0 kernel image
>>>>>> +The 2nd module: dom0 ramdisk (optional)
>>>>>
>>>>> This covers both supported platforms without going into too deep
>>>>> details; if you and Vladimir are OK, I'll commit with this change.
>>>>
>>>> Thank you very much!
>>>> Sorry I am not familiar with xen on i386, so maybe I misunderstand this.
>>>> So please commit with your change, Thanks for your correction :-)
>>>
>>> I just fetched the mainline GRUB, i would like to know why this
>>> patchset haven't been applied?
>>> Anything I need to do(improve it or post a new patchset according to
>>> your suggestion) for this patchset?
>>>
>>
>> Sorry for delay. It is not really about your patchset, but we need some
>> decision about loading additional modules/lack of initrd on ARM. Until
>> then I'd rather avoid committing to any high-level configuration support
>> that will require even more backward compatible hacks later.
>>
>> As it stands now either Xen needs to support autodetection or we need to
>> revert to providing module type explicitly.
> 
> So speaking of loading additional modules/lack of initrd on ARM, I thinks that
> will (only) affect loading XSM.
> For this, I have discussed of that with Julien, I think :
> (1) the first module must be kernel
> (2) the second module must be initrd, if we have initrd
> (3) Start from the 2nd module, XEN will detect that if the module is a XSM by
> the XSM binary signature. if we get XSM as the second module, that
> means we have not initrd.
> 

If that's the plan, excellent. Vladimir, is it OK to commit then?

> please correct me if I misunderstand it
> 
> :-)
>