[PATCH v5 06/10] x86, cleanup: Store crash memory ranges kexec_info

[WANG Chao]

On 04/11/14 at 02:10pm, Dave Young wrote:
> On 04/11/14 at 11:17am, WANG Chao wrote:
> > On 04/11/14 at 10:20am, Dave Young wrote:
> > > On 04/10/14 at 05:13pm, WANG Chao wrote:
> > > > Add two new members to kexec_info structure:
> > > > 
> > > > struct memory_range *crash_range
> > > > int nr_crash_ranges;
> > > > 
> > > > crash_range contains the memory ranges used to boot 2nd kernel.
> > > > nr_crash_ranges contains the count of the crash memory ranges.
> > > > 
> > > > Signed-off-by: WANG Chao <chaowang at redhat.com>
> > > > ---
> > > >  kexec/arch/i386/crashdump-x86.c | 6 ++++++
> > > >  kexec/kexec.h                   | 2 ++
> > > >  2 files changed, 8 insertions(+)
> > > > 
> > > > diff --git a/kexec/arch/i386/crashdump-x86.c b/kexec/arch/i386/crashdump-x86.c
> > > > index 2437c30..2a6871d 100644
> > > > --- a/kexec/arch/i386/crashdump-x86.c
> > > > +++ b/kexec/arch/i386/crashdump-x86.c
> > > > @@ -997,6 +997,12 @@ int load_crashdump_segments(struct kexec_info *info, char* mod_cmdline,
> > > >  		add_memmap(memmap_p, &nr_memmap_p, start, size, type);
> > > >  		cmdline_add_memmap_acpi(mod_cmdline, start, end);
> > > >  	}
> > > > +
> > > > +	/* Store 2nd kernel boot memory ranges for later reference in
> > > > +	 * x86-setup-linux.c: setup_linux_system_parameters() */
> > > > +	info->crash_range = memmap_p;
> > > > +	info->nr_crash_ranges = nr_memmap_p;
> > > > +
> > > >  	return 0;
> > > >  }
> > > >  
> > > > diff --git a/kexec/kexec.h b/kexec/kexec.h
> > > > index d69bba2..22d4a42 100644
> > > > --- a/kexec/kexec.h
> > > > +++ b/kexec/kexec.h
> > > > @@ -148,6 +148,8 @@ struct kexec_info {
> > > >  	int nr_segments;
> > > >  	struct memory_range *memory_range;
> > > >  	int memory_ranges;
> > > > +	struct memory_range *crash_range;
> > > > +	int nr_crash_ranges;
> > > 
> > > Is the memory_range field used in crash case? If not how about reuse the field for crash ranges.
> > 
> > We need memory_range field in the --pass-memmap-cmdline case.
> 
> I can not think out why it is needed. In case memmap=exactmap the e820 should be totally ignored.

Actually, we use this e820 to calculate saved_max_pfn.

In memmap=exactmap case, we pass two kinds of e820:

- e820 in boot_params filled with 1st kernel's memmap
- User defined exactmap in kernel cmdline


> 
> It's my understanding for the user defined memmap, but there's could be other tricks.. Could you
> test kdump for dropping the e820 passing with memmap=exactmap?

We can't get rid of passing 1st kernel's memmap as long as saved_max_pfn
is still in use in calgary iommu.

And that's why I introduce --pass-memmap-cmdline as a fallback method
for calgary iommu user with older kernel.

Thanks
WANG Chao