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.