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

Re: [Xen-devel] Supporting systems with large E820 maps



>>> On 20.03.17 at 20:03, <alex.thorlton@xxxxxxx> wrote:
> --- xen.orig/arch/x86/e820.c
> +++ xen/arch/x86/e820.c
> @@ -134,7 +134,7 @@ static struct change_member *change_poin
>  static struct e820entry *overlap_list[E820MAX] __initdata;
>  static struct e820entry new_bios[E820MAX] __initdata;
> 
> -static int __init sanitize_e820_map(struct e820entry * biosmap, char * 
> pnr_map)
> +static int __init sanitize_e820_map(struct e820entry * biosmap, unsigned int 
> * pnr_map)
>  {
>      struct change_member *change_tmp;
>      unsigned long current_type, last_type;
> @@ -509,13 +509,13 @@ static void __init reserve_dmi_region(vo
>      }
>  }
> 
> -static void __init machine_specific_memory_setup(struct e820entry *raw, char 
> *raw_nr)
> +static void __init machine_specific_memory_setup(struct e820entry *raw, 
> unsigned int *raw_nr)

I'm confused: staging has

static void __init machine_specific_memory_setup(
    struct e820entry *raw, unsigned int *raw_nr)
{

>  {
>      unsigned long mpt_limit, ro_mpt_limit;
>      uint64_t top_of_ram, size;
>      int i;
> 
> -    char nr = (char)*raw_nr;
> +    unsigned int nr = (unsigned int)*raw_nr;
>      sanitize_e820_map(raw, &nr);
>      *raw_nr = nr;
>      (void)copy_e820_map(raw, nr);
> --->8
> 
> I didn't need to go all the way up to unsigned int here, but I did this
> as a quick/dirty test to see if it got things working.

I think this type change could be submitted right away (properly
cleaned up for style). After all when plain char is a signed type
(which it is allowed to be) it won't cope with 128 entries.

> These small changes get our large machine to boot up and recognize all
> 32TB of available RAM.  I know that these changes are probably not what
> we'll want to go with in the end, but I wanted to get them sent upstream
> to get a dialogue started.
> 
> So, what do others think here?  How do we want to handle a large E820
> map?  Boris mentioned to me that we might want to attempt to do a
> dynamic allocation scheme, where we reserve more space for the memory
> map when we detect that E820 is large.

Since Jürgen says he already has something ready, I think there's
not much else to say.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

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