xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>, xen-devel@lists.xen.org
Cc: tim@xen.org, stefano.stabellini@eu.citrix.com
Subject: Re: [PATCH RFC 14/15] libxl: build a device tree for ARM guests
Date: Tue, 15 Oct 2013 00:11:36 +0100	[thread overview]
Message-ID: <525C7A28.7060003@linaro.org> (raw)
In-Reply-To: <1381164001-1446-14-git-send-email-ian.campbell@citrix.com>

On 10/07/2013 05:40 PM, Ian Campbell wrote:
> Uses xc_dom_devicetree_mem which was just added. The call to this needs to be
> carefully sequenced to be after xc_dom_parse_image (so we can tell which kind
> of guest we are building, although we don't use this yet) and before
> xc_dom_mem_init which tries to decide where to place the FDT in guest RAM.
>
> Removes libxl_noarch which would only have been used by IA64 after this
> change. Remove IA64 as part of this patch.
>
> There is no attempt to expose this as a configuration setting for the user.
>
> Includes a debug hook to dump the dtb to a file for inspection.
>
> TODO:
> - Hardcoded armv8 bits need abstracting. Perhaps e.g. read CPU compatiblity
>    node from sysfs?

I'm wondering if it's usefull to have the property compatible. From 
Linux documentation:
   So under /cpus, you are supposed to create a node for every CPU on
   the machine. There is no specific restriction on the name of the
   CPU, though it's common to call it <architecture>,<core>. For
   example, Apple uses PowerPC,G5 while IBM uses PowerPC,970FX.
   However, the Generic Names convention suggests that it would be
   better to simply use 'cpu' for each cpu node and use the compatible
   property to identify the specific cpu core.

Linux doesn't seems to retrieve the compatible node and Freebsd also.
The only way to read this property is from /proc/device-tree. But this 
directory exists only if CONFIG_PROC_DEVICETREE=y.

> - Try it with armv7

The previous point will be the same for the timer and the GIC.

> - Debug hook should be #ifdef DEBUG?
> - Various values (e.g. GIC base addresses, evtchn PPI) should be passed
>    down to the hypervisor by some mechanism I've not decided on yet. Perhaps
>    domctl but maybe better would be via the HVM save format to more easily
>    support migration of the settings?
> - TODOs and //comments in the code
   - Add initrd support?

>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

[..]

> diff --git a/tools/libxl/libxl_arm.c b/tools/libxl/libxl_arm.c
> new file mode 100644
> index 0000000..913741d
> --- /dev/null
> +++ b/tools/libxl/libxl_arm.c

[..]

> +static int fdt_property_interrupts(libxl__gc *gc, void *fdt,
> +                                   gic_interrupt_t *intr,
> +                                   unsigned num_irq)
> +{
> +    int res;
> +
> +    res = fdt_property(fdt, "interrupts", intr, sizeof (intr[0]) * num_irq);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "interrupt-parent", PHANDLE_GIC);
> +
> +    return res;
> +}

You don't need this function if the interrupt-parent properties is set 
in the root node. Which is the case below in make_root_properties.

[..]

> +static int make_cpus_node(libxl__gc *gc, void *fdt, int nr_cpus)
> +{
> +    int res, i;
> +
> +    res = fdt_begin_node(fdt, "cpus");
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "#address-cells", 1);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "#size-cells", 0);
> +    if ( res )
> +        return res;
> +
> +    for (i = 0; i < nr_cpus; i++) {
> +        char name[strlen("cpu@") + 2 + 1];
> +
> +        if ( snprintf(name, sizeof(name)-1, "cpu@%d", i) < 0 )
> +        {
> +            perror("snprintf");
> +            exit(1);
> +        }
> +
> +        res = fdt_begin_node(fdt, name);
> +        if ( res )
> +            return res;
> +
> +        res = fdt_property_string(fdt, "device_type", "cpu");
> +        if ( res )
> +            return res;
> +
> +        res = fdt_property_compat(gc, fdt, 1, "arm,armv8");
> +        if ( res )
> +            return res;
> +
> +        res = fdt_property_string(fdt, "enable-method", "psci");

#ifdef CONFIG_ARM64 and if it's a 64 bit domain?

> +        if ( res )
> +            return res;
> +
> +        res = fdt_property_regs(gc, fdt, 1, 0, 1, (uint64_t)i);
> +        if ( res )
> +            return res;
> +
> +        res = fdt_end_node(fdt);
> +        if ( res )
> +            return res;
> +
> +    }
> +
> +    res = fdt_end_node(fdt);
> +
> +    return res;
> +}
> +
> +static int make_psci_node(libxl__gc *gc, void *fdt)
> +{
> +    int res;
> +
> +    res = fdt_begin_node(fdt, "psci");
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_compat(gc, fdt, 1, "arm,psci");
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_string(fdt, "method", "hvc");
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "cpu_off", 0x1);
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_cell(fdt, "cpu_on", 0x2);
> +    if ( res )
> +        return res;

