[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 19/19] libxl: build a device tree for ARM guests
On 11/13/2013 06:11 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: - v7 CPU compat is hardcoded to cortex-a15 -- may need to define something more generic via mach-virt dt bindngs? Signed-off-by: Ian Campbell <ian.campbell@xxxxxxxxxx> Cc: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> --- v5: Correct error handling in debug_dump_fdt v4: Drop spurious comment in header s/__be32/be32/ and s/gic_interrupt_t/gic_interrupt/ to avoid reserved names Coding style fixes Use GCSPRINTF use for(;;) around FDT creation loop, undef FDT when done use libxl__realloc for fdt size increase Refactor debug dump into its own function, remove NDEBUG ifdef v2: base addresses, irq, evtchn etc stuff is now from public API headers, avoiding the need to introduce domctls etc until we want to make them dynamic. fix memory node Improve libfdt error handling, especially for FDT_ERR_NOSPACE. Derive guest CPU and timer compatiblity nodes from the guest type. wip --- tools/libxl/Makefile | 6 +- tools/libxl/libxl_arch.h | 3 + tools/libxl/libxl_arm.c | 512 ++++++++++++++++++++++++++++++++++++++++++++ tools/libxl/libxl_dom.c | 4 + tools/libxl/libxl_noarch.c | 8 - tools/libxl/libxl_x86.c | 7 + 6 files changed, 530 insertions(+), 10 deletions(-) create mode 100644 tools/libxl/libxl_arm.c delete mode 100644 tools/libxl/libxl_noarch.c [..] + for (;;) { +next_resize: + if (fdt_size) { + fdt_size <<= 1; + LOG(DEBUG, "Increasing FDT size to %zd and retrying", fdt_size); + } else { + fdt_size = 4096; + } + + fdt = libxl__realloc(gc, fdt, fdt_size); + + FDT( fdt_create(fdt, fdt_size) ); + + FDT( fdt_finish_reservemap(fdt) ); + + FDT( fdt_begin_node(fdt, "") ); + + FDT( make_root_properties(gc, vers, fdt) ); + FDT( make_chosen_node(gc, fdt, info) ); + FDT( make_cpus_node(gc, fdt, info->max_vcpus, ainfo) ); + FDT( make_psci_node(gc, fdt) ); + + FDT( make_memory_node(gc, fdt, + dom->rambase_pfn << XC_PAGE_SHIFT, + info->target_memkb * 1024) ); + FDT( make_intc_node(gc, fdt, + GUEST_GICD_BASE, GUEST_GICD_SIZE, + GUEST_GICC_BASE, GUEST_GICD_SIZE) ); + + FDT( make_timer_node(gc, fdt, ainfo) ); + FDT( make_hypervisor_node(gc, fdt, vers) ); + + FDT( fdt_end_node(fdt) ); + + FDT( fdt_finish(fdt) ); + break; + } +#undef FDT Why didn't you try to use fdt_open_into? It should fit our usage: ie, grow up the size of the device tree. Actually, DTC uses this solution when the fdt needs to be resized. -- Julien Grall _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |