Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753161AbbHRPDS (ORCPT ); Tue, 18 Aug 2015 11:03:18 -0400 Received: from g9t5009.houston.hp.com ([15.240.92.67]:46982 "EHLO g9t5009.houston.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634AbbHRPDR (ORCPT ); Tue, 18 Aug 2015 11:03:17 -0400 Message-ID: <1439910078.24434.106.camel@hp.com> Subject: Re: kexec, x86: Need a new e820 type support for kexec From: Toshi Kani To: Baoquan He Cc: dan.j.williams@intel.com, hch@lst.de, linux-nvdimm@ml01.01.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org Date: Tue, 18 Aug 2015 09:01:18 -0600 In-Reply-To: <20150818085330.GB15480@dhcp-128-28.nay.redhat.com> References: <1437697592.3214.373.camel@hp.com> <20150806081231.GA16699@dhcp-128-28.nay.redhat.com> <1438910038.3109.116.camel@hp.com> <20150818085330.GB15480@dhcp-128-28.nay.redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.4 (3.16.4-2.fc22) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2213 Lines: 54 On Tue, 2015-08-18 at 16:53 +0800, Baoquan He wrote: > 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. No, you should not report PMEM as PRAM. They are different things. The kdump kernel does not need to support memmap cmdline for PMEM, as the regular kernel does not -- memmap cmdline cannot emulate PMEM. Thanks, -Toshi > > > > > > /* Only adding memory regions of RAM and ACPI */ > > if (type != RANGE_RAM && > > type != RANGE_ACPI && > > type != RANGE_ACPI_NVS) > > continue; > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/