[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
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@xxxxxxxxx> wrote: >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@xxxxxxxxxx> 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 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? > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |