[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
08.03.2016 19:37, Fu Wei пишет: > Hi Andrei, > > On 8 March 2016 at 14:54, Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote: >> 07.03.2016 11:22, Fu Wei пишет: >>> Hi Andrei, >>> >>> On 28 February 2016 at 00:44, Fu Wei <fu.wei@xxxxxxxxxx> wrote: >>>> Hi Andrei >>>> >>>> On 28 February 2016 at 01:26, Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote: >>>>> 26.02.2016 14:13, fu.wei@xxxxxxxxxx пишет: >>>>>> From: Fu Wei <fu.wei@xxxxxxxxxx> >>>>>> >>>>>> delete: xen_linux, xen_initrd, xen_xsm >>>>>> add: xen_module >>>>>> >>>>>> This update bases on >>>>>> commit 0edd750e50698854068358ea53528100a9192902 >>>>>> Author: Vladimir Serbinenko <phcoder@xxxxxxxxx> >>>>>> Date: Fri Jan 22 10:18:47 2016 +0100 >>>>>> >>>>>> xen_boot: Remove obsolete module type distinctions. >>>>>> >>>>>> Signed-off-by: Fu Wei <fu.wei@xxxxxxxxxx> >>>>>> --- >>>>>> 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 >>>>>> >>>>>> -@node xen_linux >>>>>> -@subsection xen_linux >>>>>> +@node xen_module >>>>>> +@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. >>>>> >>>>> == >>>>>> +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 > > :-) > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |