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

[Daniel Kiper <daniel.kiper@xxxxxxxxxx>]

On Tue, Mar 21, 2017 at 01:01:44PM +0100, Juergen Gross wrote:
> On 21/03/17 11:05, Jan Beulich wrote:
> >>>> On 21.03.17 at 06:14, <jgross@xxxxxxxx> wrote:
> >> On 20/03/17 20:03, Alex Thorlton wrote:
> >>> Hey everyone,
> >>>
> >>> Recently, I've been working with Boris Ostrovsky to get Xen running on
> >>> some of our larger systems, and we've run into a few problems with the
> >>> amount of space that Xen sets aside for the E820 map.
> >>>
> >>> The first problem that I hit was that E820MAX is far too small, at 128
> >>> entries, for the system that we're testing with.  The EFI memory map
> >>> handed up from the boot loader tops out at 783 entries, which far
> >>> exceeds the amount of space allocated for the memory map in
> >>> arch/x86/boot/mem.S.  I was able to get past this problem by bumping
> >>> E820MAX up to 1024 in arch/x86/boot/mem.S and include/asm-x86/e820.h.
> >>>
> >>> The second problem that I encountered was that Xen uses a signed char to
> >>> store the number of entries in the memory map in a few places, which is
> >>> too small to hold the number of entries after bumping E820MAX up to
> >>> 1024.  I made the following changes to get past this:
> >>
> >> The problem with setting E820MAX to a higher value in mem.S without
> >> further measures is that you are growing the trampoline size. This is
> >> problematic for memory allocation in the multiboot path.
> >>
> >> I have some patches sitting here waiting for Daniel's multiboot series
> >> to go in. My patches are not using the mem.S e820 array for the EFI
> >> memory map, so the BIOS memory map buffer can remain smaller while the
> >> EFI buffer can be made rather large. This avoids growing the trampoline
> >> (in fact I've managed to reduce it to a single page).
> >>
> >> I didn't post my series up to now in order to not block Daniel's series
> >> again. So what do people think: should I wait some more time with my
> >> patches, or should I send them rather soon?
> >
> > I'd say go ahead - whether the rest of Daniel's series will go in for
> > 4.9 is undetermined at this point in time. At the very least we first
> > need to get details on the boot regression Andrew says they're
> > observing with what has gone in already.
>
> Okay. I think I'll just post the first three patches which basically
> will support more EFI memory map entries without affecting the
> assembler parts too much.

This is not a problem for me in general. However, if you can try to not
touch much of the same code as I do then it will be nice. And of course
if you CC me I will be more than happy.

Daniel

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