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
