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

[Andrei Borzenkov]

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 <address@hidden> wrote:
>>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <address@hidden> wrote:
>>>>>>>> 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.
>>>>>>>> +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
module after that is assumed to be initrd (dom0 kernel always must be
the very first module provided).

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?
>