[PATCH v6 9/9] x86: Pass memory range via E820 for kdump

[Dave Young]

[snip]

> > > > I prefer to first get this patch in if there's no problem in it and then
> > > > look back and think about how we can clean up the code block which have
> > > > been there for historical reason.
> > > 
> > > I think the cleanup is worth, but if you want to do it later I'm fine.
> > > So should better leave the patch 5/9 to later cleanup as well.
> > > 
> > > Thus except for 5/9, for other patches:
> > > Acked-by: Dave Young <dyoung at redhat.com>
> 
> Hi, Simon
> 
> Later, after a discussion with Dave Young, he is ok with 5/9. Here's his
> ACK for the whole patch series:
> 
> http://lists.infradead.org/pipermail/kexec/2014-April/011615.html
> 
> I'll explain why 5/9 is necessary below.

Yes, it's fine to me for the whole series after more discussion as Chao
mentioned below. In the future if kexec and kdump cases can use just one
array then this macro can be removed that time. 


> Patch 5/9 increased memmap_p from a small array to a large one. That
> patch is necessary.
> 
> Originally memmap_p was used to store the RANGE_RAM only for 2nd kernel
> and that was fine for memmap_p to be small, since we only have several
> memory range of RANGE_RAM to be passed to 2nd kernel.
> 
> However now memmap_p will be used to store all types of memory ranges to
> pass to 2nd kernel, which means not only RANGE_RAM but also RANGE_ACPI
> and RANGE_ACPI_NVS (probably RANGE_RESERVED in the future). That small
> memmap_p is not likely to be enough to contain all the memory ranges. So
> that's why we should increase CRASH_MAX_MEMMAP_NR to about 1024 to adapt
> the change of memmap_p will contains all type of memory ranges.

Thanks
Dave