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

[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.

please correct me if I misunderstand it

:-)

-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021