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

Dave Young dyoung at redhat.com
Thu Apr 10 23:10:58 PDT 2014


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.

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?

Thanks
Dave



More information about the kexec mailing list