Re: [Xen-devel] [PATCH] ARM/multiboot: use more flexible node naming

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Thu, 2013-09-05 at 16:22 +0200, Egger, Christoph wrote:
> On 05.09.13 16:03, Ian Campbell wrote:
> > On Thu, 2013-09-05 at 15:54 +0200, Egger, Christoph wrote:
> >> Is there a chance to get NetBSD Dom0 [1] to boot to justify that your
> >> approach is *really* generic.
> >>
> >> xen,linux-zimage and xen,linux-initrd do not sound generic
> >> but xen,dom0-kernel and xen,ramdisk do sound generic at least.
> > 
> > Does NetBSD follow the Linux zImage boot protocol
> > (Documentation/arm/Booting.txt in a Linux source tree)?
> > 
> > If not then you need to define (or link to) the NetBSD boot protocol and
> > we probably will eventually need xen,netbsd-fooimg and suitable code in
> > Xen to handle that format.
> > 
> >> [1] NetBSD Dom0 hasn't been ported to ARM yet.
> > 
> > So surely you have answered your own question then, unless you are
> > asking Andre to port NetBSD to ARM? I don't think that is a reasonable
> > prerequisite for this patch.
> 
> No, it is not a prerequisite. My question is related to the design
> if it is "I allow Linux only to boot" or "I allow any Dom0 to boot".

The design allows for any dom0, since it includes a compatibility string
which corresponds to the boot protocol to use. The implementation
currently only covers Linux though.

> Christoph
> 
> > 
> >>
> >>
> >> On 05.09.13 15:43, Andre Przywara wrote:
> >>> For the current "multiboot" on ARM support we look for a compatible
> >>> string of "xen,multiboot-module" in the device tree, and then
> >>> use "xen,linux-zimage" and "xen,linux-initrd" to differentiate
> >>> between the two supported module types.
> >>> To meet the more generic multiboot proposal in the device tree [1],
> >>> allow Xen to be more flexible in the compatible naming and also use
> >>> the new generic base name "boot,module".
> >>> The mapping to either Dom0 kernel or RAM disk works either by
> >>> providing a more specific name ("xen,dom0-kernel" and "xen,ramdisk"),
> >>> or by using the enumeration order of the device tree nodes
> >>> (module@0 = kernel, module@1 = initrd). This allows bootloaders
> >>> without any specific Xen knowledge to boot Xen anyways.
> >>>
> >>> [1] http://lists.xen.org/archives/html/xen-devel/2013-09/msg00083.html
> >>>
> >>> Signed-off-by: Andre Przywara <andre.przywara@xxxxxxxxxx>
> >>> ---
> >>>  xen/common/device_tree.c | 57 
> >>> ++++++++++++++++++++++++++++++++++++++++++------
> >>>  1 file changed, 50 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/xen/common/device_tree.c b/xen/common/device_tree.c
> >>> index ec0d5e2..e10c035 100644
> >>> --- a/xen/common/device_tree.c
> >>> +++ b/xen/common/device_tree.c
> >>> @@ -439,22 +439,63 @@ static void __init process_cpu_node(const void 
> >>> *fdt, int node,
> >>>      cpumask_set_cpu(start, &cpu_possible_map);
> >>>  }
> >>>  
> >>> +static const char * const kernel_module_names[] = {
> >>> + "xen,linux-zimage",
> >>> + "xen,dom0-kernel",
> >>> + "boot,kernel",
> >>> + NULL
> >>> +};
> >>> +
> >>> +static const char * const initrd_module_names[] = {
> >>> + "xen,linux-initrd",
> >>> + "xen,ramdisk",
> >>> + "boot,ramdisk",
> >>> + NULL
> >>> +};
> >>> +
> >>>  static void __init process_multiboot_node(const void *fdt, int node,
> >>>                                            const char *name,
> >>>                                            u32 address_cells, u32 
> >>> size_cells)
> >>>  {
> >>>      const struct fdt_property *prop;
> >>>      const u32 *cell;
> >>> -    int nr;
> >>> +    int nr = -1;
> >>>      struct dt_mb_module *mod;
> >>>      int len;
> >>> +    const char* const * name_list;
> >>>  
> >>> -    if ( fdt_node_check_compatible(fdt, node, "xen,linux-zimage") == 0 )
> >>> -        nr = MOD_KERNEL;
> >>> -    else if ( fdt_node_check_compatible(fdt, node, "xen,linux-initrd") 
> >>> == 0)
> >>> -        nr = MOD_INITRD;
> >>> -    else
> >>> -        early_panic("%s not a known xen multiboot type\n", name);
> >>> +    for (name_list = kernel_module_names; *name_list != NULL; 
> >>> name_list++)
> >>> +        if ( fdt_node_check_compatible(fdt, node, *name_list) == 0 ) {
> >>> +            nr = MOD_KERNEL;
> >>> +            break;
> >>> +        }
> >>> +
> >>> +    for (name_list = initrd_module_names; *name_list != NULL; 
> >>> name_list++)
> >>> +        if ( fdt_node_check_compatible(fdt, node, *name_list) == 0 ) {
> >>> +            nr = MOD_INITRD;
> >>> +            break;
> >>> +        }
> >>> +
> >>> +    if (nr == -1) {
> >>> +         char *s;
> >>> +
> >>> +        if ( fdt_node_check_compatible(fdt, node, "boot,module") != 0 ) {
> >>> +            early_panic("%s not a known xen multiboot type\n", name);
> >>> +            return;
> >>> +        }
> >>> +        s = strchr(name, '@');
> >>> +        if (s == NULL)
> >>> +            nr = early_info.modules.nr_mods + 1;
> >>> +        else {
> >>> +            nr = simple_strtoll(s + 1, NULL, 10) + 1;
> >>> +        }
> >>> +    }
> >>> +
> >>> +    if (nr >= NR_MODULES) {
> >>> +        early_panic("only supporting %d multiboot modules\n",
> >>> +            NR_MODULES - MOD_DISCARD_FIRST);
> >>> +        return;
> >>> +    }
> >>>  
> >>>      mod = &early_info.modules.module[nr];
> >>>  
> >>> @@ -492,6 +533,8 @@ static int __init early_scan_node(const void *fdt,
> >>>          process_cpu_node(fdt, node, name, address_cells, size_cells);
> >>>      else if ( device_tree_node_compatible(fdt, node, 
> >>> "xen,multiboot-module" ) )
> >>>          process_multiboot_node(fdt, node, name, address_cells, 
> >>> size_cells);
> >>> +    else if ( device_tree_node_compatible(fdt, node, "boot,module" ) )
> >>> +        process_multiboot_node(fdt, node, name, address_cells, 
> >>> size_cells);
> >>>  
> >>>      return 0;
> >>>  }
> >>>
> >>
> > 
> > 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel