* [PATCH v2 1/4] arm64: add "--nounzip" option support in xen_module command @ 2016-02-25 6:39 fu.wei 2016-02-25 6:39 ` [PATCH v2 2/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support fu.wei ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: fu.wei @ 2016-02-25 6:39 UTC (permalink / raw) To: grub-devel, arvidjaar, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi, Fu Wei From: Fu Wei <fu.wei@linaro.org> This patch adds "--nounzip" option support in order to be compatible with the module command of i386, then we can simplify grub-mkconfig support code. Signed-off-by: Fu Wei <fu.wei@linaro.org> --- grub-core/loader/arm64/xen_boot.c | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/grub-core/loader/arm64/xen_boot.c b/grub-core/loader/arm64/xen_boot.c index 8ae43d7..d63e631 100644 --- a/grub-core/loader/arm64/xen_boot.c +++ b/grub-core/loader/arm64/xen_boot.c @@ -20,6 +20,7 @@ #include <grub/charset.h> #include <grub/command.h> #include <grub/err.h> +#include <grub/env.h> #include <grub/file.h> #include <grub/fdt.h> #include <grub/list.h> @@ -379,6 +380,20 @@ grub_cmd_xen_module (grub_command_t cmd __attribute__((unused)), struct xen_boot_binary *module = NULL; grub_file_t file = 0; + int nounzip = 0; + + if (!argc) + { + grub_error (GRUB_ERR_BAD_ARGUMENT, N_("filename expected")); + goto fail; + } + + if (grub_strcmp (argv[0], "--nounzip") == 0) + { + argv++; + argc--; + nounzip = 1; + } if (!argc) { @@ -403,6 +418,8 @@ grub_cmd_xen_module (grub_command_t cmd __attribute__((unused)), grub_dprintf ("xen_loader", "Init module and node info\n"); + if (nounzip) + grub_file_filter_disable_compression (); file = grub_file_open (argv[0]); if (!file) goto fail; -- 2.5.0 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [PATCH v2 2/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support 2016-02-25 6:39 [PATCH v2 1/4] arm64: add "--nounzip" option support in xen_module command fu.wei @ 2016-02-25 6:39 ` fu.wei 2016-02-25 6:39 ` [PATCH v2 3/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386 fu.wei 2016-02-25 6:39 ` [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi fu.wei 2 siblings, 0 replies; 29+ messages in thread From: fu.wei @ 2016-02-25 6:39 UTC (permalink / raw) To: grub-devel, arvidjaar, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi, Fu Wei From: Fu Wei <fu.wei@linaro.org> This patch adds the support of xen_boot command: xen_hypervisor xen_module Also add a new "feature_xen_boot" to indicate this grub support xen_boot command. Signed-off-by: Fu Wei <fu.wei@linaro.org> --- grub-core/normal/main.c | 2 +- util/grub.d/20_linux_xen.in | 13 ++++++++++--- 2 files changed, 11 insertions(+), 4 deletions(-) diff --git a/grub-core/normal/main.c b/grub-core/normal/main.c index 78a70a8..3402a05 100644 --- a/grub-core/normal/main.c +++ b/grub-core/normal/main.c @@ -488,7 +488,7 @@ static const char *features[] = { "feature_chainloader_bpb", "feature_ntldr", "feature_platform_search_hint", "feature_default_font_path", "feature_all_video_module", "feature_menuentry_id", "feature_menuentry_options", "feature_200_final", - "feature_nativedisk_cmd", "feature_timeout_style" + "feature_nativedisk_cmd", "feature_timeout_style", "feature_xen_boot" }; GRUB_MOD_INIT(normal) diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in index 46045db..998ac21 100644 --- a/util/grub.d/20_linux_xen.in +++ b/util/grub.d/20_linux_xen.in @@ -122,16 +122,23 @@ linux_entry () else xen_rm_opts="no-real-mode edd=off" fi - multiboot ${rel_xen_dirname}/${xen_basename} placeholder ${xen_args} \${xen_rm_opts} + if [ "x\$feature_xen_boot" != xy ]; then + xen_loader="multiboot" + module_loader="module" + else + xen_loader="xen_hypervisor" + module_loader="xen_module" + fi + \${xen_loader} ${rel_xen_dirname}/${xen_basename} placeholder ${xen_args} \${xen_rm_opts} echo '$(echo "$lmessage" | grub_quote)' - module ${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args} + \${module_loader} ${rel_dirname}/${basename} placeholder root=${linux_root_device_thisversion} ro ${args} EOF if test -n "${initrd}" ; then # TRANSLATORS: ramdisk isn't identifier. Should be translated. message="$(gettext_printf "Loading initial ramdisk ...")" sed "s/^/$submenu_indentation/" << EOF echo '$(echo "$message" | grub_quote)' - module --nounzip ${rel_dirname}/${initrd} + \${module_loader} --nounzip ${rel_dirname}/${initrd} EOF fi sed "s/^/$submenu_indentation/" << EOF -- 2.5.0 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [PATCH v2 3/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386 2016-02-25 6:39 [PATCH v2 1/4] arm64: add "--nounzip" option support in xen_module command fu.wei 2016-02-25 6:39 ` [PATCH v2 2/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support fu.wei @ 2016-02-25 6:39 ` fu.wei 2016-02-25 6:39 ` [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi fu.wei 2 siblings, 0 replies; 29+ messages in thread From: fu.wei @ 2016-02-25 6:39 UTC (permalink / raw) To: grub-devel, arvidjaar, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi, Fu Wei From: Fu Wei <fu.wei@linaro.org> Signed-off-by: Fu Wei <fu.wei@linaro.org> --- grub-core/loader/i386/xen.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c index c4d9689..15b0727 100644 --- a/grub-core/loader/i386/xen.c +++ b/grub-core/loader/i386/xen.c @@ -689,6 +689,7 @@ fail: } static grub_command_t cmd_xen, cmd_initrd, cmd_module, cmd_multiboot; +static grub_command_t cmd_xen_hypervisor, cmd_xen_module; GRUB_MOD_INIT (xen) { @@ -696,10 +697,14 @@ GRUB_MOD_INIT (xen) 0, N_("Load Linux.")); cmd_multiboot = grub_register_command ("multiboot", grub_cmd_xen, 0, N_("Load Linux.")); + cmd_xen_hypervisor = grub_register_command ("xen_hypervisor", grub_cmd_xen, + 0, N_("Load Linux.")); cmd_initrd = grub_register_command ("initrd", grub_cmd_initrd, 0, N_("Load initrd.")); cmd_module = grub_register_command ("module", grub_cmd_module, 0, N_("Load module.")); + cmd_xen_module = grub_register_command ("xen_module", grub_cmd_module, + 0, N_("Load module.")); my_mod = mod; } @@ -709,4 +714,6 @@ GRUB_MOD_FINI (xen) grub_unregister_command (cmd_initrd); grub_unregister_command (cmd_multiboot); grub_unregister_command (cmd_module); + grub_unregister_command (cmd_xen_module); + grub_unregister_command (cmd_xen_hypervisor); } -- 2.5.0 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-25 6:39 [PATCH v2 1/4] arm64: add "--nounzip" option support in xen_module command fu.wei 2016-02-25 6:39 ` [PATCH v2 2/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support fu.wei 2016-02-25 6:39 ` [PATCH v2 3/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386 fu.wei @ 2016-02-25 6:39 ` fu.wei 2016-02-25 17:34 ` Andrei Borzenkov 2016-02-25 22:26 ` [Xen-devel] " Doug Goldstein 2 siblings, 2 replies; 29+ messages in thread From: fu.wei @ 2016-02-25 6:39 UTC (permalink / raw) To: grub-devel, arvidjaar, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi, Fu Wei From: Fu Wei <fu.wei@linaro.org> delete: xen_linux, xen_initrd, xen_xsm add: xen_module This update bases on commit 0edd750e50698854068358ea53528100a9192902 Author: Vladimir Serbinenko <phcoder@gmail.com> Date: Fri Jan 22 10:18:47 2016 +0100 xen_boot: Remove obsolete module type distinctions. Signed-off-by: Fu Wei <fu.wei@linaro.org> --- 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 @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,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 added. +The 1st module: dom0 kernel image +The 2nd module: dom0 ramdisk +All subsequent modules: UNKNOW @end deffn -@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 of xen. -See @uref{http://wiki.xen.org/wiki/XSM} for more detail. -@end deffn - - @node Networking commands @section The list of networking commands -- 2.5.0 ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-25 6:39 ` [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi fu.wei @ 2016-02-25 17:34 ` Andrei Borzenkov 2016-02-25 22:26 ` [Xen-devel] " Doug Goldstein 1 sibling, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-02-25 17:34 UTC (permalink / raw) To: fu.wei, grub-devel, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi 25.02.2016 09:39, fu.wei@linaro.org пишет: > From: Fu Wei <fu.wei@linaro.org> > > delete: xen_linux, xen_initrd, xen_xsm > add: xen_module > > This update bases on > commit 0edd750e50698854068358ea53528100a9192902 > Author: Vladimir Serbinenko <phcoder@gmail.com> > Date: Fri Jan 22 10:18:47 2016 +0100 > > xen_boot: Remove obsolete module type distinctions. > > Signed-off-by: Fu Wei <fu.wei@linaro.org> > --- > 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 @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,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 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 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 of xen. > -See @uref{http://wiki.xen.org/wiki/XSM} for more detail. > -@end deffn > - > - > @node Networking commands > @section The list of networking commands > > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-25 17:34 ` Andrei Borzenkov 0 siblings, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-02-25 17:34 UTC (permalink / raw) To: fu.wei, grub-devel, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi 25.02.2016 09:39, fu.wei@linaro.org пишет: > From: Fu Wei <fu.wei@linaro.org> > > delete: xen_linux, xen_initrd, xen_xsm > add: xen_module > > This update bases on > commit 0edd750e50698854068358ea53528100a9192902 > Author: Vladimir Serbinenko <phcoder@gmail.com> > Date: Fri Jan 22 10:18:47 2016 +0100 > > xen_boot: Remove obsolete module type distinctions. > > Signed-off-by: Fu Wei <fu.wei@linaro.org> > --- > 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 @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,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 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 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 of xen. > -See @uref{http://wiki.xen.org/wiki/XSM} for more detail. > -@end deffn > - > - > @node Networking commands > @section The list of networking commands > > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-25 17:34 ` Andrei Borzenkov @ 2016-02-26 4:48 ` Fu Wei -1 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 4:48 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Hi Andrei On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: > 25.02.2016 09:39, fu.wei@linaro.org пишет: >> From: Fu Wei <fu.wei@linaro.org> >> >> delete: xen_linux, xen_initrd, xen_xsm >> add: xen_module >> >> This update bases on >> commit 0edd750e50698854068358ea53528100a9192902 >> Author: Vladimir Serbinenko <phcoder@gmail.com> >> Date: Fri Jan 22 10:18:47 2016 +0100 >> >> xen_boot: Remove obsolete module type distinctions. >> >> Signed-off-by: Fu Wei <fu.wei@linaro.org> >> --- >> 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 @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,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 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. 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 of 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-26 4:48 ` Fu Wei 0 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 4:48 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Hi Andrei On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: > 25.02.2016 09:39, fu.wei@linaro.org пишет: >> From: Fu Wei <fu.wei@linaro.org> >> >> delete: xen_linux, xen_initrd, xen_xsm >> add: xen_module >> >> This update bases on >> commit 0edd750e50698854068358ea53528100a9192902 >> Author: Vladimir Serbinenko <phcoder@gmail.com> >> Date: Fri Jan 22 10:18:47 2016 +0100 >> >> xen_boot: Remove obsolete module type distinctions. >> >> Signed-off-by: Fu Wei <fu.wei@linaro.org> >> --- >> 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 @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,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 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. 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 of 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 4:48 ` Fu Wei @ 2016-02-26 4:55 ` Fu Wei -1 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 4:55 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Hi Andrei On 26 February 2016 at 12:48, Fu Wei <fu.wei@linaro.org> wrote: > Hi Andrei > > On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>> From: Fu Wei <fu.wei@linaro.org> >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>> --- >>> 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 @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,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 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 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 of 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 -- 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 <fu.wei@linaro.org> wrote: > Hi Andrei > > On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>> From: Fu Wei <fu.wei@linaro.org> >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>> --- >>> 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 @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,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 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. > > 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 of 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 -- 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-26 4:55 ` Fu Wei 0 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 4:55 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Hi Andrei On 26 February 2016 at 12:48, Fu Wei <fu.wei@linaro.org> wrote: > Hi Andrei > > On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>> From: Fu Wei <fu.wei@linaro.org> >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>> --- >>> 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 @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,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 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 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 of 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 -- 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 <fu.wei@linaro.org> wrote: > Hi Andrei > > On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>> From: Fu Wei <fu.wei@linaro.org> >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>> --- >>> 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 @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,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 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. > > 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 of 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 -- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 4:48 ` Fu Wei @ 2016-02-26 5:24 ` Andrei Borzenkov -1 siblings, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-02-26 5:24 UTC (permalink / raw) To: Fu Wei Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Отправлено с iPhone > 26 февр. 2016 г., в 7:48, Fu Wei <fu.wei@linaro.org> написал(а): > > Hi Andrei > >> On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>> From: Fu Wei <fu.wei@linaro.org> >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>> --- >>> 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 @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,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 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. > 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 of 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-26 5:24 ` Andrei Borzenkov 0 siblings, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-02-26 5:24 UTC (permalink / raw) To: Fu Wei Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Отправлено с iPhone > 26 февр. 2016 г., в 7:48, Fu Wei <fu.wei@linaro.org> написал(а): > > Hi Andrei > >> On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>> From: Fu Wei <fu.wei@linaro.org> >>> >>> delete: xen_linux, xen_initrd, xen_xsm >>> add: xen_module >>> >>> This update bases on >>> commit 0edd750e50698854068358ea53528100a9192902 >>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>> Date: Fri Jan 22 10:18:47 2016 +0100 >>> >>> xen_boot: Remove obsolete module type distinctions. >>> >>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>> --- >>> 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 @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,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 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. > 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 of 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 5:24 ` Andrei Borzenkov @ 2016-02-26 5:59 ` Fu Wei -1 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 5:59 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Hi Andrei On 26 February 2016 at 13:24, Andrei Borzenkov <arvidjaar@gmail.com> wrote: > > > Отправлено с iPhone > >> 26 февр. 2016 г., в 7:48, Fu Wei <fu.wei@linaro.org> написал(а): >> >> Hi Andrei >> >>> On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >>> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>>> From: Fu Wei <fu.wei@linaro.org> >>>> >>>> delete: xen_linux, xen_initrd, xen_xsm >>>> add: xen_module >>>> >>>> This update bases on >>>> commit 0edd750e50698854068358ea53528100a9192902 >>>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>>> Date: Fri Jan 22 10:18:47 2016 +0100 >>>> >>>> xen_boot: Remove obsolete module type distinctions. >>>> >>>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>>> --- >>>> 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 @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,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 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 ! > > >> 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 of 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 -- 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-26 5:59 ` Fu Wei 0 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 5:59 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Hi Andrei On 26 February 2016 at 13:24, Andrei Borzenkov <arvidjaar@gmail.com> wrote: > > > Отправлено с iPhone > >> 26 февр. 2016 г., в 7:48, Fu Wei <fu.wei@linaro.org> написал(а): >> >> Hi Andrei >> >>> On 26 February 2016 at 01:34, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >>> 25.02.2016 09:39, fu.wei@linaro.org пишет: >>>> From: Fu Wei <fu.wei@linaro.org> >>>> >>>> delete: xen_linux, xen_initrd, xen_xsm >>>> add: xen_module >>>> >>>> This update bases on >>>> commit 0edd750e50698854068358ea53528100a9192902 >>>> Author: Vladimir Serbinenko <phcoder@gmail.com> >>>> Date: Fri Jan 22 10:18:47 2016 +0100 >>>> >>>> xen_boot: Remove obsolete module type distinctions. >>>> >>>> Signed-off-by: Fu Wei <fu.wei@linaro.org> >>>> --- >>>> 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 @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,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 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 ! > > >> 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 of 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 -- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 5:59 ` Fu Wei (?) @ 2016-02-26 10:50 ` Andrei Borzenkov 2016-02-26 11:15 ` Fu Wei -1 siblings, 1 reply; 29+ messages in thread From: Andrei Borzenkov @ 2016-02-26 10:50 UTC (permalink / raw) To: Fu Wei Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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. ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 10:50 ` Andrei Borzenkov @ 2016-02-26 11:15 ` Fu Wei 2016-02-26 14:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2016-02-27 20:33 ` Konrad Rzeszutek Wilk 0 siblings, 2 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 11:15 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters Hi Andrei, On 26 February 2016 at 18:50, Andrei Borzenkov <arvidjaar@gmail.com> wrote: > On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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. :-) -- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 11:15 ` Fu Wei @ 2016-02-26 14:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2016-02-27 20:33 ` Konrad Rzeszutek Wilk 1 sibling, 0 replies; 29+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-02-26 14:03 UTC (permalink / raw) To: Fu Wei, Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Jon Masters, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List [-- Attachment #1.1: Type: text/plain, Size: 2522 bytes --] On 26.02.2016 12:15, Fu Wei wrote: > Hi Andrei, > > On 26 February 2016 at 18:50, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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. :-) > Your patches look fine. Let's wait for Andrei's opinion but I'm leaning to commit them > > [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] [-- Attachment #2: Type: text/plain, Size: 141 bytes --] _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-26 14:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 0 siblings, 0 replies; 29+ messages in thread From: Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-02-26 14:03 UTC (permalink / raw) To: Fu Wei, Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Jon Masters, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List [-- Attachment #1: Type: text/plain, Size: 2522 bytes --] On 26.02.2016 12:15, Fu Wei wrote: > Hi Andrei, > > On 26 February 2016 at 18:50, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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. :-) > Your patches look fine. Let's wait for Andrei's opinion but I'm leaning to commit them > > [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 14:03 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-02-27 2:43 ` Fu Wei -1 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-27 2:43 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Andrei Borzenkov, Jon Masters, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List On 26 February 2016 at 22:03, Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote: > On 26.02.2016 12:15, Fu Wei wrote: >> Hi Andrei, >> >> On 26 February 2016 at 18:50, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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. :-) >> > Your patches look fine. Let's wait for Andrei's opinion but I'm leaning > to commit them Hi Vladimir, Great thanks for your review, :-) Hi Andrei, Do you have any suggestion for my v3 patchset? Please let me know if I can do anything to improve it. Thanks! :-) >> >> > > -- 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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-27 2:43 ` Fu Wei 0 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-27 2:43 UTC (permalink / raw) To: Vladimir 'φ-coder/phcoder' Serbinenko Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Andrei Borzenkov, Jon Masters, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List On 26 February 2016 at 22:03, Vladimir 'φ-coder/phcoder' Serbinenko <phcoder@gmail.com> wrote: > On 26.02.2016 12:15, Fu Wei wrote: >> Hi Andrei, >> >> On 26 February 2016 at 18:50, Andrei Borzenkov <arvidjaar@gmail.com> wrote: >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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. :-) >> > Your patches look fine. Let's wait for Andrei's opinion but I'm leaning > to commit them Hi Vladimir, Great thanks for your review, :-) Hi Andrei, Do you have any suggestion for my v3 patchset? Please let me know if I can do anything to improve it. Thanks! :-) >> >> > > -- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-26 11:15 ` Fu Wei 2016-02-26 14:03 ` Vladimir 'φ-coder/phcoder' Serbinenko @ 2016-02-27 20:33 ` Konrad Rzeszutek Wilk 2016-02-28 5:10 ` Andrei Borzenkov 1 sibling, 1 reply; 29+ messages in thread From: Konrad Rzeszutek Wilk @ 2016-02-27 20:33 UTC (permalink / raw) To: The development of GNU GRUB Cc: xen-devel, Ian Campbell, Andrei Borzenkov, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters 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@gmail.com> wrote: > > On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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? Is this .. order dependency written somewhere in a document? In the Xen code-base that is? _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-27 20:33 ` Konrad Rzeszutek Wilk @ 2016-02-28 5:10 ` Andrei Borzenkov 0 siblings, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-02-28 5:10 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, The development of GNU GRUB Cc: xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters 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@gmail.com> wrote: >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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? > _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-28 5:10 ` Andrei Borzenkov 0 siblings, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-02-28 5:10 UTC (permalink / raw) To: Konrad Rzeszutek Wilk, The development of GNU GRUB Cc: xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters 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@gmail.com> wrote: >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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? > ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-28 5:10 ` Andrei Borzenkov (?) @ 2016-02-29 14:41 ` Konrad Rzeszutek Wilk 2016-03-01 4:02 ` Andrei Borzenkov -1 siblings, 1 reply; 29+ messages in thread From: Konrad Rzeszutek Wilk @ 2016-02-29 14:41 UTC (permalink / raw) To: Andrei Borzenkov Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters On Sun, Feb 28, 2016 at 08:10:33AM +0300, Andrei Borzenkov wrote: > 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@gmail.com> wrote: > >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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 'can'. If you use 'ucode=scan' on the Xen command line. Otherwise it has no clue. It actually would be just much nicer if Multiboot2 had some tag describing this and Xen (or any other OS) could just parse it like that. But that is just hand-waving, nice-to-do. > module after that is assumed to be initrd (dom0 kernel always must be > the very first module provided). That is true. > > 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@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-29 14:41 ` Konrad Rzeszutek Wilk @ 2016-03-01 4:02 ` Andrei Borzenkov 0 siblings, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-03-01 4:02 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters 29.02.2016 17:41, Konrad Rzeszutek Wilk пишет: > On Sun, Feb 28, 2016 at 08:10:33AM +0300, Andrei Borzenkov wrote: >> 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@gmail.com> wrote: >>>>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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 > > 'can'. If you use 'ucode=scan' on the Xen command line. Otherwise it has > no clue. > You can also pass ucode=N where N is module number ... but it goes off-topic. The current state is - it turned out that on ARM Xen is capable to "detect" only two types of modules - dom0 kernel and dom0 initrd. The fact is that Xen on ARM has at least one more module type and it is not possible to reliably load it with current interface. > It actually would be just much nicer if Multiboot2 had some tag describing > this and Xen (or any other OS) could just parse it like that. But that is > just hand-waving, nice-to-do. > It was decided that multiboot2 will not be used, and initial interface did pass module types from GRUB to Xen via FDT, but then it was changed to generic xen_module with explicit type specification. Personally I think that leaving detection of how to use module should be left to loaded program, and that modules should include enough information so that this can be done. > >> module after that is assumed to be initrd (dom0 kernel always must be >> the very first module provided). > > That is true. >> >> 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? >>> >> _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-03-01 4:02 ` Andrei Borzenkov 0 siblings, 0 replies; 29+ messages in thread From: Andrei Borzenkov @ 2016-03-01 4:02 UTC (permalink / raw) To: Konrad Rzeszutek Wilk Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Vladimir Serbinenko, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Jon Masters 29.02.2016 17:41, Konrad Rzeszutek Wilk пишет: > On Sun, Feb 28, 2016 at 08:10:33AM +0300, Andrei Borzenkov wrote: >> 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@gmail.com> wrote: >>>>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu.wei@linaro.org> 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 > > 'can'. If you use 'ucode=scan' on the Xen command line. Otherwise it has > no clue. > You can also pass ucode=N where N is module number ... but it goes off-topic. The current state is - it turned out that on ARM Xen is capable to "detect" only two types of modules - dom0 kernel and dom0 initrd. The fact is that Xen on ARM has at least one more module type and it is not possible to reliably load it with current interface. > It actually would be just much nicer if Multiboot2 had some tag describing > this and Xen (or any other OS) could just parse it like that. But that is > just hand-waving, nice-to-do. > It was decided that multiboot2 will not be used, and initial interface did pass module types from GRUB to Xen via FDT, but then it was changed to generic xen_module with explicit type specification. Personally I think that leaving detection of how to use module should be left to loaded program, and that modules should include enough information so that this can be done. > >> module after that is assumed to be initrd (dom0 kernel always must be >> the very first module provided). > > That is true. >> >> 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? >>> >> ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-25 6:39 ` [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi fu.wei @ 2016-02-25 22:26 ` Doug Goldstein 2016-02-25 22:26 ` [Xen-devel] " Doug Goldstein 1 sibling, 0 replies; 29+ messages in thread From: Doug Goldstein @ 2016-02-25 22:26 UTC (permalink / raw) To: fu.wei, grub-devel, arvidjaar, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi [-- Attachment #1.1: Type: text/plain, Size: 719 bytes --] On 2/25/16 12:39 AM, fu.wei@linaro.org wrote: > From: Fu Wei <fu.wei@linaro.org> > -@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 Missing an 'N' at the end there. Probably worth mentioning that the ramdisk is optional as well. -- Doug Goldstein [-- Attachment #1.2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 959 bytes --] [-- Attachment #2: Type: text/plain, Size: 126 bytes --] _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi @ 2016-02-25 22:26 ` Doug Goldstein 0 siblings, 0 replies; 29+ messages in thread From: Doug Goldstein @ 2016-02-25 22:26 UTC (permalink / raw) To: fu.wei, grub-devel, arvidjaar, phcoder Cc: xen-devel, Ian.Campbell, jcm, julien.grall, leif.lindholm, linaro-uefi [-- Attachment #1: Type: text/plain, Size: 719 bytes --] On 2/25/16 12:39 AM, fu.wei@linaro.org wrote: > From: Fu Wei <fu.wei@linaro.org> > -@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 Missing an 'N' at the end there. Probably worth mentioning that the ramdisk is optional as well. -- Doug Goldstein [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 959 bytes --] ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi 2016-02-25 22:26 ` [Xen-devel] " Doug Goldstein (?) @ 2016-02-26 4:49 ` Fu Wei -1 siblings, 0 replies; 29+ messages in thread From: Fu Wei @ 2016-02-26 4:49 UTC (permalink / raw) To: Doug Goldstein Cc: The development of GNU GRUB, xen-devel, Ian Campbell, Andrei Borzenkov, Jon Masters, Julien Grall, Leif Lindholm, Linaro UEFI Mailman List, Vladimir Serbinenko Hi Doug, On 26 February 2016 at 06:26, Doug Goldstein <cardoe@cardoe.com> wrote: > On 2/25/16 12:39 AM, fu.wei@linaro.org wrote: >> From: Fu Wei <fu.wei@linaro.org> >> -@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 > > Missing an 'N' at the end there. Probably worth mentioning that the > ramdisk is optional as well. Thanks for correction, will fix it. > > -- > Doug Goldstein > -- 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 ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2016-03-01 4:02 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-25 6:39 [PATCH v2 1/4] arm64: add "--nounzip" option support in xen_module command fu.wei 2016-02-25 6:39 ` [PATCH v2 2/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support fu.wei 2016-02-25 6:39 ` [PATCH v2 3/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386 fu.wei 2016-02-25 6:39 ` [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi fu.wei 2016-02-25 17:34 ` Andrei Borzenkov 2016-02-25 17:34 ` Andrei Borzenkov 2016-02-26 4:48 ` Fu Wei 2016-02-26 4:48 ` Fu Wei 2016-02-26 4:55 ` Fu Wei 2016-02-26 4:55 ` Fu Wei 2016-02-26 5:24 ` Andrei Borzenkov 2016-02-26 5:24 ` Andrei Borzenkov 2016-02-26 5:59 ` Fu Wei 2016-02-26 5:59 ` Fu Wei 2016-02-26 10:50 ` Andrei Borzenkov 2016-02-26 11:15 ` Fu Wei 2016-02-26 14:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2016-02-26 14:03 ` Vladimir 'φ-coder/phcoder' Serbinenko 2016-02-27 2:43 ` Fu Wei 2016-02-27 2:43 ` Fu Wei 2016-02-27 20:33 ` Konrad Rzeszutek Wilk 2016-02-28 5:10 ` Andrei Borzenkov 2016-02-28 5:10 ` Andrei Borzenkov 2016-02-29 14:41 ` Konrad Rzeszutek Wilk 2016-03-01 4:02 ` Andrei Borzenkov 2016-03-01 4:02 ` Andrei Borzenkov 2016-02-25 22:26 ` Doug Goldstein 2016-02-25 22:26 ` [Xen-devel] " Doug Goldstein 2016-02-26 4:49 ` Fu Wei
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.