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

Re: [PATCH v3 4/6] xen/x86: use arch_get_ram_range to get information from E820 map


  • To: Wei Chen <wei.chen@xxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 25 Aug 2022 14:14:22 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=4AmoUbQ6pH/b51sOzjlF0OcJwOkkHcGX4j2xUzL2BQI=; b=FvOqMBvrb91W/v1c7zC8txe98Ud9WqT9bp5PjDqJNzAB7F0RhyX8sg7oXaWS07dP9sgG0yO+SF7ZH4tS+w3Lnu4qGmujOwBFpf7mk6siNDArAH1mylNB79vC+ehDh5+ZyRbsSERpBBunAHzb6iy2dH56sYIJUaK0/LbpniFOrGlUiI3b8v3QrWlsybKrjNAmvgi6Oxn4Ozj7baVzyb8JilsJHfc5bj9Q+8d0+CnnQxcEINGHkOgDVDHh1BNDztujqE+K9rWLbwF4I5kxQAbBK6dGj5LdIexgfo8cz9Fc7mBoLha4VXEOlYsTXY1EZz8BT5Vd4l1lAji6rpLZqrAGfA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mXKAH+1ExCvZIFRpLbJP7QWQaUTHrd1X7N9Eor36bskhyEvlaJb6v92Nd9TwRexK8OsUWiIWPkj7W2aYHVXGyd9hhHHt+XRHYhDqRK4+F2ttFdqD5aAOnCxb547ITXyTBBSN6xUdymAJaz5yNNcDhGMVkprcHg0FNu0eEtm24n2uy0PKhY3lucfseFftaoTdb8sxetjoq4JnTvRlJ9yZ84xCVUVVYOB545DArPr39GDqRjcprYB2TbswB/dvPBS8J0FnE8Zvcb7UQys0Gftg2DiFh5JfeEwv1EHl0YgjTMINQWpC4UyvZhcRiLZGV54GIHE4ECjcXLJK6I24TARmJw==
  • Authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=suse.com;
  • Cc: nd@xxxxxxx, Andrew Cooper <andrew.cooper3@xxxxxxxxxx>, Roger Pau Monné <roger.pau@xxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, George Dunlap <george.dunlap@xxxxxxxxxx>, Julien Grall <julien@xxxxxxx>, Stefano Stabellini <sstabellini@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Thu, 25 Aug 2022 12:14:30 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 22.08.2022 04:58, Wei Chen wrote:
> @@ -96,3 +97,27 @@ unsigned int __init arch_get_dma_bitsize(void)
>                   flsl(node_start_pfn(node) + node_spanned_pages(node) / 4 - 
> 1)
>                   + PAGE_SHIFT, 32);
>  }
> +
> +/*
> + * This function provides the ability for caller to get one RAM entry
> + * from architectural memory map by index.
> + *
> + * This function will return zero if it can return a proper RAM entry.
> + * otherwise it will return -ENOENT for out of scope index, or return
> + * -EINVAL for non-RAM type memory entry.
> + *
> + * Note: the range is exclusive at the end, e.g. [start, end).
> + */
> +int __init arch_get_ram_range(unsigned int idx, paddr_t *start, paddr_t *end)

Since the comment is intended to apply to all architectures providing,
I think it should go with the declaration (once) rather than the
definition (at least one instance per arch).

> +{
> +    if ( idx >= e820.nr_map )
> +        return -ENOENT;
> +
> +    if ( e820.map[idx].type != E820_RAM )
> +        return -EINVAL;

EINVAL is so heavily (over)loaded that I'm inclined to ask to use e.g.
-ENODATA here.

> --- a/xen/arch/x86/srat.c
> +++ b/xen/arch/x86/srat.c
> @@ -428,18 +428,22 @@ acpi_numa_memory_affinity_init(const struct 
> acpi_srat_mem_affinity *ma)
>     Make sure the PXMs cover all memory. */
>  static int __init nodes_cover_memory(void)
>  {
> -     int i;
> +     unsigned int i;
>  
> -     for (i = 0; i < e820.nr_map; i++) {
> +     for (i = 0; ; i++) {
>               int j, found;
>               paddr_t start, end;
>  
> -             if (e820.map[i].type != E820_RAM) {
> +             /* Try to loop memory map from index 0 to end to get RAM 
> ranges. */
> +             found = arch_get_ram_range(i, &start, &end);
> +
> +             /* Index relate entry is not RAM, skip it. */
> +             if (found == -EINVAL)
>                       continue;
> -             }
>  
> -             start = e820.map[i].addr;
> -             end = e820.map[i].addr + e820.map[i].size;
> +             /* Reach the end of arch's memory map */
> +             if (found == -ENOENT)
> +                     break;

What if an arch returns a 3rd error indicator? The way you've written
it code below would assume success and use uninitialized data. I'd
like to suggest to only special-case -ENOENT and treat all other
errors the same. But of course the variable (re)used doesn't really
fit that:

                /* Reach the end of arch's memory map */
                if (found == -ENOENT)
                        break;

                /* Index relate entry is not RAM, skip it. */
                if (found)
                        continue;

because here really you mean "not found". Since in fact "found" would
want to be of "bool" type in the function, and "j" would want to be
"unsigned int" just like "i" is, I recommend introducing a new local
variable, e.g. "err".

Jan

>               do {
>                       found = 0;



 


Rackspace

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