mirror of
https://github.com/xen-project/xen.git
synced 2026-10-29 18:50:05 +01:00
Fu Wei
488c2a860a
Improve the clarity of the wording introduced in 67831c4c
"docs/arm64: update the documentation for loading XSM support"
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Fu Wei <fu.wei@linaro.org>
CC: Julien Grall <julien.grall@arm.com>
CC: Stefano Stabellini <sstabellini@kernel.org>
Reviewed-by: Julien Grall <julien.grall@arm.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
122 lines
3.9 KiB
Plaintext
122 lines
3.9 KiB
Plaintext
Dom0 kernel and ramdisk modules
|
|
================================
|
|
|
|
Xen is passed the dom0 kernel and initrd via a reference in the /chosen
|
|
node of the device tree.
|
|
|
|
Each node contains the following properties:
|
|
|
|
- compatible
|
|
|
|
Must always include at least the generic compatiblity string:
|
|
|
|
"multiboot,module"
|
|
|
|
Optionally a more specific compatible string may be used in
|
|
addition to the above. One of:
|
|
|
|
- "multiboot,kernel" -- the dom0 kernel
|
|
- "multiboot,ramdisk" -- the dom0 ramdisk
|
|
- "xen,xsm-policy" -- XSM policy blob
|
|
|
|
It is normally recommended to include a more specific
|
|
compatible string (if one applies) in addition to the generic
|
|
string (which must always be present).
|
|
|
|
Xen will assume that the first module which lacks a more
|
|
specific compatible string is a "multiboot,kernel".
|
|
|
|
Xen will examine each module, starting from the second
|
|
module that lacks a specific compatible string. Xen will
|
|
check each such module for the XSM Magic number:
|
|
|
|
- For a module which has the XSM Magic number: it will be
|
|
treated by Xen as if its compatible string was
|
|
"xen,xsm-policy";
|
|
|
|
- For a module which does not have the XSM Magic: the second
|
|
module lacking a compatible string will be treated by Xen as
|
|
if its compatible string was "multiboot,ramdisk"; for the
|
|
third and subsequent modules which lack a specific
|
|
compatible string, Xen will not apply 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
|
|
and later can use a single DTB.
|
|
|
|
- "xen,multiboot-module" equivalent to "multiboot,module"
|
|
- "xen,linux-zimage" equivalent to "multiboot,kernel"
|
|
- "xen,linux-initrd" equivalent to "multiboot,ramdisk"
|
|
|
|
For compatibility with Xen 4.4 the more specific "xen,linux-*"
|
|
names are non-optional and must be included.
|
|
|
|
- reg
|
|
|
|
Specifies the physical address of the module in RAM and the
|
|
length of the module.
|
|
|
|
- bootargs (optional)
|
|
|
|
Command line associated with this module. See below for the
|
|
priority of this field vs. other mechanisms of specifying the
|
|
bootargs for the kernel.
|
|
|
|
Examples
|
|
========
|
|
|
|
A boot module of unspecified type:
|
|
|
|
module@0xc0000000 {
|
|
compatible = "multiboot,module";
|
|
reg = <0xc0000000 0x1234>;
|
|
bootargs = "...";
|
|
};
|
|
|
|
A boot module containing a ramdisk:
|
|
|
|
module@0xd0000000 {
|
|
compatible = "multiboot,ramdisk", "multiboot,module";
|
|
reg = <0xd0000000 0x5678>;
|
|
};
|
|
|
|
The previous examples are compatible with Xen 4.5+ only.
|
|
|
|
To be compatible with Xen 4.4 as well use the legacy names:
|
|
|
|
module@0xd0000000 {
|
|
compatible = "xen,linux-initrd", "xen,multiboot-module";
|
|
reg = <0xd0000000 0x5678>;
|
|
};
|
|
|
|
Command lines
|
|
=============
|
|
|
|
Xen also checks for properties directly under /chosen to find suitable command
|
|
lines for Xen and Dom0. The logic is the following:
|
|
|
|
- If xen,xen-bootargs is present, it will be used for Xen.
|
|
- If xen,dom0-bootargs is present, it will be used for Dom0.
|
|
- If xen,xen-bootargs is _not_ present, but xen,dom0-bootargs is,
|
|
bootargs will be used for Xen.
|
|
- If a kernel boot module is present and has a bootargs property then
|
|
the top-level bootargs will used for Xen.
|
|
- If no Xen specific properties are present, bootargs is for Dom0.
|
|
- If xen,xen-bootargs is present, but xen,dom0-bootargs is missing,
|
|
bootargs will be used for Dom0.
|
|
|
|
Most of these cases is to make booting with Xen-unaware bootloaders easier.
|
|
For those you would hardcode the Xen commandline in the DTB under
|
|
/chosen/xen,xen-bootargs and would let the bootloader set the Dom0 command
|
|
line by writing bootargs (as for native Linux).
|
|
A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs
|
|
for Dom0 and bootargs for native Linux.
|