From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1aZARC-0003T5-Dv for mharc-grub-devel@gnu.org; Thu, 25 Feb 2016 23:55:34 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51845) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZARA-0003Sz-Kz for grub-devel@gnu.org; Thu, 25 Feb 2016 23:55:33 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aZAR9-0006eg-8C for grub-devel@gnu.org; Thu, 25 Feb 2016 23:55:32 -0500 Received: from mail-ob0-x22e.google.com ([2607:f8b0:4003:c01::22e]:35439) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aZAR8-0006eZ-Lv for grub-devel@gnu.org; Thu, 25 Feb 2016 23:55:31 -0500 Received: by mail-ob0-x22e.google.com with SMTP id dm2so68395593obb.2 for ; Thu, 25 Feb 2016 20:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=YllksGv5CgoL7xRX/fgCZd3WOTYUmrbuJW21zOh1wH0=; b=LlG3cAF2LneWQYxCes2G+OX7GR+ovB1XJ871PAjnf+eKY5t7XnzMXXUldA5BR8g9T0 2QC8C4fU3luJUjUomERR9pPMnT3Yx8aTIvNlC1O/7102pdmsYDJzaEU4IwEmSlGlk3v3 kit8lPDVgdsUHJKA3441KAsnnmhwOK+MdnxLE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YllksGv5CgoL7xRX/fgCZd3WOTYUmrbuJW21zOh1wH0=; b=REwOkw72zYm+kD5tEv0+aqJWDAXjxPT2EYP332cAzM8yxESmj1FgW1nolTNuTCKfnP UbWYkGnRxVWqZrlNXdy0Gk4TBy6jGW8WQAju9cbnkIibDhnl2T/s46zphzc3Qmyj8eir fGVI9s7FVuELfIJsEZGswMthsdZUDvYcYDKiToqkcfdocaMs1tWusOwduhmYx9IxmoZq qv0kdOsaT7ffqgnYyGCscR4P13KuOpAJnTdvCCICks4xYHuRScduZCgCXrfaVmQe9PbQ 2ezYD0DaJEUknam4p208XzXdYYcSg09EKoRtVFVWGLM9UmS8o3sKBlSsqoBB2Rq1gZUf 8PAA== X-Gm-Message-State: AG10YORt1EEBMJE+j/OYAaZ5HJk55jL7tPuG1E90S8BxT+EMxPWUN5AHKQ+u00biv4/VlRFUkLAYMEfz39UzF3Ey MIME-Version: 1.0 X-Received: by 10.182.20.207 with SMTP id p15mr3975028obe.13.1456462529937; Thu, 25 Feb 2016 20:55:29 -0800 (PST) Received: by 10.202.71.3 with HTTP; Thu, 25 Feb 2016 20:55:29 -0800 (PST) In-Reply-To: References: <1456382355-24614-2-git-send-email-fu.wei@linaro.org> <1456382355-24614-5-git-send-email-fu.wei@linaro.org> <56CF3B24.6030605@gmail.com> Date: Fri, 26 Feb 2016 12:55:29 +0800 Message-ID: Subject: Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi From: Fu Wei To: Andrei Borzenkov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c01::22e Cc: The development of GNU GRUB , xen-devel@lists.xensource.com, Ian Campbell , Vladimir Serbinenko , Julien Grall , Leif Lindholm , Linaro UEFI Mailman List , Jon Masters X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 04:55:33 -0000 Hi Andrei On 26 February 2016 at 12:48, Fu Wei wrote: > Hi Andrei > > On 26 February 2016 at 01:34, Andrei Borzenkov wrot= e: >> 25.02.2016 09:39, fu.wei@linaro.org =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> From: Fu Wei >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei >>> --- >>> docs/grub.texi | 32 +++++++++----------------------- >>> 1 file changed, 9 insertions(+), 23 deletions(-) >>> >>> diff --git a/docs/grub.texi b/docs/grub.texi >>> index 82f6fa4..0f99c50 100644 >>> --- a/docs/grub.texi >>> +++ b/docs/grub.texi >>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command @co= mmand{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 hyper= visor >>> +* xen_module:: Load xen modules for xen hypervisor >>> @end menu >>> >>> >>> @@ -5141,30 +5139,18 @@ 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. >>> +Each module will be identified by the order in which the modules are a= dded. >>> +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 The problem is (on ARM64) if there is no initrd for dom0, then the second module loaded will be treated as ramdisk. Maybe we need to mention that? > > 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. > > so maybe we can say: > ----------------------------- > On ARM64, 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 (optional) > All subsequent modules: UNKNOWN > > On i386, the modules will be identified by Multiboot(2) protocol. > ----------------------------- > > Is that better? please correct me if I miss something. > >> loaded then? >> >>> -@node xen_initrd >>> -@subsection xen_initrd >>> - >>> -@deffn Command xen_initrd file >>> -Load a initrd image for dom0 kernel at the booting process of xen. >>> -@end deffn >>> - >>> -@node xen_xsm >>> -@subsection xen_xsm >>> - >>> -@deffn Command xen_xsm file >>> -Load a xen security module for xen hypervisor at the booting process o= f xen. >>> -See @uref{http://wiki.xen.org/wiki/XSM} for more detail. >>> -@end deffn >>> - >>> - >>> @node Networking commands >>> @section The list of networking commands >>> >>> >> > > > > -- > 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 --=20 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 On 26 February 2016 at 12:48, Fu Wei wrote: > Hi Andrei > > On 26 February 2016 at 01:34, Andrei Borzenkov wrot= e: >> 25.02.2016 09:39, fu.wei@linaro.org =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >>> From: Fu Wei >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei >>> --- >>> docs/grub.texi | 32 +++++++++----------------------- >>> 1 file changed, 9 insertions(+), 23 deletions(-) >>> >>> diff --git a/docs/grub.texi b/docs/grub.texi >>> index 82f6fa4..0f99c50 100644 >>> --- a/docs/grub.texi >>> +++ b/docs/grub.texi >>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command @co= mmand{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 hyper= visor >>> +* xen_module:: Load xen modules for xen hypervisor >>> @end menu >>> >>> >>> @@ -5141,30 +5139,18 @@ 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. >>> +Each module will be identified by the order in which the modules are a= dded. >>> +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. > > so maybe we can say: > ----------------------------- > On ARM64, 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 (optional) > All subsequent modules: UNKNOWN > > On i386, the modules will be identified by Multiboot(2) protocol. > ----------------------------- > > Is that better? please correct me if I miss something. > >> loaded then? >> >>> -@node xen_initrd >>> -@subsection xen_initrd >>> - >>> -@deffn Command xen_initrd file >>> -Load a initrd image for dom0 kernel at the booting process of xen. >>> -@end deffn >>> - >>> -@node xen_xsm >>> -@subsection xen_xsm >>> - >>> -@deffn Command xen_xsm file >>> -Load a xen security module for xen hypervisor at the booting process o= f xen. >>> -See @uref{http://wiki.xen.org/wiki/XSM} for more detail. >>> -@end deffn >>> - >>> - >>> @node Networking commands >>> @section The list of networking commands >>> >>> >> > > > > -- > 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 --=20 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