Can we export include/asm-arm/psci.h and reuse the value here?

> +
> +    res = fdt_end_node(fdt);
> +
> +    return res;
> +}

[..]

> +static int make_hypervisor_node(libxl__gc *gc, void *fdt,
> +                                const libxl_version_info *vers)
> +{
> +    int res;
> +    gic_interrupt_t intr;
> +
> +    /* See linux Documentation/devicetree/bindings/arm/xen.txt */
> +    res = fdt_begin_node(fdt, "hypervisor");
> +    if ( res )
> +        return res;
> +
> +    res = fdt_property_compat(gc, fdt, 2,
> +                              GCSPRINTF("xen,xen-%d.%d",
> +                                        vers->xen_version_major,
> +                                        vers->xen_version_minor),
> +                              "xen,xen");
> +    if ( res )
> +        return res;
> +
> +    //DPRINT("  Grant table range: 0xb0000000-0x20000\n");
> +    /* reg 0 is grant table space */
> +    res = fdt_property_regs(gc, fdt, ROOT_ADDRESS_CELLS, ROOT_SIZE_CELLS,
> +                            1,
> +                            (uint64_t)0xb0000000,

I still don't know where this value comes from... if it's a random 
value, can we autogenerate it?

-- 
Julien Grall

  reply	other threads:[~2013-10-14 23:11 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-07 16:39 [PATCH RFC 00/15] xen: arm: 64-bit guest support and domU FDT autogeneration Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 01/15] xen: arm: Report aarch64 capability Ian Campbell
2013-10-10 14:25   ` Julien Grall
2013-10-07 16:39 ` [PATCH RFC 02/15] xen: arm: Add comment regard arm64 zImage v0 vs v1 Ian Campbell
2013-10-10 14:26   ` Julien Grall
2013-10-07 16:39 ` [PATCH RFC 03/15] xen: arm: allocate dom0 memory separately from preparing the dtb Ian Campbell
2013-10-10 14:38   ` Julien Grall
2013-10-24 17:06     ` Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 04/15] xen: arm: add enable-method to cpu nodes for arm64 guests Ian Campbell
2013-10-10 14:40   ` Julien Grall
2013-10-07 16:39 ` [PATCH RFC 05/15] xen: arm: implement XEN_DOMCTL_set_address_size Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 06/15] xen: arm: implement arch_set_info_guest for 64-bit vcpus Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 07/15] xenctx: fix typo in arm64 output Ian Campbell
2013-10-10 14:43   ` Julien Grall
2013-10-24 21:47     ` Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 08/15] tools: check for libfdt when building for ARM Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 09/15] libxc: arm: rename various bits of zimage load with 32 suffix Ian Campbell
2013-10-10 15:27   ` Julien Grall
2013-10-07 16:39 ` [PATCH RFC 10/15] libxc: allow caller to specify guest rambase rather than hardcoding Ian Campbell
2013-10-10 15:31   ` Julien Grall
2013-10-10 15:34     ` Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 11/15] libxc: allow passing a device tree blob to the guest Ian Campbell
2013-10-07 16:39 ` [PATCH RFC 12/15] libxc: support for arm64 Image format Ian Campbell
2013-10-10 15:43   ` Julien Grall
2013-10-10 15:56     ` Ian Campbell
2013-10-21  9:46       ` Ian Campbell
2013-10-21 15:11         ` Julien Grall
2013-10-07 16:39 ` [PATCH RFC 13/15] libxc: arm64 vcpu initialisation Ian Campbell
2013-10-10 15:54   ` Julien Grall
2013-10-10 15:59     ` Ian Campbell
2013-10-10 16:04       ` Julien Grall
2013-10-10 16:09         ` Ian Campbell
2013-10-14 22:36           ` Julien Grall
2013-10-07 16:40 ` [PATCH RFC 14/15] libxl: build a device tree for ARM guests Ian Campbell
2013-10-14 23:11   ` Julien Grall [this message]
2013-10-15 10:00     ` Ian Campbell
2013-10-15 13:23       ` Julien Grall
2013-10-15 13:33         ` Ian Campbell
2013-10-15 13:49           ` Julien Grall
2013-10-15 13:52             ` Ian Campbell
2013-10-15 13:46   ` Julien Grall
2013-10-07 16:40 ` [PATCH RFC 15/15] libxl: remove spurious newline from LOG() message Ian Campbell

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=525C7A28.7060003@linaro.org \
    --to=julien.grall@linaro.org \
    --cc=ian.campbell@citrix.com \
    --cc=stefano.stabellini@eu.citrix.com \
    --cc=tim@xen.org \
    --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).