From: Julien Grall <julien.grall@linaro.org>
To: Ian Campbell <ian.campbell@citrix.com>
Cc: stefano.stabellini@eu.citrix.com, tim@xen.org, xen-devel@lists.xen.org
Subject: Re: [PATCH RFC 03/15] xen: arm: allocate dom0 memory separately from preparing the dtb
Date: Thu, 10 Oct 2013 15:38:56 +0100 [thread overview]
Message-ID: <5256BC00.1020309@linaro.org> (raw)
In-Reply-To: <1381164001-1446-3-git-send-email-ian.campbell@citrix.com>
On 10/07/2013 05:39 PM, Ian Campbell wrote:
> Mixing these two together is a pain, it forces us to prepare the dtb before
> processing the kernel which means we don't know whether the guest is 32- or
> 64-bit while we construct its DTB.
>
> Instead split out the memory allocation (including 1:1 workaround handling)
> and p2m setup into a seaprate phase and then fill in the memory nodes in the
separate
> DTB based on the result while generating the DTB.
>
> This allows us to move kernel parsing before DTB setup.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> ---
> xen/arch/arm/domain_build.c | 94 ++++++++++++++++++++++++++++++-------------
> 1 file changed, 65 insertions(+), 29 deletions(-)
>
> diff --git a/xen/arch/arm/domain_build.c b/xen/arch/arm/domain_build.c
> index fb1fa56..1287934 100644
> --- a/xen/arch/arm/domain_build.c
> +++ b/xen/arch/arm/domain_build.c
> @@ -63,11 +63,8 @@ struct vcpu *__init alloc_dom0_vcpu0(void)
> return alloc_vcpu(dom0, 0, 0);
> }
>
> -static int set_memory_reg_11(struct domain *d, struct kernel_info *kinfo,
> - const struct dt_property *pp,
> - const struct dt_device_node *np, __be32 *new_cell)
> +static int allocate_memory_11(struct domain *d, struct kernel_info *kinfo)
This function always return 0 or panic if an error occurred. Perhaps you
can move the return type to void?
> {
> - int reg_size = dt_cells_to_size(dt_n_addr_cells(np) + dt_n_size_cells(np));
> paddr_t start;
> paddr_t size;
> struct page_info *pg;
> @@ -91,40 +88,53 @@ static int set_memory_reg_11(struct domain *d, struct kernel_info *kinfo,
> if ( res )
> panic("Unable to add pages in DOM0: %d\n", res);
>
> - dt_set_range(&new_cell, np, start, size);
> -
> kinfo->mem.bank[0].start = start;
> kinfo->mem.bank[0].size = size;
> kinfo->mem.nr_banks = 1;
>
> - return reg_size;
> + kinfo->unassigned_mem -= size;
> +
> + return 0;
> }
>
> -static int set_memory_reg(struct domain *d, struct kernel_info *kinfo,
> - const struct dt_property *pp,
> - const struct dt_device_node *np, __be32 *new_cell)
> +static int allocate_memory(struct domain *d, struct kernel_info *kinfo)
Same here.
> {
> - int reg_size = dt_cells_to_size(dt_n_addr_cells(np) + dt_n_size_cells(np));
> - int l = 0;
> +
> + const struct dt_device_node *memory;
> + const void *reg;
> + u32 reg_len, reg_size;
> + int l = 0, ret;
> unsigned int bank = 0;
> - u64 start;
> - u64 size;
> - int ret;
>
> if ( platform_has_quirk(PLATFORM_QUIRK_DOM0_MAPPING_11) )
> - return set_memory_reg_11(d, kinfo, pp, np, new_cell);
> + return allocate_memory_11(d, kinfo);
> +
> + memory = dt_find_node_by_type(NULL, "memory");
Can we try to have the same way to retrieve the memory node in each place?
- common/device_tree.c: looking by memory@unit
- arch/arm/domain_build.c:write_properties: looking only the exact node
name "memory"
- here: looking by type "memory"
Furthermore, your are assuming that there is only one memory node in DTS
tree. Perhaps a loop is better here?
--
Julien Grall
next prev parent reply other threads:[~2013-10-10 14:38 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 [this message]
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
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=5256BC00.1020309@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.