xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: "Egger, Christoph" <chegger@amazon.de>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: stefano.stabellini@eu.citrix.com, julien.grall@linaro.org,
	Andre Przywara <andre.przywara@linaro.org>,
	xen-devel@lists.xen.org
Subject: Re: [PATCH] ARM/multiboot: use more flexible node naming
Date: Thu, 5 Sep 2013 16:22:16 +0200	[thread overview]
Message-ID: <52289398.8050808@amazon.de> (raw)
In-Reply-To: <1378389831.14745.43.camel@kazak.uk.xensource.com>

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".

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@linaro.org>
>>> ---
>>>  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;
>>>  }
>>>
>>
> 
> 

  reply	other threads:[~2013-09-05 14:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-05 13:43 [PATCH] ARM/multiboot: use more flexible node naming Andre Przywara
2013-09-05 13:54 ` Egger, Christoph
2013-09-05 14:03   ` Ian Campbell
2013-09-05 14:22     ` Egger, Christoph [this message]
2013-09-05 14:59       ` Ian Campbell
2013-09-06  8:44         ` Andre Przywara
2013-09-06 11:11 ` Julien Grall
2013-09-09 13:52   ` Andre Przywara
2013-09-09 12:00 ` Ian Campbell
2013-09-09 14:01   ` Andre Przywara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52289398.8050808@amazon.de \
    --to=chegger@amazon.de \
    --cc=Ian.Campbell@citrix.com \
    --cc=andre.przywara@linaro.org \
    --cc=julien.grall@linaro.org \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=xen-devel@lists.xen.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).