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

Re: [Xen-devel] [PATCH] xen/x86: Increase xen_e820_map to E820_X_MAX possible entries



On Tue, Nov 15, 2016 at 07:30:35AM +0100, Ingo Molnar wrote:
> 
> * Alex Thorlton <athorlton@xxxxxxx> wrote:
> 
> > On systems with sufficiently large e820 tables, and several IOAPICs, it
> > is possible for the XENMEM_machine_memory_map callback (and its
> > counterpart, XENMEM_memory_map) to attempt to return an e820 table with
> > more than 128 entries.  This callback adds entries to the BIOS-provided
> > e820 table to account for IOAPIC registers, which, on sufficiently large
> > systems, can result in an e820 table that is too large to copy back into
> > xen_e820_map.
> > 
> > This change simply increases the size of xen_e820_map to E820_X_MAX to
> > ensure that there is enough room to store the entire e820 map returned
> > from this callback.
> 
> This means:
> 
>  #ifdef CONFIG_EFI
>  #include <linux/numa.h>
>  #define E820_X_MAX (E820MAX + 3 * MAX_NUMNODES)
>  #else   /* ! CONFIG_EFI */
>  #define E820_X_MAX E820MAX
>  #endif
> 
> It's a bit weird to key it off of CONFIG_EFI - why isn't it unconditional?
> 
> But I have no objections to the principle if it fixes a crash.

I originally thought that Juergen and Jan's alternative solution
eliminated the need for my change, but it appears that I was incorrect,
at least if we want to get the kernel booting on the older HV
without having to modify it.

I'll remove the ifdef here to make this unconditional.

Thanks, Ingo!

- Alex

_______________________________________________
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®.