kexec, x86: Need a new e820 type support for kexec
Baoquan He
bhe at redhat.com
Tue Aug 18 01:53:30 PDT 2015
On 08/06/15 at 07:13pm, Toshi Kani wrote:
> On Thu, 2015-08-06 at 16:12 +0800, Baoquan He wrote:
> E820_PMEM cannot be emulated by the "memmap=" option. Do you have to use
> the "memmap=" options to pass the ranges for kdump kernel? If so, I'd
> rather ignore E820_PMEM and let it be passed as E820_RESERVED. The kdump
> kernel can still obtain the info from NFIT if necessary.
>
> As for the code change...
>
> > @@ -640,6 +644,8 @@ static void cmdline_add_memmap_internal(char *cmdline,
> > unsigned long startk,
> > strcat (str_mmap, "K$");
> > else if (type == RANGE_ACPI || type == RANGE_ACPI_NVS)
> > strcat (str_mmap, "K#");
> > + else if (type == RANGE_PMEM || type == RANGE_PRAM)
> > + strcat (str_mmap, "K!");
>
> It should only check with RANGE_PRAM, but I do not think this change matters
> much unless you also modify the caller cmdline_add_memmap(), which has the
> following check to skip other types. I do not think we will use legacy
> NVDIMM device as a dump device, so you may ignore RANGE_PRAM and let it be
> passed as RESERVED as well (which is likely the case I tested with).
Rethink it again, maybe it's better to pass PMEM as PRAM to kdump
kernel if user really want to use memmap way by specifying
--pass-memmap-cmdline. Then I need add the PMEM and PRAM checking here
you pointed out. Will repost with them.
>
> /* Only adding memory regions of RAM and ACPI */
> if (type != RANGE_RAM &&
> type != RANGE_ACPI &&
> type != RANGE_ACPI_NVS)
> continue;
>
More information about the kexec
mailing list