Re: [Xen-devel] [PATCH 1/2] Fix util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Konrad,
Thanks for your feedback.
On 29 August 2017 at 02:40, Konrad Rzeszutek Wilk
<konrad.w...@oracle.com> wrote:
> Commit d33045ce7ffcb7c1e4a60c14d5ca64b36e3c5abe introduced
> the support for this, but it does not work under x86 (as it stops
> 20_linux_xen from running).
>
> The 20_linux_xen is run under a shell and any exits from within it:
>
For your example
> (For example on x86):
> + /usr/bin/grub2-file --is-arm64-efi /boot/xen-4.9.0.gz
> [root@tst063 grub]# echo $?
> 1
I guess that is right behavior, then
xen_loader="multiboot"
module_loader="module"
/boot/xen-4.9.0.gz is a xen binary for x86, right?
>
> will result in 20_linux_xen exciting without continuing
> and also causing grub2-mkconfig to stop processing.
maybe we are using different shell? are you using ash?
>
> As in:
>
> [root@tst063 ~]#
>
> And no more.
>
> This patch wraps the invocation of grub-file to be a in subshell
> and to process the return value in a conditional. That fixes
> the issue.
>
> RH-BZ 1486002: grub2-mkconfig does not work if xen.gz is installed.
> CC: Fu Wei <fu@linaro.org>
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.w...@oracle.com>
> ---
> util/grub.d/20_linux_xen.in | 9 -
> 1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
> index c002fc9..083bcef 100644
> --- a/util/grub.d/20_linux_xen.in
> +++ b/util/grub.d/20_linux_xen.in
> @@ -206,13 +206,12 @@ while [ "x${xen_list}" != "x" ] ; do
> if [ "x$is_top_level" != xtrue ]; then
> echo " submenu '$(gettext_printf "Xen hypervisor, version %s"
> "${xen_version}" | grub_quote)' \$menuentry_id_option
> 'xen-hypervisor-$xen_version-$boot_device_id' {"
> fi
> -$grub_file --is-arm64-efi $current_xen
> -if [ $? -ne 0 ]; then
> - xen_loader="multiboot"
> - module_loader="module"
> -else
> +if ($grub_file --is-arm64-efi $current_xen); then
> xen_loader="xen_hypervisor"
> module_loader="xen_module"
> +else
> + xen_loader="multiboot"
> + module_loader="module"
> fi
> while [ "x$list" != "x" ] ; do
> linux=`version_find_latest $list`
> --
> 2.1.4
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v8 0/3] arm64, xen: add xen_boot support into grub-mkconfig
Hi Daniel, On 15 May 2017 at 21:46, Daniel Kiper <dki...@net-space.pl> wrote: > Hi Julien, > > On Mon, May 15, 2017 at 02:43:28PM +0100, Julien Grall wrote: >> Hi Daniel, >> >> On 15/05/17 14:38, Daniel Kiper wrote: >> >On Sun, May 14, 2017 at 03:43:44PM +0800, fu@linaro.org wrote: >> >>From: Fu Wei <fu@linaro.org> >> >> >> >>This patchset add xen_boot support into grub-mkconfig for >> >>generating xen boot entrances automatically >> >> >> >>Also update the docs/grub.texi for new xen_boot commands. >> > >> >LGTM, if there are no objections I will commit it at the end >> >of this week or the beginning of next one. >> >> Thank you! >> >> Can you also please commit patch [1] which has been sitting on the grub >> ML for more than a year? This is preventing to boot Xen ARM with GRUB. >> >> Cheers, >> >> [1] https://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html > > Will do with this patch series. > Great thanks ! :-) > Daniel -- Best regards, Fu Wei Software Engineer Red Hat ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Vladimir,
On 11 May 2017 at 22:25, Fu Wei <fu@linaro.org> wrote:
> Hi Vladimir,
>
> On 11 May 2017 at 06:01, Vladimir 'phcoder' Serbinenko
> <phco...@gmail.com> wrote:
>>
>>
>> On Tue, May 9, 2017, 11:02 Fu Wei <fu@linaro.org> wrote:
>>>
>>> Hi Vladimir
>>>
>>> On 9 May 2017 at 14:59, Vladimir 'phcoder' Serbinenko <phco...@gmail.com>
>>> wrote:
>>> >
>>> >
>>> > Le Tue, May 2, 2017 à 9:06 AM, <fu@linaro.org> a écrit :
>>> >>
>>> >> From: Fu Wei <fu@linaro.org>
>>> >>
>>> >> This patch adds the support of xen_boot command for aarch64:
>>> >> xen_hypervisor
>>> >> xen_module
>>> >> These two commands are only for aarch64, since it has its own protocol
>>> >> and
>>> >> commands to boot xen hypervisor and Dom0, but not multiboot.
>>> >>
>>> >> For other architectures, they are still using multiboot and module
>>> >> commands.
>>> >>
>>> >> Signed-off-by: Fu Wei <fu@linaro.org>
>>> >> ---
>>> >> util/grub.d/20_linux_xen.in | 13 ++---
>>> >> 1 file changed, 10 insertions(+), 3 deletions(-)
>>> >>
>>> >> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
>>> >> index c48af94..919 100644
>>> >> --- a/util/grub.d/20_linux_xen.in
>>> >> +++ b/util/grub.d/20_linux_xen.in
>>> >> @@ -122,16 +122,16 @@ linux_entry ()
>>> >> else
>>> >> xen_rm_opts="no-real-mode edd=off"
>>> >> fi
>>> >> - multiboot ${rel_xen_dirname}/${xen_basename} placeholder
>>> >> ${xen_args} \${xen_rm_opts}
>>> >> + ${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
>>> >> @@ -206,6 +206,13 @@ while [ "x${xen_list}" != "x" ] ; do
>>> >> if [ "x$is_top_level" != xtrue ]; then
>>> >> echo " submenu '$(gettext_printf "Xen hypervisor, version %s"
>>> >> "${xen_version}" | grub_quote)' \$menuentry_id_option
>>> >> 'xen-hypervisor-$xen_version-$boot_device_id' {"
>>> >> fi
>>> >> +if [ "x$machine" != xaarch64 ]; then
>>> >
>>> > Machine of grub-mkconfig doesn't necessarily match the kernel. Think of
>>> > chroot or of having 32-bit userspace with 64-bit kernel. Better to do
>>> > this
>>> > on runtime. I know, it's not very nice but the whole grub-mkconfig is
>>> > trouble that needs redesign that I'm working on.
>>>
>>> So if we need to do this at run time(in grub shell), can I use
>>> "grub_cpu" variable instead?
>>
>> Yes, you can. Another possibility, probably better, is to check actual file
>> type, see grub-file
>
> Very good idea, will do in my v8 patchset, will send v8 in a day.
I have posted v8 patchset which is using “$grub_file”, please help me
to review it :-)
Great thanks!
>
>>>
>>>
>>> Thanks!
>>>
>>> >>
>>> >> + xen_loader="multiboot"
>>> >> + module_loader="module"
>>> >> +else
>>> >> + xen_loader="xen_hypervisor"
>>> >> + module_loader="xen_module"
>>> >> +fi
>>> >> while [ "x$list" != "x" ] ; do
>>> >> linux=`version_find_latest $list`
>>> >> gettext_printf "Found linux image: %s\n" "$linux" >&2
>>> >> --
>>> >> 2.9.3
>>> >>
>>> >
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> Fu Wei
>>> Software Engineer
>>> Red Hat
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat
--
Best regards,
Fu Wei
Software Engineer
Red Hat
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 0/3] arm64, xen: add xen_boot support into grub-mkconfig
From: Fu Wei <fu@linaro.org>
This patchset add xen_boot support into grub-mkconfig for
generating xen boot entrances automatically
Also update the docs/grub.texi for new xen_boot commands.
ChangeLog:
v8: http://lists.gnu.org/archive/html/grub-devel/2017-05/
Delete the redundant "#include " in patch 0001.
Use $grub_file instead of "feature_xen_boot" mechanism to
determine which xen boot commands we should use.
v7: http://lists.gnu.org/archive/html/grub-devel/2017-05/msg0.html
Delete patch 0001(v6) which is wrong.
Improve the commit message of 0002(v6).
Use "machine" variable instead of "feature_xen_boot" mechanism to
determine which xen boot commands we should use.
Update the introduction of xen_module commands in docs/grub.texi,
emphasize xen_hypervisor and xen_module are only for AArch64.
v6: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg00034.html
Fix Coding style of util/grub.d/20_linux_xen.in, use soft tab.
v5: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg8.html
Update the introduction of xen_module commands in docs/grub.texi,
according to the suggestion from Julien Grall
v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/
according to the XSM loading mechanism of Xen(upstreamed),
update the introduction of xen_module commands in docs/grub.texi
v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html
reorder the patches
update the introduction of xen_module commands in docs/grub.texi
v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html
add "--nounzip" option support in xen_module
use "feature_xen_boot" instead of "grub_xen_boot"
update the introduction of xen boot commands in docs/grub.texi
v1 :first upstream patchset:
http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html
Fu Wei (3):
arm64: add "--nounzip" option support in xen_module command
* util/grub.d/20_linux_xen.in: Add xen_boot command support for
aarch64
arm64: update the introduction of xen boot commands in docs/grub.texi
docs/grub.texi| 38 +-
grub-core/loader/arm64/xen_boot.c | 16
util/grub.d/20_linux_xen.in | 14 +++---
3 files changed, 40 insertions(+), 28 deletions(-)
--
2.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
From: Fu Wei <fu@linaro.org>
This patch adds the support of xen_boot command for aarch64:
xen_hypervisor
xen_module
These two commands are only for aarch64, since it has its own protocol and
commands to boot xen hypervisor and Dom0, but not multiboot.
For other architectures, they are still using multiboot and module
commands.
Signed-off-by: Fu Wei <fu@linaro.org>
---
util/grub.d/20_linux_xen.in | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c48af94..c002fc9 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -122,16 +122,16 @@ linux_entry ()
else
xen_rm_opts="no-real-mode edd=off"
fi
- multiboot ${rel_xen_dirname}/${xen_basename} placeholder
${xen_args} \${xen_rm_opts}
+ ${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
@@ -206,6 +206,14 @@ while [ "x${xen_list}" != "x" ] ; do
if [ "x$is_top_level" != xtrue ]; then
echo " submenu '$(gettext_printf "Xen hypervisor, version %s"
"${xen_version}" | grub_quote)' \$menuentry_id_option
'xen-hypervisor-$xen_version-$boot_device_id' {"
fi
+$grub_file --is-arm64-efi $current_xen
+if [ $? -ne 0 ]; then
+ xen_loader="multiboot"
+ module_loader="module"
+else
+ xen_loader="xen_hypervisor"
+ module_loader="xen_module"
+fi
while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
gettext_printf "Found linux image: %s\n" "$linux" >&2
--
2.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 3/3] arm64: update the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko <phco...@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.
Signed-off-by: Fu Wei <fu@linaro.org>
Reviewed-by: Julien Grall <julien.gr...@arm.com>
---
docs/grub.texi | 38 +-
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index e935af3..a0c4b9e 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3873,11 +3873,9 @@ you forget a command, you can run the command
@command{help}
@comment * vbeinfo:: List available video modes
* verify_detached:: Verify detached digital signature
* 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
+@comment * xen_*:: Xen boot commands for AArch64
+* xen_hypervisor:: Load xen hypervisor binary (only on AArch64)
+* xen_module:: Load xen modules for xen hypervisor (only on
AArch64)
@end menu
@@ -5153,32 +5151,22 @@ List available video modes. If resolution is given,
show only matching modes.
Load a Xen hypervisor binary from @var{file}. The rest of the line is passed
verbatim as the @dfn{kernel command-line}. Any other binaries must be
reloaded after using this command.
+This command is only available on AArch64 systems.
@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.
+Modules should be loaded in the following order:
+ - dom0 kernel image
+ - dom0 ramdisk if present
+ - XSM policy if present
+This command is only available on AArch64 systems.
@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.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v8 1/3] arm64: add "--nounzip" option support in xen_module command
From: Fu Wei <fu@linaro.org>
This patch adds "--nounzip" option support in order to
be compatible with the module command of multiboot on other architecture,
by this way we can simplify grub-mkconfig support code.
This patch also allow us to use zip compressed module(like Linux kernel
for Dom0).
Signed-off-by: Fu Wei <fu@linaro.org>
---
grub-core/loader/arm64/xen_boot.c | 16
1 file changed, 16 insertions(+)
diff --git a/grub-core/loader/arm64/xen_boot.c
b/grub-core/loader/arm64/xen_boot.c
index a914eb8..2a42654 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -379,6 +379,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 +417,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.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Vladimir,
On 11 May 2017 at 06:01, Vladimir 'phcoder' Serbinenko
<phco...@gmail.com> wrote:
>
>
> On Tue, May 9, 2017, 11:02 Fu Wei <fu@linaro.org> wrote:
>>
>> Hi Vladimir
>>
>> On 9 May 2017 at 14:59, Vladimir 'phcoder' Serbinenko <phco...@gmail.com>
>> wrote:
>> >
>> >
>> > Le Tue, May 2, 2017 à 9:06 AM, <fu@linaro.org> a écrit :
>> >>
>> >> From: Fu Wei <fu@linaro.org>
>> >>
>> >> This patch adds the support of xen_boot command for aarch64:
>> >> xen_hypervisor
>> >> xen_module
>> >> These two commands are only for aarch64, since it has its own protocol
>> >> and
>> >> commands to boot xen hypervisor and Dom0, but not multiboot.
>> >>
>> >> For other architectures, they are still using multiboot and module
>> >> commands.
>> >>
>> >> Signed-off-by: Fu Wei <fu@linaro.org>
>> >> ---
>> >> util/grub.d/20_linux_xen.in | 13 ++---
>> >> 1 file changed, 10 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
>> >> index c48af94..919 100644
>> >> --- a/util/grub.d/20_linux_xen.in
>> >> +++ b/util/grub.d/20_linux_xen.in
>> >> @@ -122,16 +122,16 @@ linux_entry ()
>> >> else
>> >> xen_rm_opts="no-real-mode edd=off"
>> >> fi
>> >> - multiboot ${rel_xen_dirname}/${xen_basename} placeholder
>> >> ${xen_args} \${xen_rm_opts}
>> >> + ${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
>> >> @@ -206,6 +206,13 @@ while [ "x${xen_list}" != "x" ] ; do
>> >> if [ "x$is_top_level" != xtrue ]; then
>> >> echo " submenu '$(gettext_printf "Xen hypervisor, version %s"
>> >> "${xen_version}" | grub_quote)' \$menuentry_id_option
>> >> 'xen-hypervisor-$xen_version-$boot_device_id' {"
>> >> fi
>> >> +if [ "x$machine" != xaarch64 ]; then
>> >
>> > Machine of grub-mkconfig doesn't necessarily match the kernel. Think of
>> > chroot or of having 32-bit userspace with 64-bit kernel. Better to do
>> > this
>> > on runtime. I know, it's not very nice but the whole grub-mkconfig is
>> > trouble that needs redesign that I'm working on.
>>
>> So if we need to do this at run time(in grub shell), can I use
>> "grub_cpu" variable instead?
>
> Yes, you can. Another possibility, probably better, is to check actual file
> type, see grub-file
Very good idea, will do in my v8 patchset, will send v8 in a day.
>>
>>
>> Thanks!
>>
>> >>
>> >> + xen_loader="multiboot"
>> >> + module_loader="module"
>> >> +else
>> >> + xen_loader="xen_hypervisor"
>> >> + module_loader="xen_module"
>> >> +fi
>> >> while [ "x$list" != "x" ] ; do
>> >> linux=`version_find_latest $list`
>> >> gettext_printf "Found linux image: %s\n" "$linux" >&2
>> >> --
>> >> 2.9.3
>> >>
>> >
>>
>>
>>
>> --
>> Best regards,
>>
>> Fu Wei
>> Software Engineer
>> Red Hat
--
Best regards,
Fu Wei
Software Engineer
Red Hat
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Vladimir
On 9 May 2017 at 17:02, Fu Wei <fu@linaro.org> wrote:
> Hi Vladimir
>
> On 9 May 2017 at 14:59, Vladimir 'phcoder' Serbinenko <phco...@gmail.com>
> wrote:
>>
>>
>> Le Tue, May 2, 2017 à 9:06 AM, <fu....@linaro.org> a écrit :
>>>
>>> From: Fu Wei <fu@linaro.org>
>>>
>>> This patch adds the support of xen_boot command for aarch64:
>>> xen_hypervisor
>>> xen_module
>>> These two commands are only for aarch64, since it has its own protocol and
>>> commands to boot xen hypervisor and Dom0, but not multiboot.
>>>
>>> For other architectures, they are still using multiboot and module
>>> commands.
>>>
>>> Signed-off-by: Fu Wei <fu@linaro.org>
>>> ---
>>> util/grub.d/20_linux_xen.in | 13 ++---
>>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
>>> index c48af94..919 100644
>>> --- a/util/grub.d/20_linux_xen.in
>>> +++ b/util/grub.d/20_linux_xen.in
>>> @@ -122,16 +122,16 @@ linux_entry ()
>>> else
>>> xen_rm_opts="no-real-mode edd=off"
>>> fi
>>> - multiboot ${rel_xen_dirname}/${xen_basename} placeholder
>>> ${xen_args} \${xen_rm_opts}
>>> + ${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
>>> @@ -206,6 +206,13 @@ while [ "x${xen_list}" != "x" ] ; do
>>> if [ "x$is_top_level" != xtrue ]; then
>>> echo " submenu '$(gettext_printf "Xen hypervisor, version %s"
>>> "${xen_version}" | grub_quote)' \$menuentry_id_option
>>> 'xen-hypervisor-$xen_version-$boot_device_id' {"
>>> fi
>>> +if [ "x$machine" != xaarch64 ]; then
>>
>> Machine of grub-mkconfig doesn't necessarily match the kernel. Think of
>> chroot or of having 32-bit userspace with 64-bit kernel. Better to do this
>> on runtime. I know, it's not very nice but the whole grub-mkconfig is
>> trouble that needs redesign that I'm working on.
>
> So if we need to do this at run time(in grub shell), can I use
> "grub_cpu" variable instead?
Dose this patch make sense to you?
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c48af94..0c26cbb 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\$grub_cpu" != xarm64 ]; 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
>
> Thanks!
>
>>>
>>> + xen_loader="multiboot"
>>> + module_loader="module"
>>> +else
>>> + xen_loader="xen_hypervisor"
>>> + module_loader="xen_module"
>>> +fi
>>> while [ "x$list" != "x" ] ; do
>>> linux=`version_find_latest $list`
>>> gettext_printf "Found linux image: %s\n" "$linux" >&2
>>> --
>>> 2.9.3
>>>
>>
>
>
>
> --
> Best regards,
>
> Fu Wei
> Software Engineer
> Red Hat
--
Best regards,
Fu Wei
Software Engineer
Red Hat
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Vladimir
On 9 May 2017 at 14:59, Vladimir 'phcoder' Serbinenko <phco...@gmail.com> wrote:
>
>
> Le Tue, May 2, 2017 à 9:06 AM, <fu@linaro.org> a écrit :
>>
>> From: Fu Wei <fu@linaro.org>
>>
>> This patch adds the support of xen_boot command for aarch64:
>> xen_hypervisor
>> xen_module
>> These two commands are only for aarch64, since it has its own protocol and
>> commands to boot xen hypervisor and Dom0, but not multiboot.
>>
>> For other architectures, they are still using multiboot and module
>> commands.
>>
>> Signed-off-by: Fu Wei <fu@linaro.org>
>> ---
>> util/grub.d/20_linux_xen.in | 13 ++---
>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
>> index c48af94..919 100644
>> --- a/util/grub.d/20_linux_xen.in
>> +++ b/util/grub.d/20_linux_xen.in
>> @@ -122,16 +122,16 @@ linux_entry ()
>> else
>> xen_rm_opts="no-real-mode edd=off"
>> fi
>> - multiboot ${rel_xen_dirname}/${xen_basename} placeholder
>> ${xen_args} \${xen_rm_opts}
>> + ${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
>> @@ -206,6 +206,13 @@ while [ "x${xen_list}" != "x" ] ; do
>> if [ "x$is_top_level" != xtrue ]; then
>> echo " submenu '$(gettext_printf "Xen hypervisor, version %s"
>> "${xen_version}" | grub_quote)' \$menuentry_id_option
>> 'xen-hypervisor-$xen_version-$boot_device_id' {"
>> fi
>> +if [ "x$machine" != xaarch64 ]; then
>
> Machine of grub-mkconfig doesn't necessarily match the kernel. Think of
> chroot or of having 32-bit userspace with 64-bit kernel. Better to do this
> on runtime. I know, it's not very nice but the whole grub-mkconfig is
> trouble that needs redesign that I'm working on.
So if we need to do this at run time(in grub shell), can I use
"grub_cpu" variable instead?
Thanks!
>>
>> + xen_loader="multiboot"
>> + module_loader="module"
>> +else
>> + xen_loader="xen_hypervisor"
>> + module_loader="xen_module"
>> +fi
>> while [ "x$list" != "x" ] ; do
>> linux=`version_find_latest $list`
>> gettext_printf "Found linux image: %s\n" "$linux" >&2
>> --
>> 2.9.3
>>
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 1/3] arm64: add "--nounzip" option support in xen_module command
Hi Vladimir,
On 9 May 2017 at 14:56, Vladimir 'phcoder' Serbinenko <phco...@gmail.com> wrote:
>
>
> Le Tue, May 2, 2017 à 9:06 AM, <fu@linaro.org> a écrit :
>>
>> From: Fu Wei <fu@linaro.org>
>>
>> This patch adds "--nounzip" option support in order to
>> be compatible with the module command of multiboot on other architecture,
>> by this way we can simplify grub-mkconfig support code.
>>
>> This patch also allow us to use zip compressed module(like Linux kernel
>> "vmlinuz*" for Dom0).
>>
>> Signed-off-by: Fu Wei <fu@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 a914eb8..0878364 100644
>> --- a/grub-core/loader/arm64/xen_boot.c
>> +++ b/grub-core/loader/arm64/xen_boot.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>
> This looks like spurious hunk.
Yes, we don't need this headfile to build xen_boot.
will delete it
Thanks,
>>
>> #include
>> #include
>> #include
>> @@ -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.9.3
>>
>
--
Best regards,
Fu Wei
Software Engineer
Red Hat
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Julien, On 5 May 2017 at 18:11, Julien Grall <julien.gr...@arm.com> wrote: > Hi Andrew, > > > On 05/05/17 10:01, Andrew Cooper wrote: >> >> On 05/05/17 09:57, Fu Wei wrote: >>> >>> Hi Stefano, >>> >>> On 4 May 2017 at 04:53, Stefano Stabellini <sstabell...@kernel.org> >>> wrote: >>>> >>>> On Wed, 3 May 2017, Andrew Cooper wrote: >>>>> >>>>> On 02/05/17 08:06, fu@linaro.org wrote: >>>>>> >>>>>> From: Fu Wei <fu@linaro.org> >>>>>> >>>>>> This patch adds the support of xen_boot command for aarch64: >>>>>> xen_hypervisor >>>>>> xen_module >>>>>> These two commands are only for aarch64, since it has its own protocol >>>>>> and >>>>>> commands to boot xen hypervisor and Dom0, but not multiboot. >>>>>> >>>>>> For other architectures, they are still using multiboot and module >>>>>> commands. >>>>>> >>>>>> Signed-off-by: Fu Wei <fu@linaro.org> >>>>> >>>>> Sorry if I am jumping in late and asking awkward questions, but what is >>>>> special about Xen/aarch64 here? Why is it using a non-standard entry >>>>> mechanism? >>>> >>>> Multiboot is not available on ARM. The boot protocol we have on ARM is >>>> FDT based: >>>> >>>> >>>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt >>>> >>>> We often refer to it as "multiboot for arm" but in fact it is not >>>> related to the x86 multiboot in any way. >>>> >>>> In Grub, the two protocols (multiboot and >>>> docs/misc/arm/device-tree/booting.txt) are kept clearly distinct >>>> (55a687e5.4070...@gmail.com). Hence, the need for this patch. >>> >>> Exactly, great thanks for your explanation! :-) >> >> >> So it really is an entirely custom Xen booting protocol. > > > Not really, Xen is using the Linux boot protocol. It does not allow to pass > multiple modules. The multiboot used by x86 does not support ARM (see [1]) > and hence not supported by any bootloaders existing on ARM. > > The "multiboot for ARM" has been designed to be generic enough to be used by > anyone (see [2]). And the original intention was to use "module" in > grub.cfg. I don't know why we did this change. yes, in the early patchset, I used multiboot and module command name, But since the protocol we are using is not a real multiboot, so I followed the suggestion (using xen_hypervisor and xen_module) to do this change. We don't want to confuse people. "module" is a command in the real multiboot module. if we don't use the real multiboot protocol, we avoid re-using its commands. > >> >> It is unfortunate that this wasn't reviewed sensibly at the time (and >> implemented in a project-neutral way), but it looks like the time to fix >> that properly has long since passed. > > > The bindings are project neutral. Only the commands in grub are not neutral, > I cannot find why it is not. > > Cheers, > > [1] https://www.gnu.org/software/grub/manual/multiboot/multiboot.html > [2] > https://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot > > -- > Julien Grall -- Best regards, Fu Wei Software Engineer Red Hat ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Andrew, On 5 May 2017 at 17:01, Andrew Cooper <andrew.coop...@citrix.com> wrote: > On 05/05/17 09:57, Fu Wei wrote: >> Hi Stefano, >> >> On 4 May 2017 at 04:53, Stefano Stabellini <sstabell...@kernel.org> wrote: >>> On Wed, 3 May 2017, Andrew Cooper wrote: >>>> On 02/05/17 08:06, fu@linaro.org wrote: >>>>> From: Fu Wei <fu@linaro.org> >>>>> >>>>> This patch adds the support of xen_boot command for aarch64: >>>>> xen_hypervisor >>>>> xen_module >>>>> These two commands are only for aarch64, since it has its own protocol and >>>>> commands to boot xen hypervisor and Dom0, but not multiboot. >>>>> >>>>> For other architectures, they are still using multiboot and module >>>>> commands. >>>>> >>>>> Signed-off-by: Fu Wei <fu@linaro.org> >>>> Sorry if I am jumping in late and asking awkward questions, but what is >>>> special about Xen/aarch64 here? Why is it using a non-standard entry >>>> mechanism? >>> Multiboot is not available on ARM. The boot protocol we have on ARM is >>> FDT based: >>> >>> http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt >>> >>> We often refer to it as "multiboot for arm" but in fact it is not >>> related to the x86 multiboot in any way. >>> >>> In Grub, the two protocols (multiboot and >>> docs/misc/arm/device-tree/booting.txt) are kept clearly distinct >>> (55a687e5.4070...@gmail.com). Hence, the need for this patch. >> Exactly, great thanks for your explanation! :-) > > So it really is an entirely custom Xen booting protocol. Yes, it is. > > It is unfortunate that this wasn't reviewed sensibly at the time (and > implemented in a project-neutral way), but it looks like the time to fix > that properly has long since passed. I guess the reason Xen use an entirely custom(lightweight) booting protocol on aarch64 is that the multiboot maybe a little "heavy" for aarch64. > > ~Andrew -- Best regards, Fu Wei Software Engineer Red Hat ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
Hi Stefano, On 4 May 2017 at 04:53, Stefano Stabellini <sstabell...@kernel.org> wrote: > On Wed, 3 May 2017, Andrew Cooper wrote: >> On 02/05/17 08:06, fu@linaro.org wrote: >> > From: Fu Wei <fu@linaro.org> >> > >> > This patch adds the support of xen_boot command for aarch64: >> > xen_hypervisor >> > xen_module >> > These two commands are only for aarch64, since it has its own protocol and >> > commands to boot xen hypervisor and Dom0, but not multiboot. >> > >> > For other architectures, they are still using multiboot and module >> > commands. >> > >> > Signed-off-by: Fu Wei <fu@linaro.org> >> >> Sorry if I am jumping in late and asking awkward questions, but what is >> special about Xen/aarch64 here? Why is it using a non-standard entry >> mechanism? > > Multiboot is not available on ARM. The boot protocol we have on ARM is > FDT based: > > http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=docs/misc/arm/device-tree/booting.txt > > We often refer to it as "multiboot for arm" but in fact it is not > related to the x86 multiboot in any way. > > In Grub, the two protocols (multiboot and > docs/misc/arm/device-tree/booting.txt) are kept clearly distinct > (55a687e5.4070...@gmail.com). Hence, the need for this patch. Exactly, great thanks for your explanation! :-) -- Best regards, Fu Wei Software Engineer Red Hat ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 0/3] arm64, xen: add xen_boot support into grup-mkconfig
Hi Daniel, On 5 May 2017 at 00:00, Daniel Kiper <dki...@net-space.pl> wrote: > Hey, > > On Tue, May 02, 2017 at 03:06:24PM +0800, fu@linaro.org wrote: >> From: Fu Wei <fu@linaro.org> >> >> This patchset add xen_boot support into grup-mkconfig for >> generating xen boot entrances automatically >> >> Also update the docs/grub.texi for new xen_boot commands. > > Slowly recovering after long weekend in Poland. > I will take a look at this probably next week. OK, thanks, sorry for delay, I should post it long time ago. Looking forward to your feedback! > > Daniel -- Best regards, Fu Wei Software Engineer Red Hat ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v7 0/3] arm64, xen: add xen_boot support into grup-mkconfig
Sorry for the typo On 2 May 2017 at 15:06, <fu@linaro.org> wrote: > From: Fu Wei <fu@linaro.org> > > This patchset add xen_boot support into grup-mkconfig for ^ grub2-mkconfig Also in the subject. > generating xen boot entrances automatically > > Also update the docs/grub.texi for new xen_boot commands. > > ChangeLog: > v7: http://lists.gnu.org/archive/html/grub-devel/2017-05/ > Delete patch 0001(v6) which is wrong. > Improve the commit message of 0002(v6). > Use "machine" variable instead of "feature_xen_boot" mechanism to > determine which xen boot commands we should use. > Update the introduction of xen_module commands in docs/grub.texi, > emphasize xen_hypervisor and xen_module are only for AArch64. > > v6: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg00034.html > Fix Coding style of util/grub.d/20_linux_xen.in, use soft tab. > > v5: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg8.html > Update the introduction of xen_module commands in docs/grub.texi, > according to the suggestion from Julien Grall > > v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/ > according to the XSM loading mechanism of Xen(upstreamed), > update the introduction of xen_module commands in docs/grub.texi > > v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html > reorder the patches > update the introduction of xen_module commands in docs/grub.texi > > v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html > add "--nounzip" option support in xen_module > use "feature_xen_boot" instead of "grub_xen_boot" > update the introduction of xen boot commands in docs/grub.texi > > v1 :first upstream patchset: > http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html > Fu Wei (3): > arm64: add "--nounzip" option support in xen_module command > * util/grub.d/20_linux_xen.in: Add xen_boot command support for > aarch64 > arm64: update the introduction of xen boot commands in docs/grub.texi > > docs/grub.texi| 38 +- > grub-core/loader/arm64/xen_boot.c | 17 + > util/grub.d/20_linux_xen.in | 13 ++--- > 3 files changed, 40 insertions(+), 28 deletions(-) > > -- > 2.9.3 > -- Best regards, Fu Wei Software Engineer Red Hat ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 2/3] * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64
From: Fu Wei <fu@linaro.org>
This patch adds the support of xen_boot command for aarch64:
xen_hypervisor
xen_module
These two commands are only for aarch64, since it has its own protocol and
commands to boot xen hypervisor and Dom0, but not multiboot.
For other architectures, they are still using multiboot and module
commands.
Signed-off-by: Fu Wei <fu@linaro.org>
---
util/grub.d/20_linux_xen.in | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index c48af94..919 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -122,16 +122,16 @@ linux_entry ()
else
xen_rm_opts="no-real-mode edd=off"
fi
- multiboot ${rel_xen_dirname}/${xen_basename} placeholder
${xen_args} \${xen_rm_opts}
+ ${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
@@ -206,6 +206,13 @@ while [ "x${xen_list}" != "x" ] ; do
if [ "x$is_top_level" != xtrue ]; then
echo " submenu '$(gettext_printf "Xen hypervisor, version %s"
"${xen_version}" | grub_quote)' \$menuentry_id_option
'xen-hypervisor-$xen_version-$boot_device_id' {"
fi
+if [ "x$machine" != xaarch64 ]; then
+ xen_loader="multiboot"
+ module_loader="module"
+else
+ xen_loader="xen_hypervisor"
+ module_loader="xen_module"
+fi
while [ "x$list" != "x" ] ; do
linux=`version_find_latest $list`
gettext_printf "Found linux image: %s\n" "$linux" >&2
--
2.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 0/3] arm64, xen: add xen_boot support into grup-mkconfig
From: Fu Wei <fu@linaro.org> This patchset add xen_boot support into grup-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands. ChangeLog: v7: http://lists.gnu.org/archive/html/grub-devel/2017-05/ Delete patch 0001(v6) which is wrong. Improve the commit message of 0002(v6). Use "machine" variable instead of "feature_xen_boot" mechanism to determine which xen boot commands we should use. Update the introduction of xen_module commands in docs/grub.texi, emphasize xen_hypervisor and xen_module are only for AArch64. v6: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg00034.html Fix Coding style of util/grub.d/20_linux_xen.in, use soft tab. v5: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg8.html Update the introduction of xen_module commands in docs/grub.texi, according to the suggestion from Julien Grall v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/ according to the XSM loading mechanism of Xen(upstreamed), update the introduction of xen_module commands in docs/grub.texi v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html reorder the patches update the introduction of xen_module commands in docs/grub.texi v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html add "--nounzip" option support in xen_module use "feature_xen_boot" instead of "grub_xen_boot" update the introduction of xen boot commands in docs/grub.texi v1 :first upstream patchset: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html Fu Wei (3): arm64: add "--nounzip" option support in xen_module command * util/grub.d/20_linux_xen.in: Add xen_boot command support for aarch64 arm64: update the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 38 +- grub-core/loader/arm64/xen_boot.c | 17 + util/grub.d/20_linux_xen.in | 13 ++--- 3 files changed, 40 insertions(+), 28 deletions(-) -- 2.9.3 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 3/3] arm64: update the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko <phco...@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.
Signed-off-by: Fu Wei <fu@linaro.org>
Reviewed-by: Julien Grall <julien.gr...@arm.com>
---
docs/grub.texi | 38 +-
1 file changed, 13 insertions(+), 25 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index e935af3..a0c4b9e 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3873,11 +3873,9 @@ you forget a command, you can run the command
@command{help}
@comment * vbeinfo:: List available video modes
* verify_detached:: Verify detached digital signature
* 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
+@comment * xen_*:: Xen boot commands for AArch64
+* xen_hypervisor:: Load xen hypervisor binary (only on AArch64)
+* xen_module:: Load xen modules for xen hypervisor (only on
AArch64)
@end menu
@@ -5153,32 +5151,22 @@ List available video modes. If resolution is given,
show only matching modes.
Load a Xen hypervisor binary from @var{file}. The rest of the line is passed
verbatim as the @dfn{kernel command-line}. Any other binaries must be
reloaded after using this command.
+This command is only available on AArch64 systems.
@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.
+Modules should be loaded in the following order:
+ - dom0 kernel image
+ - dom0 ramdisk if present
+ - XSM policy if present
+This command is only available on AArch64 systems.
@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.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v7 1/3] arm64: add "--nounzip" option support in xen_module command
From: Fu Wei <fu@linaro.org>
This patch adds "--nounzip" option support in order to
be compatible with the module command of multiboot on other architecture,
by this way we can simplify grub-mkconfig support code.
This patch also allow us to use zip compressed module(like Linux kernel
"vmlinuz*" for Dom0).
Signed-off-by: Fu Wei <fu@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 a914eb8..0878364 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -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.9.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko <phco...@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.
Signed-off-by: Fu Wei <fu@linaro.org>
Reviewed-by: Julien Grall <julien.gr...@arm.com>
---
docs/grub.texi | 32 +---
1 file changed, 9 insertions(+), 23 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 82f6fa4..85c913e 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.
+Modules should be loaded in the following order:
+ - dom0 kernel image
+ - dom0 ramdisk if present
+ - XSM policy if present
@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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support
From: Fu Wei <fu@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@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 c48af94..231e640 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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 1/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386
From: Fu Wei <fu@linaro.org>
Signed-off-by: Fu Wei <fu@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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 2/4] arm64: add "--nounzip" option support in xen_module command
From: Fu Wei <fu@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@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 a914eb8..0878364 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v6 0/4] arm64, xen: add xen_boot support into grup-mkconfig
From: Fu Wei <fu@linaro.org> This patchset add xen_boot support into grup-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands. This patchset has been tested on Foudation model with a bug fix: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html ChangeLog: v6: http://lists.gnu.org/archive/html/grub-devel/2016-07/ Fix Coding style of util/grub.d/20_linux_xen.in, use soft tab. v5: http://lists.gnu.org/archive/html/grub-devel/2016-07/msg8.html Update the introduction of xen_module commands in docs/grub.texi, according to the suggestion from Julien Grall v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/ according to the XSM loading mechanism of Xen(upstreamed), update the introduction of xen_module commands in docs/grub.texi v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html reorder the patches update the introduction of xen_module commands in docs/grub.texi v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html add "--nounzip" option support in xen_module use "feature_xen_boot" instead of "grub_xen_boot" update the introduction of xen boot commands in docs/grub.texi v1 :first upstream patchset: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html Fu Wei (4): i386,xen: Add xen_hypervisor and xen_module aliases for i386 arm64: add "--nounzip" option support in xen_module command * util/grub.d/20_linux_xen.in: Add xen_boot command support arm64: update the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 32 +--- grub-core/loader/arm64/xen_boot.c | 17 + grub-core/loader/i386/xen.c | 7 +++ grub-core/normal/main.c | 2 +- util/grub.d/20_linux_xen.in | 13 ++--- 5 files changed, 44 insertions(+), 27 deletions(-) -- 2.5.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64
Hi all
On 22 February 2016 at 17:29, Fu Wei <fu@linaro.org> wrote:
> Hi Julien,
>
> On 20 February 2016 at 00:28, Julien Grall <julien.gr...@linaro.org> wrote:
>> Xen is currently crashing because of malformed compatible property for
>> the boot module. This is because the property string is not
>> null-terminated as requested by the ePAR spec.
>> ---
>> grub-core/loader/arm64/xen_boot.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/grub-core/loader/arm64/xen_boot.c
>> b/grub-core/loader/arm64/xen_boot.c
>> index a914eb8..8ae43d7 100644
>> --- a/grub-core/loader/arm64/xen_boot.c
>> +++ b/grub-core/loader/arm64/xen_boot.c
>> @@ -156,7 +156,7 @@ prepare_xen_module_params (struct xen_boot_binary
>> *module, void *xen_boot_fdt)
>>grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name);
>>
>>retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible",
>> - MODULE_CUSTOM_COMPATIBLE,
>> sizeof(MODULE_CUSTOM_COMPATIBLE) - 1);
>> + MODULE_CUSTOM_COMPATIBLE,
>> sizeof(MODULE_CUSTOM_COMPATIBLE));
>>if (retval)
>> return grub_error (GRUB_ERR_IO, "failed to update FDT");
>>
>> --
>> 1.9.1
>
> I have tested it. yes, xen will crash without this patch.
> Tested-by: Fu Wei <fu@linaro.org>
I guess this bugfix haven't been merged yet,
Hope this fix can be merged soon :-)
>
> BTW, since Vladimir has simplified the xen boot code , and Now Xen
> distinguishes modules by order.
> --
> menuentry 'Foundation Model Xen test with initramfs' {
> xen_hypervisor /xen -- no-bootscrub console=dtuart conswitch=x
> dtuart=serial0 dom0_mem=512M dom0_max_vcpus=2
> xen_module /dom0_kernel_Image console=hvc0 root=/dev/ram0 ro
> xen_module /dom0_initramfs.cpio
> xen_module /xsm
> devicetree /fvp-base-gicv2-psci.dtb
> }
> -
>
> Maybe we should update doc to coordinate with this change.
>
> And another problem is: How does XEN identify XSM?
> Test with the config file above, I got "(XEN) MODULE[3]:
> 0008fabb4000 - 0008fabb65e7 Unknown"
>
> Please correct me if I miss something.
>
>
>>
>
>
>
> --
> 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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support
Hi Julien,
On 12 July 2016 at 18:21, Julien Grall <julien.gr...@arm.com> wrote:
> Hi Fu Wei,
>
>
> On 06/07/16 18:53, fu@linaro.org wrote:
>>
>> From: Fu Wei <fu@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@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 c48af94..6a88a39 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}
>
>
> What is the coding style for grub? This line is using hard tabs, but the
> previous one are using soft tab.
Thanks for pointing it out, I thinks it should be soft tab,
reason:
(1) GRUB follows the GNU Coding Standards
(2) according to "GNU Hello"( an example of how to follow the GNU
coding standards ),
the shell scripts are using soft tab.
So I will use soft tab in v6, please check
Thanks
>
>> 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
>>
>
> Regards,
>
> --
> Julien Grall
--
Best regards,
Fu Wei
Software Engineer
Red Hat
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 0/4] arm64, xen: add xen_boot support into grup-mkconfig
From: Fu Wei <fu@linaro.org> This patchset add xen_boot support into grup-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands. This patchset has been tested on Foudation model with a bug fix: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html ChangeLog: v5: Update the introduction of xen_module commands in docs/grub.texi, according to the suggestion from Julien Grall v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/ according to the XSM loading mechanism of Xen(upstreamed), update the introduction of xen_module commands in docs/grub.texi v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html reorder the patches update the introduction of xen_module commands in docs/grub.texi v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html add "--nounzip" option support in xen_module use "feature_xen_boot" instead of "grub_xen_boot" update the introduction of xen boot commands in docs/grub.texi v1 :first upstream patchset: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html Fu Wei (4): i386,xen: Add xen_hypervisor and xen_module aliases for i386 arm64: add "--nounzip" option support in xen_module command * util/grub.d/20_linux_xen.in: Add xen_boot command support arm64: update the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 32 +--- grub-core/loader/arm64/xen_boot.c | 17 + grub-core/loader/i386/xen.c | 7 +++ grub-core/normal/main.c | 2 +- util/grub.d/20_linux_xen.in | 13 ++--- 5 files changed, 44 insertions(+), 27 deletions(-) -- 2.5.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v4 0/4] arm64, xen: add xen_boot support into grup-mkconfig
Hi Julien, On 5 July 2016 at 18:48, Julien Grall <julien.gr...@arm.com> wrote: > Hi Fu Wei, > > What is the status of this series? IIRC the comments on this version were > minor. Sorry, I missed the suggestion of docs, I have rebased them to latest upstream grub and posted v5 just now. Thanks for reminding me > > Regards, > > > On 10/05/16 15:03, fu....@linaro.org wrote: >> >> From: Fu Wei <fu@linaro.org> >> >> This patchset add xen_boot support into grup-mkconfig for >> generating xen boot entrances automatically >> >> Also update the docs/grub.texi for new xen_boot commands. >> >> This patchset has been tested on Foudation model with a bug fix: >> http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html >> >> ChangeLog: >> v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/ >> according to the XSM loading mechanism of Xen(upstreamed), >> update the introduction of xen_module commands in docs/grub.texi >> >> v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html >> reorder the patches >> update the introduction of xen_module commands in docs/grub.texi >> >> v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html >> add "--nounzip" option support in xen_module >> use "feature_xen_boot" instead of "grub_xen_boot" >> update the introduction of xen boot commands in docs/grub.texi >> >> v1 :first upstream patchset: >> http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html >> >> Fu Wei (4): >>i386,xen: Add xen_hypervisor and xen_module aliases for i386 >>arm64: add "--nounzip" option support in xen_module command >>* util/grub.d/20_linux_xen.in: Add xen_boot command support >>arm64: update the introduction of xen boot commands in docs/grub.texi >> >> docs/grub.texi| 33 ++--- >> grub-core/loader/arm64/xen_boot.c | 17 + >> grub-core/loader/i386/xen.c | 7 +++ >> grub-core/normal/main.c | 2 +- >> util/grub.d/20_linux_xen.in | 13 ++--- >> 5 files changed, 45 insertions(+), 27 deletions(-) >> > > -- > Julien Grall -- Best regards, Fu Wei Software Engineer Red Hat ___ Xen-devel mailing list Xen-devel@lists.xen.org https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 1/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386
From: Fu Wei <fu@linaro.org>
Signed-off-by: Fu Wei <fu@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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko <phco...@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.
Signed-off-by: Fu Wei <fu@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..85c913e 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.
+Modules should be loaded in the following order:
+ - dom0 kernel image
+ - dom0 ramdisk if present
+ - XSM policy if present
@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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support
From: Fu Wei <fu@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@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 c48af94..6a88a39 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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5 2/4] arm64: add "--nounzip" option support in xen_module command
From: Fu Wei <fu@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@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 a914eb8..0878364 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 0/4] arm64, xen: add xen_boot support into grup-mkconfig
From: Fu Wei <fu@linaro.org> This patchset add xen_boot support into grup-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands. This patchset has been tested on Foudation model with a bug fix: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html ChangeLog: v4: http://lists.gnu.org/archive/html/grub-devel/2016-05/ according to the XSM loading mechanism of Xen(upstreamed), update the introduction of xen_module commands in docs/grub.texi v3: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00314.html reorder the patches update the introduction of xen_module commands in docs/grub.texi v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html add "--nounzip" option support in xen_module use "feature_xen_boot" instead of "grub_xen_boot" update the introduction of xen boot commands in docs/grub.texi v1 :first upstream patchset: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html Fu Wei (4): i386,xen: Add xen_hypervisor and xen_module aliases for i386 arm64: add "--nounzip" option support in xen_module command * util/grub.d/20_linux_xen.in: Add xen_boot command support arm64: update the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 33 ++--- grub-core/loader/arm64/xen_boot.c | 17 + grub-core/loader/i386/xen.c | 7 +++ grub-core/normal/main.c | 2 +- util/grub.d/20_linux_xen.in | 13 ++--- 5 files changed, 45 insertions(+), 27 deletions(-) -- 2.5.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support
From: Fu Wei <fu@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@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 c48af94..6a88a39 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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 2/4] arm64: add "--nounzip" option support in xen_module command
From: Fu Wei <fu@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@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 a914eb8..0878364 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko <phco...@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Also bases on the module loading mechanism of Xen code:
488c2a8 docs/arm64: clarify the documention for loading XSM support
67831c4 docs/arm64: update the documentation for loading XSM support
ca32012 xen/arm64: check XSM Magic from the second unknown module.
Signed-off-by: Fu Wei <fu@linaro.org>
---
docs/grub.texi | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 82f6fa4..df6018a 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3861,9 +3861,7 @@ you forget a command, you can run the command
@command{help}
* videoinfo:: List available video modes
@comment * xen_*:: Xen boot commands
* xen_hypervisor:: Load xen hypervisor binary
-* xen_linux:: Load dom0 kernel for xen hypervisor
-* xen_initrd:: Load dom0 initrd for dom0 kernel
-* xen_xsm:: Load xen security module for xen hypervisor
+* xen_module:: Load xen modules for xen hypervisor
@end menu
@@ -5141,30 +5139,19 @@ verbatim as the @dfn{kernel command-line}. Any other
binaries must be
reloaded after using this command.
@end deffn
-@node xen_linux
-@subsection xen_linux
+@node xen_module
+@subsection xen_module
-@deffn Command xen_linux file [arguments]
-Load a dom0 kernel image for xen hypervisor at the booting process of xen.
+@deffn Command xen_module [--nounzip] file [arguments]
+Load a module for xen hypervisor at the booting process of xen.
The rest of the line is passed verbatim as the module command line.
+Modules should be loaded in the following order:
+The 1st module: dom0 kernel image
+The 2nd module: dom0 ramdisk (optional, if the ramdisk is present, it must
+always be the second module)
+If the XSM is present, it can be loaded at any time after the 1st module.
@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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v4 1/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386
From: Fu Wei <fu@linaro.org>
Signed-off-by: Fu Wei <fu@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.5
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] docs/arm64: update the documention for loading XSM support
Hi All,
Great thanks for all your help :-)
On 25 April 2016 at 23:25, Stefano Stabellini <sstabell...@kernel.org> wrote:
> On Mon, 25 Apr 2016, Ian Jackson wrote:
>> Julien Grall writes ("Re: [PATCH v3] docs/arm64: update the documention for
>> loading XSM support"):
>> > Stefano has committed the previous version with some modifications. Is
>> > it better to read?
>>
>> IMO it is better than the original but I still think my proposed
>> wording is an improvement over Stefano's.
>>
>> Should I "rebase" it and resubmit ?
>
> Sure, 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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] docs/arm64: update the documention for loading XSM support
Hi Jan, On 21 April 2016 at 19:40, Jan Beulich <jbeul...@suse.com> wrote: >>>> On 21.04.16 at 13:07, <fu@linaro.org> wrote: > > Please follow the patch submission rules: Mail them _to_ the list, > _cc_-ing relevant people. Cc-ing the list twice makes little sense. > And please also apply some common sense when deciding who to > Cc - I don't think there's much point in Cc-ing other than ARM > maintainers on ARM specific doc patches (arguably that should be > reflected in ./MAINTAINERS). Sorry for late response, Thanks for your help, will fix my script :-) > > Jan > -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] docs/arm64: update the documention for loading XSM support
Hi Julien, Great thanks for your review and suggestion. I have taken almost all your suggestion, but did some modification, please have a look: http://lists.xen.org/archives/html/xen-devel/2016-04/msg02637.html Thanks for your help! :-) On 20 April 2016 at 19:27, Julien Grall <julien.gr...@arm.com> wrote: > Hello Fu Wei, > > On 14/04/16 18:06, fu@linaro.org wrote: >> >> From: Fu Wei <fu@linaro.org> >> >> This patch updates the documention for loading XSM by the module which > >> lacks a specific compatible string. > > s/documention/documentation/ > s/which/that/ > > The sentence is not clear to me. I would rephrase: > > "This patch updates the documentation for allowing detection of an XSM > module that lacks a specific compatible string". > >> This mechanism has been added by the >> >> commit ca32012341f3de7d3975407fb963e6028f0d0c8b > > > Missing full stop. > >> >> Signed-off-by: Fu Wei <fu@linaro.org> >> --- >> docs/misc/arm/device-tree/booting.txt | 17 + >> 1 file changed, 13 insertions(+), 4 deletions(-) >> >> diff --git a/docs/misc/arm/device-tree/booting.txt >> b/docs/misc/arm/device-tree/booting.txt >> index ad98bf3..f45a9c4 100644 >> --- a/docs/misc/arm/device-tree/booting.txt >> +++ b/docs/misc/arm/device-tree/booting.txt >> @@ -24,10 +24,19 @@ Each node contains the following properties: >> string (which must always be present). >> >> Xen will assume that the first module which lacks a more >> - specific compatible string is a "multiboot,kernel" and that >> - the second such is a "multiboot,ramdisk". Any subsequent >> - modules which lack a specific compatiblity string will not >> - receive any special treatment. >> + specific compatible string is a "multiboot,kernel". Xen will >> + detect the XSM magic from the second module which lacks of >> + a specific compatiblity string: > > > s/compatiblity/ > > The sentence is not clear. You could read as: "Xen will check all the > modules from the second module that lacks a specific compatible string". > > I.e Xen will do the XSM magic check even if the module has a specific > compatible string. > > I would instead say "For the second module that lacks a specific compatible > string, Xen will check if the module is a XSM policy: > >> + - if it's XSM, Xen will assume that the second such is a > > > "second such" is not clear. > >> + "xen,xsm-policy". and also assume user won't load ramdisk; > > > s/.// > > I would drop the rest of the sentence after "and". > >> + - if it's not XSM, Xen will assume that the second such is a > > > "second such" is not clear. > >> + "multiboot,ramdisk". >> + So if user want to load ramdisk without a specific compatiblity, > > > s/user/the user/ > s/compatiblity/compatibility/ > > However this is a documentation for the user. So I would say "This means > that if the ramdisk module is present and does not have a the compatible > string "multiboot,ramdisk", then it must be always the second module". > >> + it must be the 2nd one. >> + Xen will also detect the XSM Magic for the following modules >> + which lack of a specific compatiblity, and assume that the module > > > s/compatiblity/compatibility/ > >> + is a "xen,xsm-policy" or "multiboot,module", according to the >> + result of detection. > > > s/or/or a/ > s/detection/the detection/ > > I would also invert the two paragraphs. I.e inverting "So if user.." and > "Xen will...". > > Can you also mention that this behavior was introduced by Xen 4.7. I.e Xen > 4.6 (and downwards) still requires the module to have the compatible string > "xen,xsm-policy" and therefore XSM won't work with GRUB. > > The latter bits may need to be documented in GRUB. > >> >> Xen 4.4 supported a different set of legacy compatible strings >> which remain supported such that systems supporting both 4.4 >> > > Regards, > > -- > Julien Grall -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] docs/arm64: update the documention for loading XSM support
From: Fu Wei <fu@linaro.org> This patch updates the documentation for allowing detection of an XSM module that lacks a specific compatible string. This mechanism has been added by the commit ca32012341f3de7d3975407fb963e6028f0d0c8b. Signed-off-by: Fu Wei <fu@linaro.org> --- v2: Improve the doc, according to the suggestion from Julien Grall. v1: http://lists.xen.org/archives/html/xen-devel/2016-04/msg02070.html The first upstream version submitted in xen-devel mailing list. docs/misc/arm/device-tree/booting.txt | 22 ++ 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index ad98bf3..254ba77 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -24,10 +24,24 @@ Each node contains the following properties: string (which must always be present). Xen will assume that the first module which lacks a more - specific compatible string is a "multiboot,kernel" and that - the second such is a "multiboot,ramdisk". Any subsequent - modules which lack a specific compatiblity string will not - receive any special treatment. + specific compatible string is a "multiboot,kernel". + + Xen will check all the modules for the XSM Magic from the second + module that lacks a specific compatible string. According to the + result of the detection: + - if it's a XSM, Xen will assume its compatible string is a + "xen,xsm-policy"; + - if it's not a XSM, for the second module that lacks a specific + compatible string, Xen will assume its compatible string is a + "multiboot,ramdisk"; for the third and subsequent modules those + lacks a specific compatible string will not receive any special + treatment. + This means if the ramdisk module is present and does not have the + compatible string "multiboot,ramdisk", then it must always be the + second module. + Note: This XSM Magic detection behavior was introduced by Xen 4.7. + Xen 4.6 (and downwards) still requires the XSM module to have the + compatible string "xen,xsm-policy". Xen 4.4 supported a different set of legacy compatible strings which remain supported such that systems supporting both 4.4 -- 2.5.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.
Hi Wei Liu On 15 April 2016 at 17:47, Wei Liu <wei.l...@citrix.com> wrote: > On Wed, Apr 13, 2016 at 05:45:27PM +0800, Fu Wei wrote: >> Hi Julien, >> >> On 8 April 2016 at 23:19, Julien Grall <julien.gr...@arm.com> wrote: >> > Hi Wei, >> > >> > On 08/04/16 15:58, Wei Liu wrote: >> >> >> >> On Fri, Apr 08, 2016 at 03:51:22PM +0100, Julien Grall wrote: >> >>> >> >>> Hi Fu Wei, >> >>> >> >>> On 05/04/16 17:46, fu@linaro.org wrote: >> >>>> >> >>>> From: Fu Wei <fu@linaro.org> >> >>>> >> >>>> This patch adds a has_xsm_magic helper function for detecting XSM >> >>> >> >>> >from the second unknown module. >> >>>> >> >>>> >> >>>> If Xen can't get the kind of module from compatible, we guess the kind >> >>>> of >> >>>> these unknowns respectively: >> >>>> (1) The first unknown must be kernel. >> >>>> (2) Detect the XSM Magic from the 2nd unknown: >> >>>> a. If it's XSM, set the kind as XSM, and that also means we >> >>>> won't load ramdisk; >> >>>> b. if it's not XSM, set the kind as ramdisk. >> >>>> So if user want to load ramdisk, it must be the 2nd unknown. >> >>> >> >>> >> >>> The documentation in docs/misc/arm/device-tree/booting.txt needs to be >> >>> update. >> >>> >> >>> Otherwise, the rest of the patch looks good to me. >> >>> >> >>> Regards, >> >>> >> >> >> >> Is this targeting 4.7? Today is the last day for committing stuff. The >> >> doc can come in later. >> > >> > >> > Yes, it's targeting 4.7. Fu Wei, can you send a follow-up for the doc? >> > >> >> yes, of course, I will do ASAP. >> > > Yes please. Note that the anticipated release date would be the > beginning of June, so you have five weeks to do that. I have posted the doc patch: http://lists.xen.org/archives/html/xen-devel/2016-04/msg02070.html could some one review it ?? > > Wei. -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] docs/arm64: update the documention for loading XSM support
From: Fu Wei <fu@linaro.org> This patch updates the documention for loading XSM by the module which lacks a specific compatible string. This mechanism has been added by the commit ca32012341f3de7d3975407fb963e6028f0d0c8b Signed-off-by: Fu Wei <fu@linaro.org> --- docs/misc/arm/device-tree/booting.txt | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index ad98bf3..f45a9c4 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -24,10 +24,19 @@ Each node contains the following properties: string (which must always be present). Xen will assume that the first module which lacks a more - specific compatible string is a "multiboot,kernel" and that - the second such is a "multiboot,ramdisk". Any subsequent - modules which lack a specific compatiblity string will not - receive any special treatment. + specific compatible string is a "multiboot,kernel". Xen will + detect the XSM magic from the second module which lacks of + a specific compatiblity string: + - if it's XSM, Xen will assume that the second such is a + "xen,xsm-policy". and also assume user won't load ramdisk; + - if it's not XSM, Xen will assume that the second such is a + "multiboot,ramdisk". + So if user want to load ramdisk without a specific compatiblity, + it must be the 2nd one. + Xen will also detect the XSM Magic for the following modules + which lack of a specific compatiblity, and assume that the module + is a "xen,xsm-policy" or "multiboot,module", according to the + result of detection. Xen 4.4 supported a different set of legacy compatible strings which remain supported such that systems supporting both 4.4 -- 2.5.5 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi all On 18 March 2016 at 15:53, Fu Wei <fu@linaro.org> wrote: > Hi all, > > On 9 March 2016 at 16:22, Fu Wei <fu@linaro.org> wrote: >> Hi Julien, >> >> On 9 March 2016 at 15:10, Julien Grall <julien.gr...@arm.com> wrote: >>> Hi, >>> >>> On 08/03/2016 23:37, Fu Wei wrote: >>>> >>>> On 8 March 2016 at 14:54, Andrei Borzenkov <arvidj...@gmail.com> wrote: >>>> So speaking of loading additional modules/lack of initrd on ARM, I thinks >>>> that >>>> will (only) affect loading XSM. >>>> For this, I have discussed of that with Julien, I think : >>>> (1) the first module must be kernel >>>> (2) the second module must be initrd, if we have initrd >>>> (3) Start from the 2nd module, XEN will detect that if the module is a XSM >>>> by >>>> the XSM binary signature. if we get XSM as the second module, that >>>> means we have not initrd. >>> >>> >>> We need to update Xen for point (3). Fu Wei, could you send a patch for >>> this? >> >> Yes, I think I can do that. > > I have posted the patch for this: > > http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html git log ca32012341f3de7d3975407fb963e6028f0d0c8b commit ca32012341f3de7d3975407fb963e6028f0d0c8b Author: Fu Wei <fu@linaro.org> Date: Wed Apr 6 00:46:36 2016 +0800 xen/arm64: check XSM Magic from the second unknown module. This patch adds a has_xsm_magic helper function for detecting XSM from the second unknown module. If Xen can't get the kind of module from compatible, we guess the kind of these unknowns respectively: (1) The first unknown must be kernel. (2) Detect the XSM Magic from the 2nd unknown: a. If it's XSM, set the kind as XSM, and that also means we won't load ramdisk; b. if it's not XSM, set the kind as ramdisk. So if user want to load ramdisk, it must be the 2nd unknown. We also detect the XSM Magic for the following unknowns, then set its kind according to the return value of has_xsm_magic. By this way, arm64 behavior can be compatible to x86 and can simplify multi-arch bootloader such as GRUB. Signed-off-by: Fu Wei <fu@linaro.org> Acked-by: Daniel De Graaf <dgde...@tycho.nsa.gov> Acked-by: Julien Grall <julien.gr...@arm.com> Since the patch for this has been merged into the staging branch of xen, Could some one help to review this patch or maybe merge this patchset into GRUB if that is OK for all of you :-) > >> >>> >>>> please correct me if I misunderstand it >>> >>> >>> I'm fine with this plan, it matches the x86 behavior. >>> >> >> Great thanks for your review :-) >> >> >>> Cheers, >>> >>> -- >>> Julien Grall >> >> >> >> -- >> 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 -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.
Hi Julien, On 8 April 2016 at 23:19, Julien Grall <julien.gr...@arm.com> wrote: > Hi Wei, > > On 08/04/16 15:58, Wei Liu wrote: >> >> On Fri, Apr 08, 2016 at 03:51:22PM +0100, Julien Grall wrote: >>> >>> Hi Fu Wei, >>> >>> On 05/04/16 17:46, fu@linaro.org wrote: >>>> >>>> From: Fu Wei <fu@linaro.org> >>>> >>>> This patch adds a has_xsm_magic helper function for detecting XSM >>> >>> >from the second unknown module. >>>> >>>> >>>> If Xen can't get the kind of module from compatible, we guess the kind >>>> of >>>> these unknowns respectively: >>>> (1) The first unknown must be kernel. >>>> (2) Detect the XSM Magic from the 2nd unknown: >>>> a. If it's XSM, set the kind as XSM, and that also means we >>>> won't load ramdisk; >>>> b. if it's not XSM, set the kind as ramdisk. >>>> So if user want to load ramdisk, it must be the 2nd unknown. >>> >>> >>> The documentation in docs/misc/arm/device-tree/booting.txt needs to be >>> update. >>> >>> Otherwise, the rest of the patch looks good to me. >>> >>> Regards, >>> >> >> Is this targeting 4.7? Today is the last day for committing stuff. The >> doc can come in later. > > > Yes, it's targeting 4.7. Fu Wei, can you send a follow-up for the doc? > yes, of course, I will do ASAP. >> >> Julien and Daniel's acks are needed here. > > > Acked-by: Julien Grall <julien.gr...@arm.com> > > Regards, > > -- > Julien Grall -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.
Hi Julien, On 8 April 2016 at 22:51, Julien Grall <julien.gr...@arm.com> wrote: > Hi Fu Wei, > > On 05/04/16 17:46, fu@linaro.org wrote: >> >> From: Fu Wei <fu@linaro.org> >> >> This patch adds a has_xsm_magic helper function for detecting XSM >> from the second unknown module. >> >> If Xen can't get the kind of module from compatible, we guess the kind of >> these unknowns respectively: >> (1) The first unknown must be kernel. >> (2) Detect the XSM Magic from the 2nd unknown: >> a. If it's XSM, set the kind as XSM, and that also means we >> won't load ramdisk; >> b. if it's not XSM, set the kind as ramdisk. >> So if user want to load ramdisk, it must be the 2nd unknown. > > > The documentation in docs/misc/arm/device-tree/booting.txt needs to be > update. Yes, I may forgot this part, but I will make a new doc patch. Thanks for reminding me > > Otherwise, the rest of the patch looks good to me. Great thanks for your help > > Regards, > > -- > Julien Grall -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v5] xen/arm64: check XSM Magic from the second unknown module.
From: Fu Wei <fu@linaro.org>
This patch adds a has_xsm_magic helper function for detecting XSM
from the second unknown module.
If Xen can't get the kind of module from compatible, we guess the kind of
these unknowns respectively:
(1) The first unknown must be kernel.
(2) Detect the XSM Magic from the 2nd unknown:
a. If it's XSM, set the kind as XSM, and that also means we
won't load ramdisk;
b. if it's not XSM, set the kind as ramdisk.
So if user want to load ramdisk, it must be the 2nd unknown.
We also detect the XSM Magic for the following unknowns, then set its kind
according to the return value of has_xsm_magic.
By this way, arm64 behavior can be compatible to x86 and can simplify
multi-arch bootloader such as GRUB.
Signed-off-by: Fu Wei <fu@linaro.org>
---
Changelog:
v5: Wrap "#include " up by #ifdef CONFIG_HAS_DEVICE_TREE
Improve has_xsm_magic code.
v4: http://lists.xen.org/archives/html/xen-devel/2016-04/msg00553.html
Fix some code style and comments problems.
Only check the Magic number.
Re-order the code in process_multiboot_node to get the base address
first, then the XSM Magic checking function only need to check if the
Magic number is valid.
Factor the XSM Magic checking code into an helper and re-use it
in xsm_dt_policy_init.
v3: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03564.html
Using memcmp instead of strncmp.
Using "return 0;" instead of panic();
Improve some comments.
v2: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03543.html
Using XEN_MAGIC macro instead of 0xf97cff8c :
uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic = XEN_MAGIC;
Comment out the code(return 0 directly), if CONFIG_FLASK is not set.
v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html
The first upstream patch to xen-devel mailing lists.
xen/arch/arm/bootfdt.c | 37 +
xen/include/xsm/xsm.h | 8 +++-
xen/xsm/xsm_core.c | 27 +++
xen/xsm/xsm_policy.c | 8 ++--
4 files changed, 61 insertions(+), 19 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8a14015..d130633 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
static bool_t __init device_tree_node_matches(const void *fdt, int node,
@@ -175,6 +176,17 @@ static void __init process_multiboot_node(const void *fdt,
int node,
const char *cmdline;
int len;
+prop = fdt_get_property(fdt, node, "reg", );
+if ( !prop )
+panic("node %s missing `reg' property\n", name);
+
+if ( len < dt_cells_to_size(address_cells + size_cells) )
+panic("fdt: node `%s': `reg` property length is too short\n",
+name);
+
+cell = (const __be32 *)prop->data;
+device_tree_get_reg(, address_cells, size_cells, , );
+
if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
kind = BOOTMOD_KERNEL;
@@ -186,7 +198,17 @@ static void __init process_multiboot_node(const void *fdt,
int node,
else
kind = BOOTMOD_UNKNOWN;
-/* Guess that first two unknown are kernel and ramdisk respectively. */
+/**
+ * Guess the kind of these first two unknowns respectively:
+ * (1) The first unknown must be kernel.
+ * (2) Detect the XSM Magic from the 2nd unknown:
+ * a. If it's XSM, set the kind as XSM, and that also means we
+ * won't load ramdisk;
+ * b. if it's not XSM, set the kind as ramdisk.
+ * So if user want to load ramdisk, it must be the 2nd unknown.
+ * We also detect the XSM Magic for the following unknowns,
+ * then set its kind according to the return value of has_xsm_magic.
+ */
if ( kind == BOOTMOD_UNKNOWN )
{
switch ( kind_guess++ )
@@ -195,19 +217,10 @@ static void __init process_multiboot_node(const void
*fdt, int node,
case 1: kind = BOOTMOD_RAMDISK; break;
default: break;
}
+ if ( kind_guess > 1 && has_xsm_magic(start) )
+kind = BOOTMOD_XSM;
}
-prop = fdt_get_property(fdt, node, "reg", );
-if ( !prop )
-panic("node %s missing `reg' property\n", name);
-
-if ( len < dt_cells_to_size(address_cells + size_cells) )
-panic("fdt: node `%s': `reg` property length is too short\n",
-name);
-
-cell = (const __be32 *)prop->data;
-device_tree_get_reg(, address_cells, size_cells, , );
-
prop = fdt_get_property(fdt, node, "bootargs", );
if ( prop )
{
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3a
Re: [Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.
Hi Jan,
On 5 April 2016 at 22:16, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 05.04.16 at 15:38, <fu@linaro.org> wrote:
>> --- a/xen/xsm/xsm_core.c
>> +++ b/xen/xsm/xsm_core.c
>> @@ -19,6 +19,8 @@
>>
>> #ifdef CONFIG_XSM
>>
>> +#include
>
> This is not a good idea. Note how xsm_policy.c limits this inclusion to
> the CONFIG_HAS_DEVICE_TREE case only, which is the least that
> should be done here too.
OK, good point, thanks , will do.
>
>> @@ -109,6 +111,25 @@ int __init xsm_dt_init(void)
>>
>> return ret;
>> }
>> +
>> +/**
>> + * has_xsm_magic - Check XSM Magic of the module header by phy address
>> + * A XSM module has a special header
>> + *
>> + * uint magic | uint target_len | uchar target[8] |
>> + * 0xf97cff8c |8|"XenFlask" |
>> + *
>> + * 0xf97cff8c is policy magic number (XSM_MAGIC).
>> + * Here we only check the "magic" of the module.
>> + */
>> +bool __init has_xsm_magic(paddr_t start)
>> +{
>> +xsm_magic_t magic;
>> +
>> +copy_from_paddr(, start, sizeof(magic) );
>> +
>> + return ( XSM_MAGIC && magic == XSM_MAGIC );
>
> Is XSM_MAGIC == 0 possible here at all? And if it is, wouldn't it be
> better to avoid the copy_from_paddr() in that case?
yes, good idea, will do
>
> Jan
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen/arm64: check XSM Magic and Signature from the second unknown module.
Hi Julien,
I have taken all you suggestions and posted the v4 patch, please review it.
Great thanks for your help !!
On 2 April 2016 at 02:10, Julien Grall <julien.gr...@arm.com> wrote:
> (Use Stefano's new e-mail address)
> Hi Fu Wei,
>
> On 29/03/16 04:26, fu@linaro.org wrote:
>>
>> From: Fu Wei <fu@linaro.org>
>>
>> This patch add a check_xsm_signature static function for detecting XSM
>
>
> s/add/adds/
>
>> from the second unknown module.
>>
>> If Xen can't get the kind of module from compatible, we guess the kind of
>> these first two unknown respectively:
>
>
> The steps below are not only for the first two modules.
>
>> (1) The first unknown must be kernel;
>> (2) The second unknown is ramdisk, only if we have ramdisk;
>
>
> This is unclear.
>
>> (3) Start from the 2nd unknown, detect the XSM binary signature;
>> (4) If we got XSM in the 2nd unknown, that means we don't load
>> initrd.
>
>
> s/initrd/ramdisk/
>
> Also, the documentation in misc/arm/device-tree/booting.txt needs to be
> updated.
>
> ARM behavior will be compatible to x86 and will simplify multi-arch
> bootloader such as GRUB, so I'm fine to introduce this boot protocol change.
> However, I'd like to see the reason of this change spells out in the commit
> message.
>
>
>>
>> Signed-off-by: Fu Wei <fu@linaro.org>
>> ---
>> Changelog:
>> v3: Using memcmp instead of strncmp.
>> Using "return 0;" instead of panic();
>> Improve some comments.
>>
>> v2: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03543.html
>> Using XEN_MAGIC macro instead of 0xf97cff8c :
>> uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic =
>> XEN_MAGIC;
>> Comment out the code(return 0 directly), if CONFIG_FLASK is not set.
>>
>> v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html
>> The first upstream patch to xen-devel mailing lists.
>>
>> xen/arch/arm/bootfdt.c | 54
>> +-
>> 1 file changed, 53 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
>> index 8a14015..10d3382 100644
>> --- a/xen/arch/arm/bootfdt.c
>> +++ b/xen/arch/arm/bootfdt.c
>> @@ -163,6 +163,49 @@ static void __init process_memory_node(const void
>> *fdt, int node,
>> }
>> }
>>
>> +/**
>> + * check_xsm_signature - Check XSM Magic and Signature of the module
>> header
>> + * A XSM module has a special header
>> + *
>> + * uint magic | uint target_len | uchar target[8] |
>> + * 0xf97cff8c |8|"XenFlask" |
>> + *
>> + * 0xf97cff8c is policy magic number (XSM_MAGIC).
>> + * So we only read the first 16 bytes of the module, then check these
>> three
>> + * parts. This checking (memcmp) assumes little-endian byte order.
>> + */
>> +static bool __init check_xsm_signature(const void *fdt, int node,
>> + const char *name,
>> + u32 address_cells, u32 size_cells)
>> +{
>> +#ifdef CONFIG_FLASK
>> +u32 xen_magic = XSM_MAGIC, target_len = 8;
>> +const struct fdt_property *prop;
>> +unsigned char buff[16];
>> +paddr_t start, size;
>> +const __be32 *cell;
>> +int len;
>> +
>> +prop = fdt_get_property(fdt, node, "reg", );
>> +if ( !prop || len < dt_cells_to_size(address_cells + size_cells))
>> +return 0;
>> +
>> +cell = (const __be32 *)prop->data;
>> +device_tree_get_reg(, address_cells, size_cells, , );
>
>
> I would prefer if you re-order the code in process_multiboot_node to get the
> base address and size first. This function will then only check if the
> signature is valid.
>
>> +
>> +copy_from_paddr(buff, start, sizeof(buff));
>> +
>> +if (memcmp(buff, (void *) _magic, sizeof(u32)) ||
>> +memcmp(buff + sizeof(u32), (void *) _len, sizeof(u32)) ||
>> +memcmp(buff + sizeof(u32) * 2, "XenFlask", target_len))
>
>
> Do we really need to test all those fields? The current check in
> xsm_policy.c only check the magic number.
>
> Also I would prefer if you factor the code to copy/check in an helper and
> re-use it in xsm_dt_policy_init.
>
>> +return 0;
>> +
>>
[Xen-devel] [PATCH v4] xen/arm64: check XSM Magic from the second unknown module.
From: Fu Wei <fu@linaro.org>
This patch adds a has_xsm_magic helper function for detecting XSM
from the second unknown module.
If Xen can't get the kind of module from compatible, we guess the kind of
these unknowns respectively:
(1) The first unknown must be kernel.
(2) Detect the XSM Magic from the 2nd unknown:
a. If it's XSM, set the kind as XSM, and that also means we
won't load ramdisk;
b. if it's not XSM, set the kind as ramdisk.
So if user want to load ramdisk, it must be the 2nd unknown.
We also detect the XSM Magic for the following unknowns, then set its kind
according to the return value of has_xsm_magic.
By this way, arm64 behavior can be compatible to x86 and can simplify
multi-arch bootloader such as GRUB.
Signed-off-by: Fu Wei <fu@linaro.org>
---
Changelog:
v4: Fix some code style and comments problems.
Only check the Magic number.
Re-order the code in process_multiboot_node to get the base address
first, then the XSM Magic checking function only need to check if the
Magic number is valid.
Factor the XSM Magic checking code into an helper and re-use it
in xsm_dt_policy_init.
v3: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03564.html
Using memcmp instead of strncmp.
Using "return 0;" instead of panic();
Improve some comments.
v2: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03543.html
Using XEN_MAGIC macro instead of 0xf97cff8c :
uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic = XEN_MAGIC;
Comment out the code(return 0 directly), if CONFIG_FLASK is not set.
v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html
The first upstream patch to xen-devel mailing lists.
xen/arch/arm/bootfdt.c | 37 +
xen/include/xsm/xsm.h | 8 +++-
xen/xsm/xsm_core.c | 21 +
xen/xsm/xsm_policy.c | 8 ++--
4 files changed, 55 insertions(+), 19 deletions(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8a14015..d130633 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
static bool_t __init device_tree_node_matches(const void *fdt, int node,
@@ -175,6 +176,17 @@ static void __init process_multiboot_node(const void *fdt,
int node,
const char *cmdline;
int len;
+prop = fdt_get_property(fdt, node, "reg", );
+if ( !prop )
+panic("node %s missing `reg' property\n", name);
+
+if ( len < dt_cells_to_size(address_cells + size_cells) )
+panic("fdt: node `%s': `reg` property length is too short\n",
+name);
+
+cell = (const __be32 *)prop->data;
+device_tree_get_reg(, address_cells, size_cells, , );
+
if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 ||
fdt_node_check_compatible(fdt, node, "multiboot,kernel") == 0 )
kind = BOOTMOD_KERNEL;
@@ -186,7 +198,17 @@ static void __init process_multiboot_node(const void *fdt,
int node,
else
kind = BOOTMOD_UNKNOWN;
-/* Guess that first two unknown are kernel and ramdisk respectively. */
+/**
+ * Guess the kind of these first two unknowns respectively:
+ * (1) The first unknown must be kernel.
+ * (2) Detect the XSM Magic from the 2nd unknown:
+ * a. If it's XSM, set the kind as XSM, and that also means we
+ * won't load ramdisk;
+ * b. if it's not XSM, set the kind as ramdisk.
+ * So if user want to load ramdisk, it must be the 2nd unknown.
+ * We also detect the XSM Magic for the following unknowns,
+ * then set its kind according to the return value of has_xsm_magic.
+ */
if ( kind == BOOTMOD_UNKNOWN )
{
switch ( kind_guess++ )
@@ -195,19 +217,10 @@ static void __init process_multiboot_node(const void
*fdt, int node,
case 1: kind = BOOTMOD_RAMDISK; break;
default: break;
}
+ if ( kind_guess > 1 && has_xsm_magic(start) )
+kind = BOOTMOD_XSM;
}
-prop = fdt_get_property(fdt, node, "reg", );
-if ( !prop )
-panic("node %s missing `reg' property\n", name);
-
-if ( len < dt_cells_to_size(address_cells + size_cells) )
-panic("fdt: node `%s': `reg` property length is too short\n",
-name);
-
-cell = (const __be32 *)prop->data;
-device_tree_get_reg(, address_cells, size_cells, , );
-
prop = fdt_get_property(fdt, node, "bootargs", );
if ( prop )
{
diff --git a/xen/include/xsm/xsm.h b/xen/include/xsm/xsm.h
index 3afed70..803c7ea 100644
--- a/xen/include/xsm/xsm.h
+++ b/xen/include/xsm/xsm.h
@@ -745,6 +745,7 @@ extern int xsm_multiboot_policy_init(unsigned long
*module_map,
#ifdef CONFIG_HAS_D
Re: [Xen-devel] [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64
Hi Julien, I have posted the v3 , please check http://lists.xen.org/archives/html/xen-devel/2016-03/msg03564.html And I hope GRUB patch can be merged :-) On 30 March 2016 at 23:52, Julien Grall <julien.gr...@linaro.org> wrote: > Hello, > > Ping? > > Regards, > > > On 19/02/16 16:28, Julien Grall wrote: >> >> Xen is currently crashing because of malformed compatible property for >> the boot module. This is because the property string is not >> null-terminated as requested by the ePAR spec. >> --- >> grub-core/loader/arm64/xen_boot.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/grub-core/loader/arm64/xen_boot.c >> b/grub-core/loader/arm64/xen_boot.c >> index a914eb8..8ae43d7 100644 >> --- a/grub-core/loader/arm64/xen_boot.c >> +++ b/grub-core/loader/arm64/xen_boot.c >> @@ -156,7 +156,7 @@ prepare_xen_module_params (struct xen_boot_binary >> *module, void *xen_boot_fdt) >> grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name); >> >> retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible", >> - MODULE_CUSTOM_COMPATIBLE, >> sizeof(MODULE_CUSTOM_COMPATIBLE) - 1); >> + MODULE_CUSTOM_COMPATIBLE, >> sizeof(MODULE_CUSTOM_COMPATIBLE)); >> if (retval) >> return grub_error (GRUB_ERR_IO, "failed to update FDT"); >> >> > > -- > Julien Grall -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3] xen/arm64: check XSM Magic and Signature from the second unknown module.
Hi Jan
On 29 March 2016 at 17:56, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 29.03.16 at 05:26, <fu@linaro.org> wrote:
>> +static bool __init check_xsm_signature(const void *fdt, int node,
>> + const char *name,
>> + u32 address_cells, u32 size_cells)
>> +{
>> +#ifdef CONFIG_FLASK
>> +u32 xen_magic = XSM_MAGIC, target_len = 8;
>> +const struct fdt_property *prop;
>> +unsigned char buff[16];
>> +paddr_t start, size;
>> +const __be32 *cell;
>> +int len;
>> +
>> +prop = fdt_get_property(fdt, node, "reg", );
>> +if ( !prop || len < dt_cells_to_size(address_cells + size_cells))
>
> At the very least you'll need to adjust style: There's a missing
> blank before the closing parenthesis here, and more of this kind
> of issue follow later.
Ah, sorry, will fix it. Thanks ! ;-)
>
> Jan
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm64: check XSM Magic and Signature from the second unknown module.
Hi Daniel, On 29 March 2016 at 06:08, Daniel De Graaf <dgde...@tycho.nsa.gov> wrote: > On 03/28/2016 04:54 PM, Konrad Rzeszutek Wilk wrote: >> >> On Tue, Mar 29, 2016 at 01:55:07AM +0800, fu@linaro.org wrote: >>> >>> From: Fu Wei <fu@linaro.org> >>> >>> This patch add a check_xsm_signature static function for detecting XSM >>> from the second unknown module. >>> >>> If xen can't get the kind of module from compatible, we guess the kind of >>> these first two unknown respectively: >>> (1) The first unknown must be kernel; >>> (2) The second unknown is ramdisk, only if we have ramdisk; >>> (3) Start from the 2nd unknown, detect the XSM binary signature; >>> (4) If we got XSM in the 2nd unknown, that means we don't load >>> initrd. >>> >> >> Pls make the 'xen' be 'Xen'. >> >>> Signed-off-by: Fu Wei <fu@linaro.org> >> >> >> Cc-ing also Daniel (XSM maintainer). >> >> And Julien (linaro.org != arm.com) and Stefano. >>> >>> --- >>> v2: Using XEN_MAGIC macro instead of 0xf97cff8c : >>> uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic = >>> XEN_MAGIC; >>> Comment out the code(return 0 directly), if CONFIG_FLASK is not set. >>> >>> v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html >>> The first upstream patch to xen-devel mailing lists. >>> >>> xen/arch/arm/bootfdt.c | 57 >>> +- >>> 1 file changed, 56 insertions(+), 1 deletion(-) >>> >>> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c >>> index 8a14015..322f17f 100644 >>> --- a/xen/arch/arm/bootfdt.c >>> +++ b/xen/arch/arm/bootfdt.c >>> @@ -163,6 +163,52 @@ static void __init process_memory_node(const void >>> *fdt, int node, >>> } >>> } >>> >>> +/** >>> + * check_xsm_signature - Check XSM Magic and Signature of the module >>> header >>> + * A XSM module has a special header >>> + * >>> + * uint magic | uint target_len | uchar target[8] | >>> + * 0xf97cff8c |8|"XenFlask" | >>> + * >>> + * 0xf97cff8c is policy magic number. >>> + * So we only read the first 16 Bytes of the module, then check these >>> three >> >> >> s/Bytes/bytes/ >>> >>> + * parts. >> >> >> Is it possible for the hypervisor to chnage the policy magic number? >> Perhaps >> you should have : >> >> BUILD_BUG_ON(0xf97cff8c != XSM_MAGIC); >> >> to guard against changes? > > > The value of XSM_MAGIC will always be that constant if FLASK is the enabled > security module; the value was different when the (now-removed) ACM module > was selected. OK, it seems we can just use this :-) > > [...] >>> >>> +if (strncmp(buff, (char *) _magic, sizeof(u32)) || >>> +strncmp(buff + sizeof(u32), (char *) _len, sizeof(u32)) >>> || >>> +strncmp(buff + sizeof(u32) * 2, "XenFlask", target_len)) >>> +return 0; >>> + > > > memcmp() is more correct than strncmp() here, especially since target_len > will > have embedded NULLs. It also assumes little endian byte order; is that > worth > commenting on? yes, thanks. I think memcmp() is correct too! :-) I have added a comment in the next version :-) Please check my v3 patch :-) http://lists.xen.org/archives/html/xen-devel/2016-03/msg03564.html > > -- > Daniel De Graaf > National Security Agency -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2] xen/arm64: check XSM Magic and Signature from the second unknown module.
Hi Konrad,
On 29 March 2016 at 04:54, Konrad Rzeszutek Wilk <konrad.w...@oracle.com> wrote:
> On Tue, Mar 29, 2016 at 01:55:07AM +0800, fu@linaro.org wrote:
>> From: Fu Wei <fu@linaro.org>
>>
>> This patch add a check_xsm_signature static function for detecting XSM
>> from the second unknown module.
>>
>> If xen can't get the kind of module from compatible, we guess the kind of
>> these first two unknown respectively:
>> (1) The first unknown must be kernel;
>> (2) The second unknown is ramdisk, only if we have ramdisk;
>> (3) Start from the 2nd unknown, detect the XSM binary signature;
>> (4) If we got XSM in the 2nd unknown, that means we don't load initrd.
>>
>
> Pls make the 'xen' be 'Xen'.
Thanks, :-)
>
>> Signed-off-by: Fu Wei <fu@linaro.org>
>
> Cc-ing also Daniel (XSM maintainer).
Thanks, I will add him into to-list next time:-)
>
> And Julien (linaro.org != arm.com) and Stefano.
>> ---
>> v2: Using XEN_MAGIC macro instead of 0xf97cff8c :
>> uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic = XEN_MAGIC;
>> Comment out the code(return 0 directly), if CONFIG_FLASK is not set.
>>
>> v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html
>> The first upstream patch to xen-devel mailing lists.
>>
>> xen/arch/arm/bootfdt.c | 57
>> +-
>> 1 file changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
>> index 8a14015..322f17f 100644
>> --- a/xen/arch/arm/bootfdt.c
>> +++ b/xen/arch/arm/bootfdt.c
>> @@ -163,6 +163,52 @@ static void __init process_memory_node(const void *fdt,
>> int node,
>> }
>> }
>>
>> +/**
>> + * check_xsm_signature - Check XSM Magic and Signature of the module header
>> + * A XSM module has a special header
>> + *
>> + * uint magic | uint target_len | uchar target[8] |
>> + * 0xf97cff8c |8|"XenFlask" |
>> + *
>> + * 0xf97cff8c is policy magic number.
>> + * So we only read the first 16 Bytes of the module, then check these three
>
> s/Bytes/bytes/
thanks , will do
>> + * parts.
>
> Is it possible for the hypervisor to chnage the policy magic number? Perhaps
> you should have :
>
> BUILD_BUG_ON(0xf97cff8c != XSM_MAGIC);
>
> to guard against changes?
>
>> + */
>> +static bool __init check_xsm_signature(const void *fdt, int node,
>> + const char *name,
>> + u32 address_cells, u32 size_cells)
>> +{
>> +#ifdef CONFIG_FLASK
>> +u32 xen_magic = XSM_MAGIC, target_len = 8;
>> +const struct fdt_property *prop;
>> +paddr_t start, size;
>> +const __be32 *cell;
>> +char buff[16];
>> +int len;
>> +
>> +prop = fdt_get_property(fdt, node, "reg", );
>> +if ( !prop )
>> +panic("node %s missing `reg' property\n", name);
>
> Why panic? Can't you just return?
>
>> +
>> +if ( len < dt_cells_to_size(address_cells + size_cells) )
>> +panic("fdt: node `%s': `reg` property length is too short\n", name);
>
> Ditto?
Good point, will do
Thanks for your review :-)
>
>> +
>> +cell = (const __be32 *)prop->data;
>> +device_tree_get_reg(, address_cells, size_cells, , );
>> +
>> +copy_from_paddr(buff, start, sizeof(buff));
>> +
>> +if (strncmp(buff, (char *) _magic, sizeof(u32)) ||
>> +strncmp(buff + sizeof(u32), (char *) _len, sizeof(u32)) ||
>> +strncmp(buff + sizeof(u32) * 2, "XenFlask", target_len))
>> +return 0;
>> +
>> +return 1;
>> +#else
>> +return 0;
>> +#endif
>> +}
>> +
>> static void __init process_multiboot_node(const void *fdt, int node,
>>const char *name,
>>u32 address_cells, u32 size_cells)
>> @@ -186,7 +232,13 @@ static void __init process_multiboot_node(const void
>> *fdt, int node,
>> else
>> kind = BOOTMOD_UNKNOWN;
>>
>> -/* Guess that first two unknown are kernel and ramdisk respectively. */
>> +/**
>> + * Guess the kind of these first two unknown respectively:
>> + * (1) The first unknown must be kernel;
>
[Xen-devel] [PATCH v3] xen/arm64: check XSM Magic and Signature from the second unknown module.
From: Fu Wei <fu@linaro.org>
This patch add a check_xsm_signature static function for detecting XSM
from the second unknown module.
If Xen can't get the kind of module from compatible, we guess the kind of
these first two unknown respectively:
(1) The first unknown must be kernel;
(2) The second unknown is ramdisk, only if we have ramdisk;
(3) Start from the 2nd unknown, detect the XSM binary signature;
(4) If we got XSM in the 2nd unknown, that means we don't load initrd.
Signed-off-by: Fu Wei <fu@linaro.org>
---
Changelog:
v3: Using memcmp instead of strncmp.
Using "return 0;" instead of panic();
Improve some comments.
v2: http://lists.xen.org/archives/html/xen-devel/2016-03/msg03543.html
Using XEN_MAGIC macro instead of 0xf97cff8c :
uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic = XEN_MAGIC;
Comment out the code(return 0 directly), if CONFIG_FLASK is not set.
v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html
The first upstream patch to xen-devel mailing lists.
xen/arch/arm/bootfdt.c | 54 +-
1 file changed, 53 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8a14015..10d3382 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -163,6 +163,49 @@ static void __init process_memory_node(const void *fdt,
int node,
}
}
+/**
+ * check_xsm_signature - Check XSM Magic and Signature of the module header
+ * A XSM module has a special header
+ *
+ * uint magic | uint target_len | uchar target[8] |
+ * 0xf97cff8c |8|"XenFlask" |
+ *
+ * 0xf97cff8c is policy magic number (XSM_MAGIC).
+ * So we only read the first 16 bytes of the module, then check these three
+ * parts. This checking (memcmp) assumes little-endian byte order.
+ */
+static bool __init check_xsm_signature(const void *fdt, int node,
+ const char *name,
+ u32 address_cells, u32 size_cells)
+{
+#ifdef CONFIG_FLASK
+u32 xen_magic = XSM_MAGIC, target_len = 8;
+const struct fdt_property *prop;
+unsigned char buff[16];
+paddr_t start, size;
+const __be32 *cell;
+int len;
+
+prop = fdt_get_property(fdt, node, "reg", );
+if ( !prop || len < dt_cells_to_size(address_cells + size_cells))
+return 0;
+
+cell = (const __be32 *)prop->data;
+device_tree_get_reg(, address_cells, size_cells, , );
+
+copy_from_paddr(buff, start, sizeof(buff));
+
+if (memcmp(buff, (void *) _magic, sizeof(u32)) ||
+memcmp(buff + sizeof(u32), (void *) _len, sizeof(u32)) ||
+memcmp(buff + sizeof(u32) * 2, "XenFlask", target_len))
+return 0;
+
+return 1;
+#else
+return 0;
+#endif
+}
+
static void __init process_multiboot_node(const void *fdt, int node,
const char *name,
u32 address_cells, u32 size_cells)
@@ -186,7 +229,13 @@ static void __init process_multiboot_node(const void *fdt,
int node,
else
kind = BOOTMOD_UNKNOWN;
-/* Guess that first two unknown are kernel and ramdisk respectively. */
+/**
+ * Guess the kind of these first two unknown respectively:
+ * (1) The first unknown must be kernel;
+ * (2) The second unknown is ramdisk, only if we have ramdisk;
+ * (3) Start from the 2nd unknown, detect the XSM binary signature;
+ * (4) If we got XSM in the 2nd unknown, that means we have not initrd.
+ */
if ( kind == BOOTMOD_UNKNOWN )
{
switch ( kind_guess++ )
@@ -195,6 +244,9 @@ static void __init process_multiboot_node(const void *fdt,
int node,
case 1: kind = BOOTMOD_RAMDISK; break;
default: break;
}
+if (kind_guess > 1 && check_xsm_signature(fdt, node, name,
+ address_cells, size_cells))
+kind = BOOTMOD_XSM;
}
prop = fdt_get_property(fdt, node, "reg", );
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2] xen/arm64: check XSM Magic and Signature from the second unknown module.
From: Fu Wei <fu@linaro.org>
This patch add a check_xsm_signature static function for detecting XSM
from the second unknown module.
If xen can't get the kind of module from compatible, we guess the kind of
these first two unknown respectively:
(1) The first unknown must be kernel;
(2) The second unknown is ramdisk, only if we have ramdisk;
(3) Start from the 2nd unknown, detect the XSM binary signature;
(4) If we got XSM in the 2nd unknown, that means we don't load initrd.
Signed-off-by: Fu Wei <fu@linaro.org>
---
v2: Using XEN_MAGIC macro instead of 0xf97cff8c :
uint32_t selinux_magic = 0xf97cff8c; --> uint32_t xen_magic = XEN_MAGIC;
Comment out the code(return 0 directly), if CONFIG_FLASK is not set.
v1: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html
The first upstream patch to xen-devel mailing lists.
xen/arch/arm/bootfdt.c | 57 +-
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8a14015..322f17f 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -163,6 +163,52 @@ static void __init process_memory_node(const void *fdt,
int node,
}
}
+/**
+ * check_xsm_signature - Check XSM Magic and Signature of the module header
+ * A XSM module has a special header
+ *
+ * uint magic | uint target_len | uchar target[8] |
+ * 0xf97cff8c |8|"XenFlask" |
+ *
+ * 0xf97cff8c is policy magic number.
+ * So we only read the first 16 Bytes of the module, then check these three
+ * parts.
+ */
+static bool __init check_xsm_signature(const void *fdt, int node,
+ const char *name,
+ u32 address_cells, u32 size_cells)
+{
+#ifdef CONFIG_FLASK
+u32 xen_magic = XSM_MAGIC, target_len = 8;
+const struct fdt_property *prop;
+paddr_t start, size;
+const __be32 *cell;
+char buff[16];
+int len;
+
+prop = fdt_get_property(fdt, node, "reg", );
+if ( !prop )
+panic("node %s missing `reg' property\n", name);
+
+if ( len < dt_cells_to_size(address_cells + size_cells) )
+panic("fdt: node `%s': `reg` property length is too short\n", name);
+
+cell = (const __be32 *)prop->data;
+device_tree_get_reg(, address_cells, size_cells, , );
+
+copy_from_paddr(buff, start, sizeof(buff));
+
+if (strncmp(buff, (char *) _magic, sizeof(u32)) ||
+strncmp(buff + sizeof(u32), (char *) _len, sizeof(u32)) ||
+strncmp(buff + sizeof(u32) * 2, "XenFlask", target_len))
+return 0;
+
+return 1;
+#else
+return 0;
+#endif
+}
+
static void __init process_multiboot_node(const void *fdt, int node,
const char *name,
u32 address_cells, u32 size_cells)
@@ -186,7 +232,13 @@ static void __init process_multiboot_node(const void *fdt,
int node,
else
kind = BOOTMOD_UNKNOWN;
-/* Guess that first two unknown are kernel and ramdisk respectively. */
+/**
+ * Guess the kind of these first two unknown respectively:
+ * (1) The first unknown must be kernel;
+ * (2) The second unknown is ramdisk, only if we have ramdisk;
+ * (3) Start from the 2nd unknown, detect the XSM binary signature;
+ * (4) If we got XSM in the 2nd unknown, that means we have not initrd.
+ */
if ( kind == BOOTMOD_UNKNOWN )
{
switch ( kind_guess++ )
@@ -195,6 +247,9 @@ static void __init process_multiboot_node(const void *fdt,
int node,
case 1: kind = BOOTMOD_RAMDISK; break;
default: break;
}
+if (kind_guess > 1 && check_xsm_signature(fdt, node, name,
+ address_cells, size_cells))
+kind = BOOTMOD_XSM;
}
prop = fdt_get_property(fdt, node, "reg", );
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.
Hi Jan,
On 18 March 2016 at 16:24, Jan Beulich <jbeul...@suse.com> wrote:
>>>> On 18.03.16 at 08:41, <fu@linaro.org> wrote:
>> --- a/xen/arch/arm/bootfdt.c
>> +++ b/xen/arch/arm/bootfdt.c
>> @@ -163,6 +163,36 @@ static void __init process_memory_node(const void *fdt,
>> int node,
>> }
>> }
>>
>> +static bool __init check_xsm_signature(const void *fdt, int node,
>> + const char *name,
>> + u32 address_cells, u32 size_cells)
>> +{
>> +uint32_t selinux_magic = 0xf97cff8c;
>
> So this would be the 3rd instance of this literal number in the source
> base. I would have wanted to suggest using one of the two
> constants we already have, but I don't know which one to pick.
>
> Daniel - why do we have both XSM_MAGIC and FLASK_MAGIC?
Ah, Sorry for that , I didn't know we already have these definition.
OK, I think we should use XSM_MAGIC,
and I think FLASK_MAGIC should be "XenFlask".
Please correct me if I misunderstand something.
So maybe I should do :
uint32_t xen_magic = XEN_MAGIC;
>
> Jan
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] xen/arm64: check XSM Magic and Signature from the second unknown module.
From: Fu Wei <fu@linaro.org>
This patch add a check_xsm_signature static function for detecting XSM
from the second unknown module.
If xen can't get the kind of module from compatible, we guess the kind of
these first two unknown respectively:
(1) The first unknown must be kernel;
(2) The second unknown is ramdisk, only if we have ramdisk;
(3) Start from the 2nd unknown, detect the XSM binary signature;
(4) If we got XSM in the 2nd unknown, that means we don't load initrd.
Signed-off-by: Fu Wei <fu@linaro.org>
---
ChangeLog:
v1: This patch - the first upstream patch to xen-devel mailing lists.
xen/arch/arm/bootfdt.c | 41 -
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
index 8a14015..1a74ecf 100644
--- a/xen/arch/arm/bootfdt.c
+++ b/xen/arch/arm/bootfdt.c
@@ -163,6 +163,36 @@ static void __init process_memory_node(const void *fdt,
int node,
}
}
+static bool __init check_xsm_signature(const void *fdt, int node,
+ const char *name,
+ u32 address_cells, u32 size_cells)
+{
+uint32_t selinux_magic = 0xf97cff8c;
+const struct fdt_property *prop;
+paddr_t start, size;
+const __be32 *cell;
+/* 16 == sizeof(uint32_t) * 2 + sizeof("XenFlask") - 1 */
+char magic[16];
+int len;
+
+prop = fdt_get_property(fdt, node, "reg", );
+if ( !prop )
+panic("node %s missing `reg' property\n", name);
+
+if ( len < dt_cells_to_size(address_cells + size_cells) )
+panic("fdt: node `%s': `reg` property length is too short\n", name);
+
+cell = (const __be32 *)prop->data;
+device_tree_get_reg(, address_cells, size_cells, , );
+
+copy_from_paddr(magic, start, 16);
+if (strncmp(magic, (char *) _magic, sizeof(uint32_t)) ||
+strncmp(magic + sizeof(uint32_t) * 2, "XenFlask", 8))
+return 0;
+
+return 1;
+}
+
static void __init process_multiboot_node(const void *fdt, int node,
const char *name,
u32 address_cells, u32 size_cells)
@@ -186,7 +216,13 @@ static void __init process_multiboot_node(const void *fdt,
int node,
else
kind = BOOTMOD_UNKNOWN;
-/* Guess that first two unknown are kernel and ramdisk respectively. */
+/**
+ * Guess the kind of these first two unknown respectively:
+ * (1) The first unknown must be kernel;
+ * (2) The second unknown is ramdisk, only if we have ramdisk;
+ * (3) Start from the 2nd unknown, detect the XSM binary signature;
+ * (4) If we got XSM in the 2nd unknown, that means we have not initrd.
+ */
if ( kind == BOOTMOD_UNKNOWN )
{
switch ( kind_guess++ )
@@ -195,6 +231,9 @@ static void __init process_multiboot_node(const void *fdt,
int node,
case 1: kind = BOOTMOD_RAMDISK; break;
default: break;
}
+if (kind_guess > 1 && check_xsm_signature(fdt, node, name,
+ address_cells, size_cells))
+kind = BOOTMOD_XSM;
}
prop = fdt_get_property(fdt, node, "reg", );
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi all, On 9 March 2016 at 16:22, Fu Wei <fu@linaro.org> wrote: > Hi Julien, > > On 9 March 2016 at 15:10, Julien Grall <julien.gr...@arm.com> wrote: >> Hi, >> >> On 08/03/2016 23:37, Fu Wei wrote: >>> >>> On 8 March 2016 at 14:54, Andrei Borzenkov <arvidj...@gmail.com> wrote: >>> So speaking of loading additional modules/lack of initrd on ARM, I thinks >>> that >>> will (only) affect loading XSM. >>> For this, I have discussed of that with Julien, I think : >>> (1) the first module must be kernel >>> (2) the second module must be initrd, if we have initrd >>> (3) Start from the 2nd module, XEN will detect that if the module is a XSM >>> by >>> the XSM binary signature. if we get XSM as the second module, that >>> means we have not initrd. >> >> >> We need to update Xen for point (3). Fu Wei, could you send a patch for >> this? > > Yes, I think I can do that. I have posted the patch for this: http://lists.xen.org/archives/html/xen-devel/2016-03/msg02430.html > >> >>> please correct me if I misunderstand it >> >> >> I'm fine with this plan, it matches the x86 behavior. >> > > Great thanks for your review :-) > > >> Cheers, >> >> -- >> Julien Grall > > > > -- > 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Julien, On 9 March 2016 at 15:10, Julien Grall <julien.gr...@arm.com> wrote: > Hi, > > On 08/03/2016 23:37, Fu Wei wrote: >> >> On 8 March 2016 at 14:54, Andrei Borzenkov <arvidj...@gmail.com> wrote: >> So speaking of loading additional modules/lack of initrd on ARM, I thinks >> that >> will (only) affect loading XSM. >> For this, I have discussed of that with Julien, I think : >> (1) the first module must be kernel >> (2) the second module must be initrd, if we have initrd >> (3) Start from the 2nd module, XEN will detect that if the module is a XSM >> by >> the XSM binary signature. if we get XSM as the second module, that >> means we have not initrd. > > > We need to update Xen for point (3). Fu Wei, could you send a patch for > this? Yes, I think I can do that. > >> please correct me if I misunderstand it > > > I'm fine with this plan, it matches the x86 behavior. > Great thanks for your review :-) > Cheers, > > -- > Julien Grall -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Andrei,
On 8 March 2016 at 14:54, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 07.03.2016 11:22, Fu Wei пишет:
>> Hi Andrei,
>>
>> On 28 February 2016 at 00:44, Fu Wei <fu@linaro.org> wrote:
>>> Hi Andrei
>>>
>>> On 28 February 2016 at 01:26, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>>>> 26.02.2016 14:13, fu@linaro.org пишет:
>>>>> From: Fu Wei <fu@linaro.org>
>>>>>
>>>>> delete: xen_linux, xen_initrd, xen_xsm
>>>>> add: xen_module
>>>>>
>>>>> This update bases on
>>>>> commit 0edd750e50698854068358ea53528100a9192902
>>>>> Author: Vladimir Serbinenko <phco...@gmail.com>
>>>>> Date: Fri Jan 22 10:18:47 2016 +0100
>>>>>
>>>>> xen_boot: Remove obsolete module type distinctions.
>>>>>
>>>>> Signed-off-by: Fu Wei <fu@linaro.org>
>>>>> ---
>>>>> docs/grub.texi | 33 ++---
>>>>> 1 file changed, 10 insertions(+), 23 deletions(-)
>>>>>
>>>>> diff --git a/docs/grub.texi b/docs/grub.texi
>>>>> index 82f6fa4..3fbdd99 100644
>>>>> --- a/docs/grub.texi
>>>>> +++ b/docs/grub.texi
>>>>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command
>>>>> @command{help}
>>>>> * videoinfo:: List available video modes
>>>>> @comment * xen_*:: Xen boot commands
>>>>> * xen_hypervisor:: Load xen hypervisor binary
>>>>> -* xen_linux:: Load dom0 kernel for xen hypervisor
>>>>> -* xen_initrd:: Load dom0 initrd for dom0 kernel
>>>>> -* xen_xsm:: Load xen security module for xen
>>>>> hypervisor
>>>>> +* xen_module:: Load xen modules for xen hypervisor
>>>>> @end menu
>>>>>
>>>>>
>>>>> @@ -5141,30 +5139,19 @@ verbatim as the @dfn{kernel command-line}. Any
>>>>> other binaries must be
>>>>> reloaded after using this command.
>>>>> @end deffn
>>>>>
>>>>> -@node xen_linux
>>>>> -@subsection xen_linux
>>>>> +@node xen_module
>>>>> +@subsection xen_module
>>>>>
>>>>> -@deffn Command xen_linux file [arguments]
>>>>> -Load a dom0 kernel image for xen hypervisor at the booting process of
>>>>> xen.
>>>>> +@deffn Command xen_module [--nounzip] file [arguments]
>>>>> +Load a module for xen hypervisor at the booting process of xen.
>>>>> The rest of the line is passed verbatim as the module command line.
>>>>
>>>> ==
>>>>> +On i386, the modules will be identified by Multiboot(2) protocol.
>>>>> +On arm64, each module will be identified by the order in which the
>>>>> +modules are added.
>>>>
>>>> I think it is better to skip it entirely. It is not really correct -
>>>> neither multiboot protocol provides any module identification (Xen
>>>> probes module types), nor is i386 using multiboot2, nor can all modules
>>>> be probed, so order still matters. To avoid confusion I'd simply
>>>> replaced the above three lines with
>>>>
>>>> Modules should be loaded in the following order:
>>>>
>>>>> +The 1st module: dom0 kernel image
>>>>> +The 2nd module: dom0 ramdisk (optional)
>>>>
>>>> This covers both supported platforms without going into too deep
>>>> details; if you and Vladimir are OK, I'll commit with this change.
>>>
>>> Thank you very much!
>>> Sorry I am not familiar with xen on i386, so maybe I misunderstand this.
>>> So please commit with your change, Thanks for your correction :-)
>>
>> I just fetched the mainline GRUB, i would like to know why this
>> patchset haven't been applied?
>> Anything I need to do(improve it or post a new patchset according to
>> your suggestion) for this patchset?
>>
>
> Sorry for delay. It is not really about your patchset, but we need some
> decision about loading additional modules/lack of initrd on ARM. Until
> then I'd rather avoid committing to any high-level configuration support
> that will require even more backward compatible hacks later.
>
> As it stands now either Xen needs to support autodetection or we need to
> revert to providing module type explicitly.
So speaking of loading additional modules/lack of initrd on ARM, I thinks that
will (only) affect loading XSM.
For this, I have discussed of that with Julien, I think :
(1) the first module must be kernel
(2) the second module must be initrd, if we have initrd
(3) Start from the 2nd module, XEN will detect that if the module is a XSM by
the XSM binary signature. if we get XSM as the second module, that
means we have not initrd.
please correct me if I misunderstand it
:-)
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Andrei,
On 28 February 2016 at 00:44, Fu Wei <fu@linaro.org> wrote:
> Hi Andrei
>
> On 28 February 2016 at 01:26, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>> 26.02.2016 14:13, fu@linaro.org пишет:
>>> From: Fu Wei <fu@linaro.org>
>>>
>>> delete: xen_linux, xen_initrd, xen_xsm
>>> add: xen_module
>>>
>>> This update bases on
>>> commit 0edd750e50698854068358ea53528100a9192902
>>> Author: Vladimir Serbinenko <phco...@gmail.com>
>>> Date: Fri Jan 22 10:18:47 2016 +0100
>>>
>>> xen_boot: Remove obsolete module type distinctions.
>>>
>>> Signed-off-by: Fu Wei <fu@linaro.org>
>>> ---
>>> docs/grub.texi | 33 ++---
>>> 1 file changed, 10 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/docs/grub.texi b/docs/grub.texi
>>> index 82f6fa4..3fbdd99 100644
>>> --- a/docs/grub.texi
>>> +++ b/docs/grub.texi
>>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command
>>> @command{help}
>>> * videoinfo:: List available video modes
>>> @comment * xen_*:: Xen boot commands
>>> * xen_hypervisor:: Load xen hypervisor binary
>>> -* xen_linux:: Load dom0 kernel for xen hypervisor
>>> -* xen_initrd:: Load dom0 initrd for dom0 kernel
>>> -* xen_xsm:: Load xen security module for xen hypervisor
>>> +* xen_module:: Load xen modules for xen hypervisor
>>> @end menu
>>>
>>>
>>> @@ -5141,30 +5139,19 @@ verbatim as the @dfn{kernel command-line}. Any
>>> other binaries must be
>>> reloaded after using this command.
>>> @end deffn
>>>
>>> -@node xen_linux
>>> -@subsection xen_linux
>>> +@node xen_module
>>> +@subsection xen_module
>>>
>>> -@deffn Command xen_linux file [arguments]
>>> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
>>> +@deffn Command xen_module [--nounzip] file [arguments]
>>> +Load a module for xen hypervisor at the booting process of xen.
>>> The rest of the line is passed verbatim as the module command line.
>>
>> ==
>>> +On i386, the modules will be identified by Multiboot(2) protocol.
>>> +On arm64, each module will be identified by the order in which the
>>> +modules are added.
>>
>> I think it is better to skip it entirely. It is not really correct -
>> neither multiboot protocol provides any module identification (Xen
>> probes module types), nor is i386 using multiboot2, nor can all modules
>> be probed, so order still matters. To avoid confusion I'd simply
>> replaced the above three lines with
>>
>> Modules should be loaded in the following order:
>>
>>> +The 1st module: dom0 kernel image
>>> +The 2nd module: dom0 ramdisk (optional)
>>
>> This covers both supported platforms without going into too deep
>> details; if you and Vladimir are OK, I'll commit with this change.
>
> Thank you very much!
> Sorry I am not familiar with xen on i386, so maybe I misunderstand this.
> So please commit with your change, Thanks for your correction :-)
I just fetched the mainline GRUB, i would like to know why this
patchset haven't been applied?
Anything I need to do(improve it or post a new patchset according to
your suggestion) for this patchset?
Great thanks :-)
>
>
>>
>>> @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
>>>
>>>
>>
>
>
>
> --
> 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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Andrei
On 28 February 2016 at 01:26, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 26.02.2016 14:13, fu@linaro.org пишет:
>> From: Fu Wei <fu@linaro.org>
>>
>> delete: xen_linux, xen_initrd, xen_xsm
>> add: xen_module
>>
>> This update bases on
>> commit 0edd750e50698854068358ea53528100a9192902
>> Author: Vladimir Serbinenko <phco...@gmail.com>
>> Date: Fri Jan 22 10:18:47 2016 +0100
>>
>> xen_boot: Remove obsolete module type distinctions.
>>
>> Signed-off-by: Fu Wei <fu@linaro.org>
>> ---
>> docs/grub.texi | 33 ++---
>> 1 file changed, 10 insertions(+), 23 deletions(-)
>>
>> diff --git a/docs/grub.texi b/docs/grub.texi
>> index 82f6fa4..3fbdd99 100644
>> --- a/docs/grub.texi
>> +++ b/docs/grub.texi
>> @@ -3861,9 +3861,7 @@ you forget a command, you can run the command
>> @command{help}
>> * videoinfo:: List available video modes
>> @comment * xen_*:: Xen boot commands
>> * xen_hypervisor:: Load xen hypervisor binary
>> -* xen_linux:: Load dom0 kernel for xen hypervisor
>> -* xen_initrd:: Load dom0 initrd for dom0 kernel
>> -* xen_xsm:: Load xen security module for xen hypervisor
>> +* xen_module:: Load xen modules for xen hypervisor
>> @end menu
>>
>>
>> @@ -5141,30 +5139,19 @@ verbatim as the @dfn{kernel command-line}. Any other
>> binaries must be
>> reloaded after using this command.
>> @end deffn
>>
>> -@node xen_linux
>> -@subsection xen_linux
>> +@node xen_module
>> +@subsection xen_module
>>
>> -@deffn Command xen_linux file [arguments]
>> -Load a dom0 kernel image for xen hypervisor at the booting process of xen.
>> +@deffn Command xen_module [--nounzip] file [arguments]
>> +Load a module for xen hypervisor at the booting process of xen.
>> The rest of the line is passed verbatim as the module command line.
>
> ==
>> +On i386, the modules will be identified by Multiboot(2) protocol.
>> +On arm64, each module will be identified by the order in which the
>> +modules are added.
>
> I think it is better to skip it entirely. It is not really correct -
> neither multiboot protocol provides any module identification (Xen
> probes module types), nor is i386 using multiboot2, nor can all modules
> be probed, so order still matters. To avoid confusion I'd simply
> replaced the above three lines with
>
> Modules should be loaded in the following order:
>
>> +The 1st module: dom0 kernel image
>> +The 2nd module: dom0 ramdisk (optional)
>
> This covers both supported platforms without going into too deep
> details; if you and Vladimir are OK, I'll commit with this change.
Thank you very much!
Sorry I am not familiar with xen on i386, so maybe I misunderstand this.
So please commit with your change, Thanks for your correction :-)
>
>> @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
>>
>>
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
On 26 February 2016 at 22:03, Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> wrote: > On 26.02.2016 12:15, Fu Wei wrote: >> Hi Andrei, >> >> On 26 February 2016 at 18:50, Andrei Borzenkov <arvidj...@gmail.com> wrote: >>> On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu@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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Andrei, On 26 February 2016 at 18:50, Andrei Borzenkov <arvidj...@gmail.com> wrote: > On Fri, Feb 26, 2016 at 8:59 AM, Fu Wei <fu@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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 3/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support
From: Fu Wei <fu@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@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 2/4] arm64: add "--nounzip" option support in xen_module command
From: Fu Wei <fu@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@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
#include
#include
+#include
#include
#include
#include
@@ -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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko <phco...@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Signed-off-by: Fu Wei <fu@linaro.org>
---
docs/grub.texi | 33 ++---
1 file changed, 10 insertions(+), 23 deletions(-)
diff --git a/docs/grub.texi b/docs/grub.texi
index 82f6fa4..3fbdd99 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3861,9 +3861,7 @@ you forget a command, you can run the command
@command{help}
* videoinfo:: List available video modes
@comment * xen_*:: Xen boot commands
* xen_hypervisor:: Load xen hypervisor binary
-* xen_linux:: Load dom0 kernel for xen hypervisor
-* xen_initrd:: Load dom0 initrd for dom0 kernel
-* xen_xsm:: Load xen security module for xen hypervisor
+* xen_module:: Load xen modules for xen hypervisor
@end menu
@@ -5141,30 +5139,19 @@ verbatim as the @dfn{kernel command-line}. Any other
binaries must be
reloaded after using this command.
@end deffn
-@node xen_linux
-@subsection xen_linux
+@node xen_module
+@subsection xen_module
-@deffn Command xen_linux file [arguments]
-Load a dom0 kernel image for xen hypervisor at the booting process of xen.
+@deffn Command xen_module [--nounzip] file [arguments]
+Load a module for xen hypervisor at the booting process of xen.
The rest of the line is passed verbatim as the module command line.
+On i386, the modules will be identified by Multiboot(2) protocol.
+On arm64, each module will be identified by the order in which the
+modules are added.
+The 1st module: dom0 kernel image
+The 2nd module: dom0 ramdisk (optional)
@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 0/4] arm64, xen: add xen_boot support into grup-mkconfig
From: Fu Wei <fu@linaro.org> This patchset add xen_boot support into grup-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands. This patchset has been tested on Foudation model with a bug fix: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html ChangeLog: v3: reorder the patches update the introduction of xen_module commands in docs/grub.texi v2: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00282.html add "--nounzip" option support in xen_module use "feature_xen_boot" instead of "grub_xen_boot" update the introduction of xen boot commands in docs/grub.texi v1 :first upstream patchset: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html Fu Wei (4): i386,xen: Add xen_hypervisor and xen_module aliases for i386 arm64: add "--nounzip" option support in xen_module command * util/grub.d/20_linux_xen.in: Add xen_boot command support arm64: update the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 33 ++--- grub-core/loader/arm64/xen_boot.c | 17 + grub-core/loader/i386/xen.c | 7 +++ grub-core/normal/main.c | 2 +- util/grub.d/20_linux_xen.in | 13 ++--- 5 files changed, 45 insertions(+), 27 deletions(-) -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 1/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386
From: Fu Wei <fu@linaro.org>
Signed-off-by: Fu Wei <fu@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Andrei
On 26 February 2016 at 13:24, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>
>
> Отправлено с iPhone
>
>> 26 февр. 2016 г., в 7:48, Fu Wei <fu@linaro.org> написал(а):
>>
>> Hi Andrei
>>
>>> On 26 February 2016 at 01:34, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>>> 25.02.2016 09:39, fu@linaro.org пишет:
>>>> From: Fu Wei <fu@linaro.org>
>>>>
>>>> delete: xen_linux, xen_initrd, xen_xsm
>>>> add: xen_module
>>>>
>>>> This update bases on
>>>>commit 0edd750e50698854068358ea53528100a9192902
>>>>Author: Vladimir Serbinenko <phco...@gmail.com>
>>>>Date: Fri Jan 22 10:18:47 2016 +0100
>>>>
>>>>xen_boot: Remove obsolete module type distinctions.
>>>>
>>>> Signed-off-by: Fu Wei <fu@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 fil
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Doug, On 26 February 2016 at 06:26, Doug Goldstein <car...@cardoe.com> wrote: > On 2/25/16 12:39 AM, fu@linaro.org wrote: >> From: Fu Wei <fu@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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Andrei
On 26 February 2016 at 12:48, Fu Wei <fu@linaro.org> wrote:
> Hi Andrei
>
> On 26 February 2016 at 01:34, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>> 25.02.2016 09:39, fu@linaro.org пишет:
>>> From: Fu Wei <fu@linaro.org>
>>>
>>> delete: xen_linux, xen_initrd, xen_xsm
>>> add: xen_module
>>>
>>> This update bases on
>>> commit 0edd750e50698854068358ea53528100a9192902
>>> Author: Vladimir Serbinenko <phco...@gmail.com>
>>> Date: Fri Jan 22 10:18:47 2016 +0100
>>>
>>> xen_boot: Remove obsolete module type distinctions.
>>>
>>> Signed-off-by: Fu Wei <fu@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 61221
Re: [Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
Hi Andrei
On 26 February 2016 at 01:34, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 25.02.2016 09:39, fu@linaro.org пишет:
>> From: Fu Wei <fu@linaro.org>
>>
>> delete: xen_linux, xen_initrd, xen_xsm
>> add: xen_module
>>
>> This update bases on
>> commit 0edd750e50698854068358ea53528100a9192902
>> Author: Vladimir Serbinenko <phco...@gmail.com>
>> Date: Fri Jan 22 10:18:47 2016 +0100
>>
>> xen_boot: Remove obsolete module type distinctions.
>>
>> Signed-off-by: Fu Wei <fu@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH 1/3] arm64: add grub_xen_boot env to indicate that we have xen_* commands
Hi Andrei.
On 25 February 2016 at 02:12, Andrei Borzenkov <arvidj...@gmail.com> wrote:
> 24.02.2016 21:01, fu@linaro.org пишет:
>> From: Fu Wei <fu@linaro.org>
>>
>> Signed-off-by: Fu Wei <fu@linaro.org>
>> ---
>> grub-core/loader/arm64/xen_boot.c | 8
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/grub-core/loader/arm64/xen_boot.c
>> b/grub-core/loader/arm64/xen_boot.c
>> index 8ae43d7..ef03111 100644
>> --- a/grub-core/loader/arm64/xen_boot.c
>> +++ b/grub-core/loader/arm64/xen_boot.c
>> @@ -20,6 +20,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -490,10 +491,17 @@ GRUB_MOD_INIT (xen_boot)
>> grub_register_command ("xen_module", grub_cmd_xen_module, 0,
>> N_("Load a xen module."));
>>my_mod = mod;
>> +
>> +/* setup a env to indicate that
>> + * we have xen_* commands.
>> + */
>> + grub_env_set ("grub_xen_boot", "y");
>> + grub_env_export ("grub_xen_boot");
>> }
>
> Please define feature for it, see grub-core/normal/main.c.
Thanks for your suggestion
>
>>
>> GRUB_MOD_FINI (xen_boot)
>> {
>>grub_unregister_command (cmd_xen_hypervisor);
>>grub_unregister_command (cmd_xen_module);
>> + grub_env_unset ("grub_xen_boot");
>> }
>>
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 0/4] arm64, xen: add xen_boot support into grup-mkconfig
From: Fu Wei <fu@linaro.org> This patchset add xen_boot support into grup-mkconfig for generating xen boot entrances automatically Also update the docs/grub.texi for new xen_boot commands. This patchset has been tested on Foudation model with a bug fix: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00205.html ChangeLog: v2: add "--nounzip" option support in xen_module use "feature_xen_boot" instead of "grub_xen_boot" update the introduction of xen boot commands in docs/grub.texi v1 :first upstream patchset: http://lists.gnu.org/archive/html/grub-devel/2016-02/msg00264.html Fu Wei (4): arm64: add "--nounzip" option support in xen_module command * util/grub.d/20_linux_xen.in: Add xen_boot command support i386,xen: Add xen_hypervisor and xen_module aliases for i386 arm64: update the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 32 +--- grub-core/loader/arm64/xen_boot.c | 17 + grub-core/loader/i386/xen.c | 7 +++ grub-core/normal/main.c | 2 +- util/grub.d/20_linux_xen.in | 13 ++--- 5 files changed, 44 insertions(+), 27 deletions(-) -- 2.5.0 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 2/4] * util/grub.d/20_linux_xen.in: Add xen_boot command support
From: Fu Wei <fu@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@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 4/4] arm64: update the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
delete: xen_linux, xen_initrd, xen_xsm
add: xen_module
This update bases on
commit 0edd750e50698854068358ea53528100a9192902
Author: Vladimir Serbinenko <phco...@gmail.com>
Date: Fri Jan 22 10:18:47 2016 +0100
xen_boot: Remove obsolete module type distinctions.
Signed-off-by: Fu Wei <fu@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 1/4] arm64: add "--nounzip" option support in xen_module command
From: Fu Wei <fu@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@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
#include
#include
+#include
#include
#include
#include
@@ -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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v2 3/4] i386, xen: Add xen_hypervisor and xen_module aliases for i386
From: Fu Wei <fu@linaro.org>
Signed-off-by: Fu Wei <fu@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH GRUB] Allow initrd concatenation on ARM64
Hi Vladimir,
Sorry for late response, I turned to work on other tasks and haven't
sent the test resulted to you.
Last weekend I got a email from Julien about a xen boot problem on
arm64, I just noticed that you have simplified the xen_boot.c to drop
xen_linux, xen_initrd and xen_xsm.
By this way, we still can boot xen on arm64 by loading modules in a
specific order, and simplified the xen boot code. I guess that is also
a good way to make a patch for updating boot entrance in grub.cfg.
Is this still OK to update grub.cfg by this way:
(1) in xen_boot.c
grub_env_set ("grub_xen_boot", "y");
grub_env_export ("grub_xen_boot");
(2)in util/grub.d/20_linux_xen.in
diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in
index f532fb9..49aa709 100644
--- a/util/grub.d/20_linux_xen.in
+++ b/util/grub.d/20_linux_xen.in
@@ -120,16 +120,16 @@ linux_entry ()
else
xen_rm_opts="no-real-mode edd=off"
fi
- multiboot ${rel_xen_dirname}/${xen_basename} placeholder ${xen_args}
\${xen_rm_opts}
+ ${multiboot_cmd} ${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_linux_cmd} ${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_initrd_cmd} ${rel_dirname}/${initrd}
EOF
fi
sed "s/^/$submenu_indentation/" << EOF
@@ -185,6 +185,16 @@ case "$machine" in
*) GENKERNEL_ARCH="$machine" ;;
esac
+if [ "x$grub_xen_boot" != xy ]; then
+ multiboot_cmd="multiboot"
+ module_linux_cmd="module"
+ module_initrd_cmd="module --nounzip"
+else
+ multiboot_cmd="xen_hypervisor"
+ module_linux_cmd="xen_module"
+ module_initrd_cmd="xen_module"
+fi
+
# Extra indentation to add to menu entries in a submenu. We're not in a submenu
# yet, so it's empty. In a submenu it will be equal to '\t' (one tab).
submenu_indentation=""
(3)add xen_* aliases on x86,
diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
index c4d9689..b88d51b 100644
--- a/grub-core/loader/i386/xen.c
+++ b/grub-core/loader/i386/xen.c
@@ -696,10 +696,14 @@ GRUB_MOD_INIT (xen)
0, N_("Load Linux."));
cmd_multiboot = grub_register_command ("multiboot", grub_cmd_xen,
0, N_("Load Linux."));
+ cmd_multiboot = 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_module = grub_register_command ("xen_module", grub_cmd_module,
+ 0, N_("Load module."));
my_mod = mod;
}
Please correct me if I misunderstand something, thanks for your help, :-)
and sorry for delay :-(
On 12 November 2015 at 21:48, Vladimir 'φ-coder/phcoder' Serbinenko
<phco...@gmail.com> wrote:
> On 12.11.2015 14:27, Ian Campbell wrote:
>> On Thu, 2015-11-12 at 14:08 +0100, Vladimir 'φ-coder/phcoder' Serbinenko
>> wrote:
>>> While on it also change "xen_linux" to "xen_kernel" to be vendor-neutral
>>> Could someone test please? I only compile-tested it
>>
>> I was expecting this patch to include a change
>> to ./util/grub.d/20_linux_xen.in to update the naming there, but it looks
>> like that aspect of the original series isn't in tree yet?
>>
> We need to figure out what we should do on x86 wrt multiboot vs
> multiboot2 before adapting 20_linux_xen
>> BTW, you have a stray "linux" in the description of the (now) xen_kernel
>> command.
>>
> Fixed locally, thank you
>> Ian.
>>
>> .
>>
>
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH] arm64: xen_boot: Fix xen boot using Grub on AARCH64
Hi Julien,
On 20 February 2016 at 00:28, Julien Grall <julien.gr...@linaro.org> wrote:
> Xen is currently crashing because of malformed compatible property for
> the boot module. This is because the property string is not
> null-terminated as requested by the ePAR spec.
> ---
> grub-core/loader/arm64/xen_boot.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/grub-core/loader/arm64/xen_boot.c
> b/grub-core/loader/arm64/xen_boot.c
> index a914eb8..8ae43d7 100644
> --- a/grub-core/loader/arm64/xen_boot.c
> +++ b/grub-core/loader/arm64/xen_boot.c
> @@ -156,7 +156,7 @@ prepare_xen_module_params (struct xen_boot_binary
> *module, void *xen_boot_fdt)
>grub_fdt_add_subnode (xen_boot_fdt, chosen_node, module_name);
>
>retval = grub_fdt_set_prop (xen_boot_fdt, module_node, "compatible",
> - MODULE_CUSTOM_COMPATIBLE,
> sizeof(MODULE_CUSTOM_COMPATIBLE) - 1);
> + MODULE_CUSTOM_COMPATIBLE,
> sizeof(MODULE_CUSTOM_COMPATIBLE));
>if (retval)
> return grub_error (GRUB_ERR_IO, "failed to update FDT");
>
> --
> 1.9.1
I have tested it. yes, xen will crash without this patch.
Tested-by: Fu Wei <fu@linaro.org>
BTW, since Vladimir has simplified the xen boot code , and Now Xen
distinguishes modules by order.
--
menuentry 'Foundation Model Xen test with initramfs' {
xen_hypervisor /xen -- no-bootscrub console=dtuart conswitch=x
dtuart=serial0 dom0_mem=512M dom0_max_vcpus=2
xen_module /dom0_kernel_Image console=hvc0 root=/dev/ram0 ro
xen_module /dom0_initramfs.cpio
xen_module /xsm
devicetree /fvp-base-gicv2-psci.dtb
}
-
Maybe we should update doc to coordinate with this change.
And another problem is: How does XEN identify XSM?
Test with the config file above, I got "(XEN) MODULE[3]:
0008fabb4000 - 0008fabb65e7 Unknown"
Please correct me if I miss something.
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH GRUB] Allow initrd concatenation on ARM64
Hi Vladimir, OK, I will test it. On 12 November 2015 at 21:08, Vladimir 'φ-coder/phcoder' Serbinenko <phco...@gmail.com> wrote: > While on it also change "xen_linux" to "xen_kernel" to be vendor-neutral > Could someone test please? I only compile-tested it -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] arm64: Add the missing license macro in fdt module
From: Fu Wei <fu@linaro.org>
Signed-off-by: Fu Wei <fu@linaro.org>
---
grub-core/loader/arm64/fdt.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/grub-core/loader/arm64/fdt.c b/grub-core/loader/arm64/fdt.c
index 5202c14..901bd7b 100644
--- a/grub-core/loader/arm64/fdt.c
+++ b/grub-core/loader/arm64/fdt.c
@@ -25,6 +25,8 @@
#include
#include
+GRUB_MOD_LICENSE ("GPLv3+");
+
static void *loaded_fdt;
static void *fdt;
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] arm64: Add the introduction of xen boot commands in docs/grub.texi
From: Fu Wei <fu@linaro.org>
xen_hypervisor
xen_linux
xen_initrd
xen_xsm
Signed-off-by: Fu Wei <fu@linaro.org>
---
docs/grub.texi | 38 ++
1 file changed, 38 insertions(+)
diff --git a/docs/grub.texi b/docs/grub.texi
index db765a3..1df3db2 100644
--- a/docs/grub.texi
+++ b/docs/grub.texi
@@ -3857,6 +3857,11 @@ you forget a command, you can run the command
@command{help}
@comment * vbeinfo:: List available video modes
* verify_detached:: Verify detached digital signature
* 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
@end menu
@@ -5120,6 +5125,39 @@ successfully. If validation fails, it is set to a
non-zero value.
List available video modes. If resolution is given, show only matching modes.
@end deffn
+@node xen_hypervisor
+@subsection xen_hypervisor
+
+@deffn Command xen_hypervisor file [arguments] @dots{}
+Load a Xen hypervisor binary from @var{file}. The rest of the line is passed
+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
+
+@deffn Command xen_linux file [arguments]
+Load a dom0 kernel image for xen hypervisor at the booting process of xen.
+The rest of the line is passed verbatim as the module command line.
+@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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] arm64: clean up a useless variable in xen_boot.c
From: Fu Wei <fu@linaro.org>
This patch delete "file_name_index" variable and related comment.
They are for xen_module command which has been deleted.
Signed-off-by: Fu Wei <fu@linaro.org>
---
grub-core/loader/arm64/xen_boot.c | 19 +--
1 file changed, 5 insertions(+), 14 deletions(-)
diff --git a/grub-core/loader/arm64/xen_boot.c
b/grub-core/loader/arm64/xen_boot.c
index fc5bb0c..d1a2189 100644
--- a/grub-core/loader/arm64/xen_boot.c
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -136,16 +136,10 @@ xen_boot_address_align (grub_addr_t start, grub_size_t
align)
return (align ? (ALIGN_UP (start, align)) : start);
}
-/* Parse the option of xen_module command. For now, we support
- (1) --type
- We also set up the type of module in this function.
- If there are some "--type" options in the command line,
- we make a custom compatible stream in this function. */
+/* set module type according to command name. */
static grub_err_t
-set_module_type (grub_command_t cmd, struct xen_boot_binary *module, int
*file_name_index)
+set_module_type (grub_command_t cmd, struct xen_boot_binary *module)
{
- *file_name_index = 0;
-
if (!grub_strcmp (cmd->name, "xen_linux"))
module->node_info.type = MODULE_IMAGE;
else if (!grub_strcmp (cmd->name, "xen_initrd"))
@@ -440,7 +434,6 @@ grub_cmd_xen_module (grub_command_t cmd, int argc, char
*argv[])
{
struct xen_boot_binary *module = NULL;
- int file_name_index = 0;
grub_file_t file = 0;
if (!argc)
@@ -462,8 +455,7 @@ grub_cmd_xen_module (grub_command_t cmd, int argc, char
*argv[])
return grub_errno;
/* process all the options and get module type */
- if (set_module_type (cmd, module, _name_index) !=
- GRUB_ERR_NONE)
+ if (set_module_type (cmd, module) != GRUB_ERR_NONE)
goto fail;
switch (module->node_info.type)
{
@@ -491,12 +483,11 @@ grub_cmd_xen_module (grub_command_t cmd, int argc, char
*argv[])
module->name, module->node_info.compat_string,
module->node_info.compat_string_size);
- file = grub_file_open (argv[file_name_index]);
+ file = grub_file_open (argv[0]);
if (!file)
goto fail;
- xen_boot_binary_load (module, file, argc - file_name_index,
- argv + file_name_index);
+ xen_boot_binary_load (module, file, argc, argv);
if (grub_errno == GRUB_ERR_NONE)
grub_list_push (GRUB_AS_LIST_P (_head), GRUB_AS_LIST (module));
--
2.5.0
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] arm64: Add xen_boot module file
Hi Ian, On 3 November 2015 at 23:22, Ian Campbell <ian.campb...@citrix.com> wrote: > On Tue, 2015-11-03 at 22:57 +0800, Fu Wei wrote: >> Hi Vladimir, >> >> After discussing with Ian Campbell, Since we already can load all >> the necessary binaries for Xen boot on arm64 for now, we don't really >> need "xen_module" command now. >> But maybe someday , xen need a new type of binary in boot time, then >> we still need this support. > > You mean support for "--type" passed to the xen_module command, right? I > thought the xen_module stuff had been applied. Or am I misunderstanding > which bits have been applied? Actually, I mean: xen-module command is for "--type" support. If we don't need "--type" now, we can delete xen-module code(which has been deleted by Vladimir from my patch, so now, the upstream grub has not --type support). Vladimir has applied most of my patch, except xen-module command code. > >> So I will submit a "xen_module" command patch soon, in case we need >> it. > > Just to clarify, my suggestion was to repost the bits which were omitted > from the prior patches just so that they are available in the ML archives > etc should anyone ever want to resurrect them in the future. yes, that is what I am gonna do. > > Ian. > -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
[Xen-devel] [PATCH] arm64: Fix the bug in fdt module
From: Fu Wei <fu@linaro.org>
This patch goes with commit:
4d0cb755387d6f109b901386ed4d3d475df239fe
arm64: Move FDT functions to separate module
linux and xen_boot modules can't work without this patch.
Signed-off-by: Fu Wei <fu@linaro.org>
---
grub-core/Makefile.core.def | 1 +
grub-core/loader/arm64/fdt.c | 5 +
2 files changed, 6 insertions(+)
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 2ef10d1..3ea4e49 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1674,6 +1674,7 @@ module = {
module = {
name = fdt;
arm64 = loader/arm64/fdt.c;
+ fdt = lib/fdt.c;
enable = arm64;
};
diff --git a/grub-core/loader/arm64/fdt.c b/grub-core/loader/arm64/fdt.c
index 5202c14..d160ca0 100644
--- a/grub-core/loader/arm64/fdt.c
+++ b/grub-core/loader/arm64/fdt.c
@@ -25,6 +25,10 @@
#include
#include
+GRUB_MOD_LICENSE ("GPLv3+");
+
+static grub_dl_t my_mod;
+
static void *loaded_fdt;
static void *fdt;
@@ -177,6 +181,7 @@ GRUB_MOD_INIT (fdt)
cmd_devicetree =
grub_register_command ("devicetree", grub_cmd_devicetree, 0,
N_("Load DTB file."));
+ my_mod = mod;
}
GRUB_MOD_FINI (fdt)
--
2.4.3
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] arm64: Add xen_boot module file
Hi Vladimir,
After discussing with Ian Campbell, Since we already can load all
the necessary binaries for Xen boot on arm64 for now, we don't really
need "xen_module" command now.
But maybe someday , xen need a new type of binary in boot time, then
we still need this support.
So I will submit a "xen_module" command patch soon, in case we need it.
Great thanks ! :-)
On 30 October 2015 at 16:08, Fu Wei <fu@linaro.org> wrote:
> Hi Vladimir,
>
> yes, Thanks for your modification :-)
>
> I just follow the xen boot protocol :
> http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
>
> xen_module is just for "--type" option, I will discuss this with Xen
> developer for this.
> If we need this option, I will resubmit it :-)
>
> Great thanks!
>
> On 29 October 2015 at 22:27, Vladimir 'φ-coder/phcoder' Serbinenko
> <phco...@gmail.com> wrote:
>> Committed without the xen_module command. Its argument parsing was
>> non-trivial and I don't quite get what its intent is. Can you resubmit?
>> On 23.07.2015 07:16, fu@linaro.org wrote:
>>> From: Fu Wei <fu@linaro.org>
>>>
>>> grub-core/loader/arm64/xen_boot.c
>>>
>>> - This adds support for the Xen boot on ARM specification for arm64.
>>> - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm
>>> to load different binaries for xen boot;
>>> Introduce xen_module to load common or custom module for xen boot.
>>> - This Xen boot support is a separated module for aarch64,
>>> but reuse the existing code of devicetree in linux module.
>>>
>>> Signed-off-by: Fu Wei <fu@linaro.org>
>>> ---
>>> grub-core/Makefile.core.def | 7 +
>>> grub-core/loader/arm64/xen_boot.c | 685
>>> ++
>>> 2 files changed, 692 insertions(+)
>>>
>>> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
>>> index a6101de..796f7e9 100644
>>> --- a/grub-core/Makefile.core.def
>>> +++ b/grub-core/Makefile.core.def
>>> @@ -1648,6 +1648,13 @@ module = {
>>> };
>>>
>>> module = {
>>> + name = xen_boot;
>>> + common = lib/cmdline.c;
>>> + arm64 = loader/arm64/xen_boot.c;
>>> + enable = arm64;
>>> +};
>>> +
>>> +module = {
>>>name = linux;
>>>x86 = loader/i386/linux.c;
>>>xen = loader/i386/xen.c;
>>> diff --git a/grub-core/loader/arm64/xen_boot.c
>>> b/grub-core/loader/arm64/xen_boot.c
>>> new file mode 100644
>>> index 000..33a65dd
>>> --- /dev/null
>>> +++ b/grub-core/loader/arm64/xen_boot.c
>>> @@ -0,0 +1,685 @@
>>> +/*
>>> + * GRUB -- GRand Unified Bootloader
>>> + * Copyright (C) 2014 Free Software Foundation, Inc.
>>> + *
>>> + * GRUB is free software: you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation, either version 3 of the License, or
>>> + * (at your option) any later version.
>>> + *
>>> + * GRUB is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>>> + * GNU General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU General Public License
>>> + * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
>>> + */
>>> +
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include
>>> +#include/* required by struct xen_hypervisor_header */
>>> +#include
>>> +#include
>>> +
>>> +GRUB_MOD_LICENSE ("GPLv3+");
>>> +
>>> +#define XEN_HYPERVISOR_NAME "xen_hypervisor"
>>> +
>>> +#define MODULE_DEFAULT_ALIGN (0x0)
>>> +#define MODULE_IMAGE_MIN_ALIGN MODULE_DEFAULT_ALIGN
>>> +#define MODULE_INITRD_MIN_ALIGN MODULE_DEFAULT_ALIGN
>>> +#define MODULE_XSM_MIN_ALIGN MODULE_DEFAULT_ALIGN
>>> +#define MODULE_CUSTOM_MIN_ALIGN MODULE_DEFAULT_ALIGN
>>> +
>>> +/* #define MODU
Re: [Xen-devel] [PATCH v3 3/4] * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64
Hi Vladimir,
Great thanks for your suggestion! :-)
On 29 October 2015 at 23:25, Vladimir 'φ-coder/phcoder' Serbinenko
<phco...@gmail.com> wrote:
>> +if [ "x$machine" != xaarch64 ]; then
>> + multiboot_cmd="multiboot"
>> + module_linux_cmd="module"
>> + module_initrd_cmd="module --nounzip"
>> +else
>> + multiboot_cmd="xen_hypervisor"
>> + module_linux_cmd="xen_linux"
>> + module_initrd_cmd="xen_initrd"
>> +fi
>> +
> Please do not hardcode an assumption that grub-mkconfig is executed on
> the same machine as GRUB is booted. I know that we have instances of
> such assumption in some cases but we'd like to eliminate them. Alternatives:
> - Check arch on boot time
> - Check that new xen commands are supported (define a new feature)
> Please add xen_* aliases on x86 as well
I would like to go this way, but could you provide some help or a
little example for :
(1) How to check the new xen commands(or xen_boot module)
(2)add xen_* aliases on x86, is that like something below?
diff --git a/grub-core/loader/i386/xen.c b/grub-core/loader/i386/xen.c
index c4d9689..b88d51b 100644
--- a/grub-core/loader/i386/xen.c
+++ b/grub-core/loader/i386/xen.c
@@ -696,10 +696,14 @@ GRUB_MOD_INIT (xen)
0, N_("Load Linux."));
cmd_multiboot = grub_register_command ("multiboot", grub_cmd_xen,
0, N_("Load Linux."));
+ cmd_multiboot = 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_module = grub_register_command ("xen_linux", grub_cmd_module,
+ 0, N_("Load module."));
my_mod = mod;
}
But how to deal with xen_initrd ?
Could you help me ?
Great 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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 1/4] arm64: Add and export some accessor functions for xen boot
Hi Vladimir,
Good idea! I can see your patch for it in master branch.
Great thanks for your help, I will try this ASAP :-)
On 29 October 2015 at 20:03, Vladimir 'φ-coder/phcoder' Serbinenko
<phco...@gmail.com> wrote:
> On 23.07.2015 07:16, fu@linaro.org wrote:
>> From: Fu Wei <fu@linaro.org>
>>
>> Add accessor functions of "loaded" flag in
>> grub-core/loader/arm64/linux.c.
>>
>> Export accessor functions of "loaded" flag and
>> grub_linux_get_fdt function in include/grub/arm64/linux.h.
>>
>> Purpose: Reuse the existing code of devicetree in linux module.
>>
>> Signed-off-by: Fu Wei <fu@linaro.org>
>> ---
>> grub-core/loader/arm64/linux.c | 13 +
>> include/grub/arm64/linux.h | 6 +-
>> 2 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
>> index 987f5b9..cf6026e 100644
>> --- a/grub-core/loader/arm64/linux.c
>> +++ b/grub-core/loader/arm64/linux.c
>> @@ -48,6 +48,19 @@ static grub_addr_t initrd_end;
>> static void *loaded_fdt;
>> static void *fdt;
>>
>> +/* The accessor functions for "loaded" flag */
>> +int
>> +grub_linux_get_loaded (void)
>> +{
>> + return loaded;
>> +}
>> +
>> +void
>> +grub_linux_set_loaded (int loaded_flag)
>> +{
>> + loaded = loaded_flag;
>> +}
>> +
> Accessor functions are usually useless in GRUB. We have no public API to
> respect. So it only adds clutter. Also "loaded" flag is static for а
> good reason: it's specific to linux.c. I'm going to move fdt part to
> fdt.c and have uniform interface for both linux and xen.
>> static void *
>> get_firmware_fdt (void)
>> {
>> diff --git a/include/grub/arm64/linux.h b/include/grub/arm64/linux.h
>> index 65796d9..20058f3 100644
>> --- a/include/grub/arm64/linux.h
>> +++ b/include/grub/arm64/linux.h
>> @@ -43,10 +43,14 @@ struct grub_arm64_linux_kernel_header
>> };
>>
>> /* Declare the functions for getting dtb and checking/booting image */
>> -void *grub_linux_get_fdt (void);
>> grub_err_t grub_arm64_uefi_check_image (struct
>> grub_arm64_linux_kernel_header
>> *lh);
>> grub_err_t grub_arm64_uefi_boot_image (grub_addr_t addr, grub_size_t size,
>> char *args);
>>
>> +/* Export the accessor functions for gettin dtb and "loaded" flag */
>> +void EXPORT_FUNC (*grub_linux_get_fdt) (void);
>> +int EXPORT_FUNC (grub_linux_get_loaded) (void);
>> +void EXPORT_FUNC (grub_linux_set_loaded) (int loaded_flag);
>> +
> EXPORT_* are necessary only for core. Not for modules.
>> #endif /* ! GRUB_LINUX_CPU_HEADER */
>>
>
>
--
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
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 2/4] arm64: Add xen_boot module file
Hi Vladimir,
yes, Thanks for your modification :-)
I just follow the xen boot protocol :
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
xen_module is just for "--type" option, I will discuss this with Xen
developer for this.
If we need this option, I will resubmit it :-)
Great thanks!
On 29 October 2015 at 22:27, Vladimir 'φ-coder/phcoder' Serbinenko
<phco...@gmail.com> wrote:
> Committed without the xen_module command. Its argument parsing was
> non-trivial and I don't quite get what its intent is. Can you resubmit?
> On 23.07.2015 07:16, fu@linaro.org wrote:
>> From: Fu Wei <fu@linaro.org>
>>
>> grub-core/loader/arm64/xen_boot.c
>>
>> - This adds support for the Xen boot on ARM specification for arm64.
>> - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm
>> to load different binaries for xen boot;
>> Introduce xen_module to load common or custom module for xen boot.
>> - This Xen boot support is a separated module for aarch64,
>> but reuse the existing code of devicetree in linux module.
>>
>> Signed-off-by: Fu Wei <fu@linaro.org>
>> ---
>> grub-core/Makefile.core.def | 7 +
>> grub-core/loader/arm64/xen_boot.c | 685
>> ++
>> 2 files changed, 692 insertions(+)
>>
>> diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
>> index a6101de..796f7e9 100644
>> --- a/grub-core/Makefile.core.def
>> +++ b/grub-core/Makefile.core.def
>> @@ -1648,6 +1648,13 @@ module = {
>> };
>>
>> module = {
>> + name = xen_boot;
>> + common = lib/cmdline.c;
>> + arm64 = loader/arm64/xen_boot.c;
>> + enable = arm64;
>> +};
>> +
>> +module = {
>>name = linux;
>>x86 = loader/i386/linux.c;
>>xen = loader/i386/xen.c;
>> diff --git a/grub-core/loader/arm64/xen_boot.c
>> b/grub-core/loader/arm64/xen_boot.c
>> new file mode 100644
>> index 000..33a65dd
>> --- /dev/null
>> +++ b/grub-core/loader/arm64/xen_boot.c
>> @@ -0,0 +1,685 @@
>> +/*
>> + * GRUB -- GRand Unified Bootloader
>> + * Copyright (C) 2014 Free Software Foundation, Inc.
>> + *
>> + * GRUB is free software: you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License as published by
>> + * the Free Software Foundation, either version 3 of the License, or
>> + * (at your option) any later version.
>> + *
>> + * GRUB is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with GRUB. If not, see <http://www.gnu.org/licenses/>.
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include/* required by struct xen_hypervisor_header */
>> +#include
>> +#include
>> +
>> +GRUB_MOD_LICENSE ("GPLv3+");
>> +
>> +#define XEN_HYPERVISOR_NAME "xen_hypervisor"
>> +
>> +#define MODULE_DEFAULT_ALIGN (0x0)
>> +#define MODULE_IMAGE_MIN_ALIGN MODULE_DEFAULT_ALIGN
>> +#define MODULE_INITRD_MIN_ALIGN MODULE_DEFAULT_ALIGN
>> +#define MODULE_XSM_MIN_ALIGN MODULE_DEFAULT_ALIGN
>> +#define MODULE_CUSTOM_MIN_ALIGN MODULE_DEFAULT_ALIGN
>> +
>> +/* #define MODULE_IMAGE_COMPATIBLE "xen,linux-image\0xen,module"
>> +#define MODULE_INITRD_COMPATIBLE "xen,linux-image\0xen,module"
>> +#define MODULE_XSM_COMPATIBLE "xen,xsm-policy\0xen,module"
>> +#define MODULE_CUSTOM_COMPATIBLE "xen,module" */
>> +#define MODULE_IMAGE_COMPATIBLE "multiboot,kernel\0multiboot,module"
>> +#define MODULE_INITRD_COMPATIBLE "multiboot,ramdisk\0multiboot,module"
>> +#define MODULE_XSM_COMPATIBLE "xen,xsm-policy\0multiboot,module"
>> +#define MODULE_CUSTOM_COMPATIBLE "multiboot,module"
>> +
>> +/* This maximum size is defined in Power.org ePAPR V1.1
>> + * https://www.power.org/documentation/epapr-version-1-1/
>> + * 2.2.1.1 Node Name Requirements
>> + * node-name@unit-address
>> + * 31 + 1(@) + 16(64bit a
Re: [Xen-devel] [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)
Hi Stefano, I have tried my grub on Foundation model, but I did not get this error, I guess that is the UEFI problem ? On 1 October 2015 at 00:00, Stefano Stabellini <stefano.stabell...@eu.citrix.com> wrote: > Hi Fu, > > I backported your patches to the CentOS aarch64 grub2 rpm. I am testing > it on X-Gene with EFI firmware. It works fine when booting Xen, but > booting native kernels (no Xen) doesn't work anymore. Grub prints > > error: out of memory. > > Press any key to continue... > > grub is still able to continue and load Linux, but then the kernel fails > to boot with "Cannot open root device", even though the grub config is > still same as before and the rootfs (which is xfs) hasn't changed. > Reverting the patches solved the problem. > > Do you have any ideas on what is causing the issue? Maybe the initramfs > hasn't been properly loaded? > > > Thanks, > > Stefano > > > On Tue, 8 Sep 2015, Fu Wei wrote: >> Hi Vladimir, >> >> Do you have any suggestion on this patchset? >> Do I need to improve anything? >> >> Great thanks for your help. >> >> On 4 August 2015 at 16:34, Fu Wei <fu@linaro.org> wrote: >> > Hi Vladimir, >> > >> > this patchset follows all your comment of v2 patchset. >> > Do you have any suggestion on this patchset? >> > >> > Great thanks for your help. >> > >> > >> > On 23 July 2015 at 13:16, <fu@linaro.org> wrote: >> >> From: Fu Wei <fu@linaro.org> >> >> >> >> - This adds support for the Xen boot on ARM specification for arm64. >> >> >> >> - Add and export some accessor functions of "loaded" flag and >> >> grub_linux_get_fdt function in include/grub/arm64/linux.h for xen >> >> boot. >> >> >> >> - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm >> >> to load different binaries for xen boot. >> >> Introduce xen_module to load common or custom module for xen boot. >> >> >> >> - This Xen boot support is a separated module for aarch64, >> >> but reuse the existing code of devicetree in linux module. >> >> >> >> - Add the support of xen_hypervisor, xen_linux and xen_initrd >> >> in util/grub.d/20_linux_xen.in >> >> >> >> - Add the introduction of all xen boot commands in docs/grub.texi >> >> >> >> - The example of this support is > >> the Foundation FVP model> >> >> >> >> https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP_model_by_GRUB >> >> >> >> Changelog: >> >> v3: create separate module for xen boot: xen_boot >> >> create separate commands for different types of module >> >> delete order-dependent for commands of xen module >> >> simplify the code >> >> >> >> v2: remove the patches which have been accepted. >> >> according to Vladimir's suggestion, change the command manes >> >> and relevant code: >> >> multiboot-->xen_hypervisor >> >> module-->xen_module >> >> improve the option parsing support for xen_hypervisor/xen_module >> >> commands. >> >> add a patch for adding xen_hypervisor/xen_module support >> >> in util/grub.d/20_linux_xen.in. >> >> update docs/grub.texi patch for the new command names. >> >> >> >> v1: The first version upstream patchset to grub-devel mailing list >> >> >> >> >> >> Fu Wei (4): >> >> arm64: Add and export some accessor functions for xen boot >> >> arm64: Add xen_boot module file >> >> * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 >> >> arm64: Add the introduction of xen boot commands in docs/grub.texi >> >> >> >> docs/grub.texi| 56 >> >> grub-core/Makefile.core.def | 7 + >> >> grub-core/loader/arm64/linux.c| 13 + >> >> grub-core/loader/arm64/xen_boot.c | 685 >> >> ++ >> >> include/grub/arm64/linux.h| 6 +- >> >> util/grub.d/20_linux_xen.in | 16 +- >> >> 6 files changed, 779 insertions(+), 4 deletions(-) >> >> create mode 100644 grub-core/loader/arm64/xen_boot.c >> >> >> >> -- >> >> 1.8.3.1 &g
Re: [Xen-devel] [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)
Hi Stefano, Sorry for late response, I will try to test my latest patch ASAP. but I don't see this problem before. will let you know the result , thanks for your testing On 2 October 2015 at 00:19, Stefano Stabellini <stefano.stabell...@eu.citrix.com> wrote: > On Wed, 30 Sep 2015, Stefano Stabellini wrote: >> Hi Fu, >> >> I backported your patches to the CentOS aarch64 grub2 rpm. I am testing >> it on X-Gene with EFI firmware. It works fine when booting Xen, but >> booting native kernels (no Xen) doesn't work anymore. Grub prints >> >> error: out of memory. >> >> Press any key to continue... >> >> grub is still able to continue and load Linux, but then the kernel fails >> to boot with "Cannot open root device", even though the grub config is >> still same as before and the rootfs (which is xfs) hasn't changed. >> Reverting the patches solved the problem. >> >> Do you have any ideas on what is causing the issue? Maybe the initramfs >> hasn't been properly loaded? > > It looks like the following chunk of commit > f8451af8251a3866cb8b7307b9917dd5d34fbd0a "arm64: Export useful functions > from linux.c" causes troubles: > > > diff --git a/grub-core/loader/linux.c b/grub-core/loader/linux.c > index 117232f..a63a11a 100644 > --- a/grub-core/loader/linux.c > +++ b/grub-core/loader/linux.c > @@ -205,7 +205,8 @@ grub_initrd_init (int argc, char *argv[], >initrd_ctx->nfiles++; >initrd_ctx->components[i].size > = grub_file_size (initrd_ctx->components[i].file); > - initrd_ctx->size += ALIGN_UP (initrd_ctx->components[i].size, 4); > + if (argc != 1) > + initrd_ctx->size += ALIGN_UP (initrd_ctx->components[i].size, 4); > } > >if (newc) > > > Simply removing this change seems to fix the issue and Xen still boots > fine. -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)
Hi Vladimir, Do you have any suggestion on this patchset? Do I need to improve anything? Great thanks for your help. On 4 August 2015 at 16:34, Fu Wei <fu@linaro.org> wrote: > Hi Vladimir, > > this patchset follows all your comment of v2 patchset. > Do you have any suggestion on this patchset? > > Great thanks for your help. > > > On 23 July 2015 at 13:16, <fu....@linaro.org> wrote: >> From: Fu Wei <fu@linaro.org> >> >> - This adds support for the Xen boot on ARM specification for arm64. >> >> - Add and export some accessor functions of "loaded" flag and >> grub_linux_get_fdt function in include/grub/arm64/linux.h for xen boot. >> >> - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm >> to load different binaries for xen boot. >> Introduce xen_module to load common or custom module for xen boot. >> >> - This Xen boot support is a separated module for aarch64, >> but reuse the existing code of devicetree in linux module. >> >> - Add the support of xen_hypervisor, xen_linux and xen_initrd >> in util/grub.d/20_linux_xen.in >> >> - Add the introduction of all xen boot commands in docs/grub.texi >> >> - The example of this support is > Foundation FVP model> >> >> https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP_model_by_GRUB >> >> Changelog: >> v3: create separate module for xen boot: xen_boot >> create separate commands for different types of module >> delete order-dependent for commands of xen module >> simplify the code >> >> v2: remove the patches which have been accepted. >> according to Vladimir's suggestion, change the command manes >> and relevant code: >> multiboot-->xen_hypervisor >> module-->xen_module >> improve the option parsing support for xen_hypervisor/xen_module >> commands. >> add a patch for adding xen_hypervisor/xen_module support >> in util/grub.d/20_linux_xen.in. >> update docs/grub.texi patch for the new command names. >> >> v1: The first version upstream patchset to grub-devel mailing list >> >> >> Fu Wei (4): >> arm64: Add and export some accessor functions for xen boot >> arm64: Add xen_boot module file >> * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 >> arm64: Add the introduction of xen boot commands in docs/grub.texi >> >> docs/grub.texi| 56 >> grub-core/Makefile.core.def | 7 + >> grub-core/loader/arm64/linux.c| 13 + >> grub-core/loader/arm64/xen_boot.c | 685 >> ++ >> include/grub/arm64/linux.h| 6 +- >> util/grub.d/20_linux_xen.in | 16 +- >> 6 files changed, 779 insertions(+), 4 deletions(-) >> create mode 100644 grub-core/loader/arm64/xen_boot.c >> >> -- >> 1.8.3.1 >> > > > > -- > 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)
Hi Vladimir, this patchset follows all your comment of v2 patchset. Do you have any suggestion on this patchset? Great thanks for your help. On 23 July 2015 at 13:16, fu@linaro.org wrote: From: Fu Wei fu@linaro.org - This adds support for the Xen boot on ARM specification for arm64. - Add and export some accessor functions of loaded flag and grub_linux_get_fdt function in include/grub/arm64/linux.h for xen boot. - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm to load different binaries for xen boot. Introduce xen_module to load common or custom module for xen boot. - This Xen boot support is a separated module for aarch64, but reuse the existing code of devicetree in linux module. - Add the support of xen_hypervisor, xen_linux and xen_initrd in util/grub.d/20_linux_xen.in - Add the introduction of all xen boot commands in docs/grub.texi - The example of this support is How to boot Xen with GRUB on AArch64 the Foundation FVP model https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP_model_by_GRUB Changelog: v3: create separate module for xen boot: xen_boot create separate commands for different types of module delete order-dependent for commands of xen module simplify the code v2: remove the patches which have been accepted. according to Vladimir's suggestion, change the command manes and relevant code: multiboot--xen_hypervisor module--xen_module improve the option parsing support for xen_hypervisor/xen_module commands. add a patch for adding xen_hypervisor/xen_module support in util/grub.d/20_linux_xen.in. update docs/grub.texi patch for the new command names. v1: The first version upstream patchset to grub-devel mailing list Fu Wei (4): arm64: Add and export some accessor functions for xen boot arm64: Add xen_boot module file * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 arm64: Add the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 56 grub-core/Makefile.core.def | 7 + grub-core/loader/arm64/linux.c| 13 + grub-core/loader/arm64/xen_boot.c | 685 ++ include/grub/arm64/linux.h| 6 +- util/grub.d/20_linux_xen.in | 16 +- 6 files changed, 779 insertions(+), 4 deletions(-) create mode 100644 grub-core/loader/arm64/xen_boot.c -- 1.8.3.1 -- 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 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
Re: [Xen-devel] [PATCH v2 1/3] arm64: Add Xen boot support file
Hi Vladimir,
I have submitted a new patchset (v3) for xen boot.
this patchset follows all your comment here.
please help me again on this, Great thanks for your help.
On 16 July 2015 at 00:18, Vladimir 'φ-coder/phcoder' Serbinenko
phco...@gmail.com wrote:
On 13.07.2015 10:53, fu@linaro.org wrote:
From: Fu Wei fu@linaro.org
This patch adds Xen boot support file:
grub-core/loader/arm64/xen_boot.c
include/grub/arm64/xen_boot.h
This patch also adds commands register code and hearder file into
grub-core/loader/arm64/linux.c
- This adds support for the Xen boot on ARM specification for arm64.
- The implementation for Xen is following Multiboot on ARM
Specification:
http://wiki.xen.org/wiki/Xen_ARM_with_Virtualization_Extensions/Multiboot
Please don't refer to this protocol as multiboot anywhere in grub or
around because it's NOT multiboot and we don't want to confuse those 2
protocols.
and xen/docs/misc/arm/device-tree/booting.txt in Xen source code.
- The multiboot/module commands have existed,
so we use xen_hypervisor/xen_module instead.
- This Xen boot support is built into linux module for aarch64.
- Adding this functionality to the existing linux module is for
reusing the existing code of devicetree.
Please create separate module. Modules are dynamically linked.
Signed-off-by: Fu Wei fu@linaro.org
---
grub-core/Makefile.core.def | 1 +
grub-core/loader/arm64/linux.c| 6 +
grub-core/loader/arm64/xen_boot.c | 615
++
include/grub/arm64/xen_boot.h | 115 +++
4 files changed, 737 insertions(+)
create mode 100644 grub-core/loader/arm64/xen_boot.c
create mode 100644 include/grub/arm64/xen_boot.h
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index a6101de..01f8261 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1659,6 +1659,7 @@ module = {
ia64_efi = loader/ia64/efi/linux.c;
arm = loader/arm/linux.c;
arm64 = loader/arm64/linux.c;
+ arm64 = loader/arm64/xen_boot.c;
fdt = lib/fdt.c;
common = loader/linux.c;
common = lib/cmdline.c;
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index 987f5b9..7ae9bde 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/arm64/linux.c
@@ -26,6 +26,7 @@
#include grub/mm.h
#include grub/types.h
#include grub/cpu/linux.h
+#include grub/cpu/xen_boot.h
#include grub/efi/efi.h
#include grub/efi/pe32.h
#include grub/i18n.h
@@ -477,6 +478,9 @@ GRUB_MOD_INIT (linux)
cmd_devicetree =
grub_register_command (devicetree, grub_cmd_devicetree, 0,
N_(Load DTB file.));
+
+ grub_arm64_linux_register_xen_boot_command (mod, loaded);
+
my_mod = mod;
}
@@ -485,4 +489,6 @@ GRUB_MOD_FINI (linux)
grub_unregister_command (cmd_linux);
grub_unregister_command (cmd_initrd);
grub_unregister_command (cmd_devicetree);
+
+ grub_arm64_linux_unregister_xen_boot_command ();
}
Not needed with separate module.
diff --git a/grub-core/loader/arm64/xen_boot.c
b/grub-core/loader/arm64/xen_boot.c
new file mode 100644
index 000..23bd00e
--- /dev/null
+++ b/grub-core/loader/arm64/xen_boot.c
@@ -0,0 +1,615 @@
+/*
+ * GRUB -- GRand Unified Bootloader
+ * Copyright (C) 2014 Free Software Foundation, Inc.
+ *
+ * GRUB is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation, either version 3 of the License, or
+ * (at your option) any later version.
+ *
+ * GRUB is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with GRUB. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include grub/cache.h
+#include grub/charset.h
+#include grub/command.h
+#include grub/err.h
+#include grub/file.h
+#include grub/fdt.h
+#include grub/linux.h
+#include grub/list.h
+#include grub/loader.h
+#include grub/misc.h
+#include grub/mm.h
+#include grub/types.h
+#include grub/cpu/linux.h
+#include grub/cpu/xen_boot.h
+#include grub/efi/efi.h
+#include grub/efi/pe32.h
+#include grub/i18n.h
+#include grub/lib/cmdline.h
+
+static grub_dl_t linux_mod;
+static int *loaded;
+
+static struct xen_boot_binary *xen_hypervisor;
+static struct xen_boot_binary *module_head;
+static const grub_size_t module_default_align[] = {
+ MODULE_IMAGE_MIN_ALIGN,
+ MODULE_INITRD_MIN_ALIGN,
+ MODULE_OTHER_MIN_ALIGN,
+ MODULE_CUSTOM_MIN_ALIGN
+};
+
+static void *xen_boot_fdt;
+static const compat_string_struct_t default_compat_string[] = {
+ FDT_COMPATIBLE (MODULE_IMAGE_COMPATIBLE
[Xen-devel] [PATCH v3 1/4] arm64: Add and export some accessor functions for xen boot
From: Fu Wei fu@linaro.org
Add accessor functions of loaded flag in
grub-core/loader/arm64/linux.c.
Export accessor functions of loaded flag and
grub_linux_get_fdt function in include/grub/arm64/linux.h.
Purpose: Reuse the existing code of devicetree in linux module.
Signed-off-by: Fu Wei fu@linaro.org
---
grub-core/loader/arm64/linux.c | 13 +
include/grub/arm64/linux.h | 6 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/grub-core/loader/arm64/linux.c b/grub-core/loader/arm64/linux.c
index 987f5b9..cf6026e 100644
--- a/grub-core/loader/arm64/linux.c
+++ b/grub-core/loader/arm64/linux.c
@@ -48,6 +48,19 @@ static grub_addr_t initrd_end;
static void *loaded_fdt;
static void *fdt;
+/* The accessor functions for loaded flag */
+int
+grub_linux_get_loaded (void)
+{
+ return loaded;
+}
+
+void
+grub_linux_set_loaded (int loaded_flag)
+{
+ loaded = loaded_flag;
+}
+
static void *
get_firmware_fdt (void)
{
diff --git a/include/grub/arm64/linux.h b/include/grub/arm64/linux.h
index 65796d9..20058f3 100644
--- a/include/grub/arm64/linux.h
+++ b/include/grub/arm64/linux.h
@@ -43,10 +43,14 @@ struct grub_arm64_linux_kernel_header
};
/* Declare the functions for getting dtb and checking/booting image */
-void *grub_linux_get_fdt (void);
grub_err_t grub_arm64_uefi_check_image (struct grub_arm64_linux_kernel_header
*lh);
grub_err_t grub_arm64_uefi_boot_image (grub_addr_t addr, grub_size_t size,
char *args);
+/* Export the accessor functions for gettin dtb and loaded flag */
+void EXPORT_FUNC (*grub_linux_get_fdt) (void);
+int EXPORT_FUNC (grub_linux_get_loaded) (void);
+void EXPORT_FUNC (grub_linux_set_loaded) (int loaded_flag);
+
#endif /* ! GRUB_LINUX_CPU_HEADER */
--
1.8.3.1
___
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
[Xen-devel] [PATCH v3 0/4] arm64: Add Xen boot support (via fdt)
From: Fu Wei fu@linaro.org - This adds support for the Xen boot on ARM specification for arm64. - Add and export some accessor functions of loaded flag and grub_linux_get_fdt function in include/grub/arm64/linux.h for xen boot. - Introduce xen_hypervisor, xen_linux, xen_initrd and xen_xsm to load different binaries for xen boot. Introduce xen_module to load common or custom module for xen boot. - This Xen boot support is a separated module for aarch64, but reuse the existing code of devicetree in linux module. - Add the support of xen_hypervisor, xen_linux and xen_initrd in util/grub.d/20_linux_xen.in - Add the introduction of all xen boot commands in docs/grub.texi - The example of this support is How to boot Xen with GRUB on AArch64 the Foundation FVP model https://wiki.linaro.org/LEG/Engineering/Grub2/Xen_booting_on_Foundation_FVP_model_by_GRUB Changelog: v3: create separate module for xen boot: xen_boot create separate commands for different types of module delete order-dependent for commands of xen module simplify the code v2: remove the patches which have been accepted. according to Vladimir's suggestion, change the command manes and relevant code: multiboot--xen_hypervisor module--xen_module improve the option parsing support for xen_hypervisor/xen_module commands. add a patch for adding xen_hypervisor/xen_module support in util/grub.d/20_linux_xen.in. update docs/grub.texi patch for the new command names. v1: The first version upstream patchset to grub-devel mailing list Fu Wei (4): arm64: Add and export some accessor functions for xen boot arm64: Add xen_boot module file * util/grub.d/20_linux_xen.in: Add support of the XEN boot on aarch64 arm64: Add the introduction of xen boot commands in docs/grub.texi docs/grub.texi| 56 grub-core/Makefile.core.def | 7 + grub-core/loader/arm64/linux.c| 13 + grub-core/loader/arm64/xen_boot.c | 685 ++ include/grub/arm64/linux.h| 6 +- util/grub.d/20_linux_xen.in | 16 +- 6 files changed, 779 insertions(+), 4 deletions(-) create mode 100644 grub-core/loader/arm64/xen_boot.c -- 1.8.3.1 ___ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
