Отправлено с 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%7D 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