[Patch v3] Add persistent memory support

[Dave Young]

On 08/24/15 at 01:54pm, Toshi Kani wrote:
> On Thu, 2015-08-20 at 15:42 +0800, Dave Young wrote:
> > On 08/20/15 at 10:52am, Baoquan He wrote:
> > > On 08/20/15 at 10:38am, Dave Young wrote:
> > > > On 08/19/15 at 06:45pm, Baoquan He wrote:
> > > > > On 08/19/15 at 05:28pm, Dave Young wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On 08/19/15 at 05:03pm, Baoquan He wrote:
> > > > >   
> > > > > > > diff --git a/kexec/arch/i386/crashdump-x86.c 
> > > > > > > b/kexec/arch/i386/crashdump-x86.c
> > > > > > > index 82bf239..598a78f 100644
> > > > > > > --- a/kexec/arch/i386/crashdump-x86.c
> > > > > > > +++ b/kexec/arch/i386/crashdump-x86.c
> > > > > > > @@ -301,6 +301,10 @@ static int get_crash_memory_ranges(struct 
> > > > > > > memory_range **range, int *ranges,
> > > > > > >  			type = RANGE_ACPI;
> > > > > > >  		} else if(memcmp(str,"ACPI Non-volatile 
> > > > > > > Storage\n",26) == 0 ) {
> > > > > > >  			type = RANGE_ACPI_NVS;
> > > > > > > +		} else if(memcmp(str,"Persistent Memory 
> > > > > > > (legacy)\n",27) == 0 ) {
> > > > > > > +			type = RANGE_PRAM;
> > > > > > > +		} else if(memcmp(str,"Persistent Memory\n",18) 
> > > > > > > == 0 ) {
> > > > > > > +			type = RANGE_PMEM;
> > > > > > >  		} else if(memcmp(str,"reserved\n",9) == 0 ) {
> > > > > > >  			type = RANGE_RESERVED;
> > > > > > >  		} else if (memcmp(str, "GART\n", 5) == 0) {
> > > > > > > @@ -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_PRAM)
> > > > > > > +		strcat (str_mmap, "K!");
> > > > > > 
> > > > > > Since we have switched to use e820 it is not necessary to 
> > > > > > supporting new things in legacy memmap interface?
> > > > > 
> > > > > Well, I am not sure about this. Kexec-tools provides memmap method 
> > > > > to pass the memory ranges, then either we continue supporting it or 
> > > > > we delete it. Now is this OK we just keep legacy memmap code there 
> > > > > and ignore it? If people check the man page and find --pass-memmap
> > > > > -cmdline and intend to try, then kexec/kdump fail, then how do we go 
> > > > > with it?
> > > > 
> > > > It is a legacy interface, IMO we should deprecate it and remove it 
> > > > after a period like several release cycle.
> > > 
> > > So if customers still want to specify memmap there isn't a way.
> > > 
> > 
> > Why do one use memmap with new kexec-tools?
> > 
> > There's no reason to use the old interface, I do not think there's any 
> > benefit since new interface works well and be more scalable.
> 
> Unless --pass-memmap-cmdline has already been deprecated, I think it should
> keep up with the kernel update in the memmap cmd-line.  IOW, if we do not
> keep it up, it should be marked as deprecated.

Hmm, after looking into old discussion, I found that the options is there for
the known issue for calgary iommu. I really doubt there's someone is using it
but who knows.

calgary code uses saved_max_pfn which is only calculaed when there's memmap=exactmap
cmdline params. So before removing the limitation we still need carry the old
interface.

Hence, I will not object Bao's changes in his patch any more.

Thanks
Dave