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 an XSM, Xen will assume its compatible string is
+ "xen,xsm-policy";
+ - if it's not an XSM, for the second module that lacks a specific
+ compatible string, Xen will assume its compatible string is
+ "multiboot,ramdisk"; the third and subsequent modules that
+ lack a specific compatible string will not receive any special
+ treatment.
+ This means that 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