[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions


  • To: Stefano Stabellini <sstabellini@xxxxxxxxxx>
  • From: Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>
  • Date: Tue, 13 Aug 2019 14:23:47 +0000
  • Accept-language: en-US
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=epam.com; dmarc=pass action=none header.from=epam.com; dkim=pass header.d=epam.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h3HlHX0/18Heb7F1byjVPG7mmrWSLT2WlgdzdsEPc+0=; b=LEbQNm596ivxk7IMRpDnWj4f36gIGdHQQb53Ja6ejT1A/wx6hHqHDsJfEaZVdlDDCLmtbIot+MDyulxwKTgNVj0FMmHY/+eDdPIrWHNUMNkStFmwiYkWYqk8wwEkwk9DgNQFdKnsw9PjU7w3OkTScUlnLoNY604DFOiNyhQGBQtigsbdoT2zL0PoKUctROSR02sBR2MCCC+3CbHMdmwgCEwDg64qtuNIxKlBGdRZQNFn6RIEop9LaDV0d5YTt4J8k/Cpg/3WNaAiRPjnBCqv9W9NJgyrFaPwqscUwqjkgJ816B+oF9jSgZmOLCIw9f2b2C5AFgcU9V6rn5XuYw/rmg==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DAPOWbJeQLNNfUn1JGb83AX5GygPICVn/k9LIvelQSsI312HgI7p+tIHtUdbeHllh6R+lHjsD9uW1NvMYi+uv5IfLUFU/0hPp1akZHXyxFq3vIpOWrztuj+WsASUALCDE0Ta/k9GcY5tCQ4DnfvHrX1htZ5eLk2aurlWICS8S6BgEEF0UNUoUH192aVEZ0y4HyODdrxJmOjLxRCjY0d5kaHaorbWG4En56OM4RgESbA/A+hIzmBZqxP1uuNeZWKUqbd3PViJlEvH9c6N5IuUuEW2oqTMLbPXzWQUWOId1GIDXXbFJeeQZEqXcFNXqwwg2XtSHgFJJVac/IF4so0znw==
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=Volodymyr_Babchuk@xxxxxxxx;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, "julien.grall@xxxxxxx" <julien.grall@xxxxxxx>, Volodymyr Babchuk <Volodymyr_Babchuk@xxxxxxxx>, Stefano Stabellini <stefanos@xxxxxxxxxx>
  • Delivery-date: Tue, 13 Aug 2019 14:23:52 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>
  • Thread-index: AQHVUV1QMNfXhdMZzkSWk2vkeQwkS6b5IrWA
  • Thread-topic: [PATCH v5 3/7] xen/arm: keep track of reserved-memory regions

Stefano Stabellini writes:

> As we parse the device tree in Xen, keep track of the reserved-memory
> regions as they need special treatment (follow-up patches will make use
> of the stored information.)
>
> Reuse process_memory_node to add reserved-memory regions to the
> bootinfo.reserved_mem array.
>
> Refuse to continue once we reach the max number of reserved memory
> regions to avoid accidentally mapping any portions of them into a VM.
>
> Signed-off-by: Stefano Stabellini <stefanos@xxxxxxxxxx>
>
> ---
> Changes in v5:
> - remove unneeded cast
> - remove unneeded strlen check
> - don't pass address_cells, size_cells, depth to device_tree_for_each_node
>
> Changes in v4:
> - depth + 1 in process_reserved_memory_node
> - pass address_cells and size_cells to device_tree_for_each_node
> - pass struct meminfo * instead of a boolean to process_memory_node
> - improve in-code comment
> - use a separate process_reserved_memory_node (separate from
>   process_memory_node) function wrapper to have different error handling
>
> Changes in v3:
> - match only /reserved-memory
> - put the warning back in place for reg not present on a normal memory
>   region
> - refuse to continue once we reach the max number of reserved memory
>   regions
>
> Changes in v2:
> - call process_memory_node from process_reserved_memory_node to avoid
>   duplication
> ---
>  xen/arch/arm/bootfdt.c      | 41 +++++++++++++++++++++++++++++++------
>  xen/include/asm-arm/setup.h |  1 +
>  2 files changed, 36 insertions(+), 6 deletions(-)
>
> diff --git a/xen/arch/arm/bootfdt.c b/xen/arch/arm/bootfdt.c
> index 590b14304c..0b0e22a3d0 100644
> --- a/xen/arch/arm/bootfdt.c
> +++ b/xen/arch/arm/bootfdt.c
> @@ -136,6 +136,7 @@ static int __init process_memory_node(const void *fdt, 
> int node,
>      const __be32 *cell;
>      paddr_t start, size;
>      u32 reg_cells = address_cells + size_cells;
> +    struct meminfo *mem = data;
>
>      if ( address_cells < 1 || size_cells < 1 )
>          return -ENOENT;
> @@ -147,21 +148,46 @@ static int __init process_memory_node(const void *fdt, 
> int node,
>      cell = (const __be32 *)prop->data;
>      banks = fdt32_to_cpu(prop->len) / (reg_cells * sizeof (u32));
>
> -    for ( i = 0; i < banks && bootinfo.mem.nr_banks < NR_MEM_BANKS; i++ )
> +    for ( i = 0; i < banks && mem->nr_banks < NR_MEM_BANKS; i++ )
What is logic behind the second part of the loop condition?

You know that if (banks > NR_MEM_BANKS) then you will exit with error. Do
you really need to iterate over loop in this case?

>      {
>          device_tree_get_reg(&cell, address_cells, size_cells, &start, &size);
>          if ( !size )
>              continue;
> -        bootinfo.mem.bank[bootinfo.mem.nr_banks].start = start;
> -        bootinfo.mem.bank[bootinfo.mem.nr_banks].size = size;
> -        bootinfo.mem.nr_banks++;
> +        mem->bank[mem->nr_banks].start = start;
> +        mem->bank[mem->nr_banks].size = size;
> +        mem->nr_banks++;
>      }
>
> -    if ( bootinfo.mem.nr_banks == NR_MEM_BANKS )
> +    if ( mem->nr_banks == NR_MEM_BANKS )
Looks like you have the same off-by-one error, as in previous patch.
I can see that it was there earlier. But it is good time to fix it.

>          return -ENOSPC;
>      return 0;
>  }
>
> +static int __init process_reserved_memory_node(const void *fdt, int node,
> +                                               const char *name, int depth,
> +                                               u32 address_cells,
> +                                               u32 size_cells,
> +                                               void *data)
> +{
> +    int rc = process_memory_node(fdt, node, name, depth, address_cells,
> +                                 size_cells, data);
> +
> +    if ( rc == -ENOSPC )
> +        panic("Max number of supported reserved-memory regions reached.");
> +    else if ( rc != -ENOENT )
> +        return rc;
> +    return 0;
> +}
> +
> +static int __init process_reserved_memory(const void *fdt, int node,
> +                                          const char *name, int depth,
> +                                          u32 address_cells, u32 size_cells)
> +{
> +    return device_tree_for_each_node(fdt, node,
> +                                     process_reserved_memory_node,
> +                                     &bootinfo.reserved_mem);
> +}
> +
>  static void __init process_multiboot_node(const void *fdt, int node,
>                                            const char *name,
>                                            u32 address_cells, u32 size_cells)
> @@ -295,7 +321,10 @@ static int __init early_scan_node(const void *fdt,
>
>      if ( device_tree_node_matches(fdt, node, "memory") )
>          rc = process_memory_node(fdt, node, name, depth,
> -                                 address_cells, size_cells, NULL);
> +                                 address_cells, size_cells, &bootinfo.mem);
> +    else if ( depth == 1 && !strcmp(name, "reserved-memory") )
I believe you want to use dt_node_cmp() there.

> +        rc = process_reserved_memory(fdt, node, name, depth,
> +                                     address_cells, size_cells);
>      else if ( depth <= 3 && (device_tree_node_compatible(fdt, node, 
> "xen,multiboot-module" ) ||
>                device_tree_node_compatible(fdt, node, "multiboot,module" )))
>          process_multiboot_node(fdt, node, name, address_cells, size_cells);
> diff --git a/xen/include/asm-arm/setup.h b/xen/include/asm-arm/setup.h
> index 8bf3d5910a..efcba545c2 100644
> --- a/xen/include/asm-arm/setup.h
> +++ b/xen/include/asm-arm/setup.h
> @@ -66,6 +66,7 @@ struct bootcmdlines {
>
>  struct bootinfo {
>      struct meminfo mem;
> +    struct meminfo reserved_mem;
>      struct bootmodules modules;
>      struct bootcmdlines cmdlines;
>  #ifdef CONFIG_ACPI


--
Volodymyr Babchuk at EPAM
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.