Kexec Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Young <dyoung@redhat.com>
To: WANG Chao <chaowang@redhat.com>
Cc: kexec@lists.infradead.org, horms@verge.net.au, linn@hp.com,
	hpa@zytor.com, trenn@suse.de, vgoyal@redhat.com,
	ebiederm@xmission.com
Subject: Re: [PATCH v5 06/10] x86, cleanup: Store crash memory ranges kexec_info
Date: Fri, 11 Apr 2014 14:10:58 +0800	[thread overview]
Message-ID: <20140411061058.GA4700@dhcp-16-198.nay.redhat.com> (raw)
In-Reply-To: <20140411031746.GG2944@dhcp-17-89.nay.redhat.com>

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@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

_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

  reply	other threads:[~2014-04-11  6:31 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-10  9:12 [PATCH v5 00/10] kexec-tools, x86: E820 memmap pass for kdump WANG Chao
2014-04-10  9:12 ` [PATCH v5 01/10] x86, cleanup: fix indent WANG Chao
2014-04-10  9:12 ` [PATCH v5 02/10] x86, cleanup: add extra arguments to add_memmap() and delete_memmap() WANG Chao
2014-04-11  2:22   ` Dave Young
2014-04-11  4:47     ` WANG Chao
2014-04-10  9:12 ` [PATCH v5 03/10] x86, cleanup: add other types of memory range for 2nd kernel boot to memmap_p WANG Chao
2014-04-11  2:24   ` Dave Young
2014-04-11  3:02     ` WANG Chao
2014-04-10  9:12 ` [PATCH v5 04/10] x86, cleanup: add_memmap() only do alignment check on RANGE_RAM WANG Chao
2014-04-10  9:12 ` [PATCH v5 05/10] x86, cleanup: use dbgprint_mem_range for memory range debugging WANG Chao
2014-04-10 20:18   ` Linn Crosetto
2014-04-11  2:00     ` Dave Young
2014-04-11  2:11       ` WANG Chao
2014-04-10  9:12 ` [PATCH v5 06/10] x86, cleanup: increase CRASH_MAX_MEMMAP_NR up to CRASH_MAX_MEMORY_RANGES WANG Chao
2014-04-10  9:13 ` [PATCH v5 06/10] x86, cleanup: Store crash memory ranges kexec_info WANG Chao
2014-04-11  2:20   ` Dave Young
2014-04-11  3:17     ` WANG Chao
2014-04-11  6:10       ` Dave Young [this message]
2014-04-11  6:50         ` WANG Chao
2014-04-11  7:02           ` Dave Young
2014-04-10  9:13 ` [PATCH v5 07/10] x86, cleanup: Add a funtion add_setup_data() WANG Chao
2014-04-10  9:13 ` [PATCH v5 07/10] x86, cleanup: Store crash memory ranges kexec_info WANG Chao
2014-04-10  9:13 ` [PATCH v5 08/10] x86: add --pass-memmap-cmdline option WANG Chao
2014-04-10  9:13 ` [PATCH v5 08/10] x86, cleanup: Add a funtion add_setup_data() WANG Chao
2014-04-10  9:13 ` [PATCH v5 09/10] x86: add --pass-memmap-cmdline option WANG Chao
2014-04-10  9:13 ` [PATCH v5 09/10] x86: Pass memory range via E820 for kdump WANG Chao
2014-04-11  2:28   ` Dave Young
2014-04-11  2:36     ` H. Peter Anvin
2014-04-11  2:47       ` Dave Young
2014-04-11  2:55         ` H. Peter Anvin
2014-04-11  3:00         ` WANG Chao
2014-04-11  3:33           ` WANG Chao
2014-04-11  2:06 ` [PATCH v5 00/10] kexec-tools, x86: E820 memmap pass " Dave Young
2014-04-11  2:14   ` WANG Chao
2014-04-11  3:05 ` WANG Chao

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140411061058.GA4700@dhcp-16-198.nay.redhat.com \
    --to=dyoung@redhat.com \
    --cc=chaowang@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=linn@hp.com \
    --cc=trenn@suse.de \
    --cc=vgoyal@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox