All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Renninger <trenn@suse.de>
To: Yinghai Lu <yinghai@kernel.org>
Cc: x86@kernel.org, kexec@lists.infradead.org,
	linux-kernel@vger.kernel.org, horms@verge.net.au,
	"H. Peter Anvin" <hpa@zytor.com>,
	vgoyal@redhat.com
Subject: Re: [PATCH 2/2] x86 e820: Introduce memmap=resetusablemap for kdump usage
Date: Tue, 29 Jan 2013 10:47:34 +0100	[thread overview]
Message-ID: <201301291047.34957.trenn@suse.de> (raw)
In-Reply-To: <CAE9FiQWDcFR+6L-GiR6rk60TC0zH=xewyH_h1Rx_QB+8PTiU3Q@mail.gmail.com>

On Tuesday, January 29, 2013 03:10:38 AM Yinghai Lu wrote:
> On Mon, Jan 28, 2013 at 5:11 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> So I guess the final patch should be:
> >>    - Add a new e820 type:
> >>         E820_KDUMP_RESERVED /* Originally usable memory where the crashed
> >>                                                     kernel kernel resided in */
> >>   - Use Yinghai's last posted patch, but instead of:
> >> +                     e820_update_range(0, ULLONG_MAX, E820_RAM,
> >> +                                       E820_RESERVED);
> >> ...
> >> +                     e820_remove_range(start_at, mem_size, E820_RESERVED, 0);
> >> do:
> >> +                     e820_update_range(0, ULLONG_MAX, E820_RAM,
> >> +                                       E820_KDUMP_RESERVED);
> >> ...
> >> +                     e820_remove_range(start_at, mem_size, E820_KDUMP_RESERVED, 0);
> >>
> >>   - Come up with another memmap=kdump_reserve_ram memmap option name
> >>     or however it should get named...
> >>
> >> If this proposal gets accepted, I can send a tested patch...
> >>
> >
> > Yes, this is much saner.  There really shouldn't need to be an option,
> > even; since the tools need to be modified anyway, just modify the actual
> > memory map data structure itself.
> 
> yes,
> 
> kexec-tools will change that to E820_KDUMP_RESERVED (or other good name).
> 
> We only need to update kernel to get old max_pfn by
> checking E820_KDUMP_RESERVED.

Wait, above proposal does not include kexec-tools mangling of the
e820 table, for several reasons:

- Keep the boot interface clean and pass the original table
- Only one possible error source on e820 table modifications
- While hpa proposed kexec-tools to pass a modified e820 table to
  make things easier, exactly the opposite is the case:
  If kexec-tools and the kernel modify the table, things are more
  complex and hard to understand in case of debugging where things
  went wrong
- It's really easy to do that in the kernel. As shown above it should
  simply be this line to change usable areas into E820_KDUMP_RESERVED
  ones:
  e820_update_range(0, ULLONG_MAX, E820_RAM, E820_KDUMP_RESERVED);
  and possibly slight adjusting when the memmap=X#Y memory
  the kdump kernel uses is added (has to override E820_KDUMP_RESERVED
  areas with usable memory again)

My previously posted kexec-tools patches should simply work,
it's just that the memmap option name changes to:
memmap=kdump_reserve_ram

This is what I proposed and is IMO the best and less complex
way to go. I guess I still wait another day for comments and
will send something if you agree.

   Thomas

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

WARNING: multiple messages have this Message-ID (diff)
From: Thomas Renninger <trenn@suse.de>
To: Yinghai Lu <yinghai@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	kexec@lists.infradead.org, vgoyal@redhat.com, horms@verge.net.au
Subject: Re: [PATCH 2/2] x86 e820: Introduce memmap=resetusablemap for kdump usage
Date: Tue, 29 Jan 2013 10:47:34 +0100	[thread overview]
Message-ID: <201301291047.34957.trenn@suse.de> (raw)
In-Reply-To: <CAE9FiQWDcFR+6L-GiR6rk60TC0zH=xewyH_h1Rx_QB+8PTiU3Q@mail.gmail.com>

On Tuesday, January 29, 2013 03:10:38 AM Yinghai Lu wrote:
> On Mon, Jan 28, 2013 at 5:11 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> >> So I guess the final patch should be:
> >>    - Add a new e820 type:
> >>         E820_KDUMP_RESERVED /* Originally usable memory where the crashed
> >>                                                     kernel kernel resided in */
> >>   - Use Yinghai's last posted patch, but instead of:
> >> +                     e820_update_range(0, ULLONG_MAX, E820_RAM,
> >> +                                       E820_RESERVED);
> >> ...
> >> +                     e820_remove_range(start_at, mem_size, E820_RESERVED, 0);
> >> do:
> >> +                     e820_update_range(0, ULLONG_MAX, E820_RAM,
> >> +                                       E820_KDUMP_RESERVED);
> >> ...
> >> +                     e820_remove_range(start_at, mem_size, E820_KDUMP_RESERVED, 0);
> >>
> >>   - Come up with another memmap=kdump_reserve_ram memmap option name
> >>     or however it should get named...
> >>
> >> If this proposal gets accepted, I can send a tested patch...
> >>
> >
> > Yes, this is much saner.  There really shouldn't need to be an option,
> > even; since the tools need to be modified anyway, just modify the actual
> > memory map data structure itself.
> 
> yes,
> 
> kexec-tools will change that to E820_KDUMP_RESERVED (or other good name).
> 
> We only need to update kernel to get old max_pfn by
> checking E820_KDUMP_RESERVED.

Wait, above proposal does not include kexec-tools mangling of the
e820 table, for several reasons:

- Keep the boot interface clean and pass the original table
- Only one possible error source on e820 table modifications
- While hpa proposed kexec-tools to pass a modified e820 table to
  make things easier, exactly the opposite is the case:
  If kexec-tools and the kernel modify the table, things are more
  complex and hard to understand in case of debugging where things
  went wrong
- It's really easy to do that in the kernel. As shown above it should
  simply be this line to change usable areas into E820_KDUMP_RESERVED
  ones:
  e820_update_range(0, ULLONG_MAX, E820_RAM, E820_KDUMP_RESERVED);
  and possibly slight adjusting when the memmap=X#Y memory
  the kdump kernel uses is added (has to override E820_KDUMP_RESERVED
  areas with usable memory again)

My previously posted kexec-tools patches should simply work,
it's just that the memmap option name changes to:
memmap=kdump_reserve_ram

This is what I proposed and is IMO the best and less complex
way to go. I guess I still wait another day for comments and
will send something if you agree.

   Thomas

  parent reply	other threads:[~2013-01-29  9:47 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22 15:20 [PATCH 0/2] Only parse exactmap once, introduce memmap=resetusablemap Thomas Renninger
2013-01-22 15:20 ` Thomas Renninger
2013-01-22 15:20 ` [PATCH 1/2] x86 e820: Check for exactmap appearance when parsing first memmap option Thomas Renninger
2013-01-22 15:20   ` Thomas Renninger
2013-01-22 19:33   ` Yinghai Lu
2013-01-22 19:33     ` Yinghai Lu
2013-01-29  1:09   ` H. Peter Anvin
2013-01-29  1:09     ` H. Peter Anvin
2013-01-29  2:01     ` Yinghai Lu
2013-01-29  2:01       ` Yinghai Lu
2013-01-22 15:20 ` [PATCH 2/2] x86 e820: Introduce memmap=resetusablemap for kdump usage Thomas Renninger
2013-01-22 15:20   ` Thomas Renninger
2013-01-22 15:54   ` H. Peter Anvin
2013-01-22 15:54     ` H. Peter Anvin
2013-01-22 16:23     ` Thomas Renninger
2013-01-22 16:23       ` Thomas Renninger
2013-01-22 16:32       ` H. Peter Anvin
2013-01-22 16:32         ` H. Peter Anvin
2013-01-22 20:06         ` Yinghai Lu
2013-01-24  4:07           ` Yinghai Lu
2013-01-24  4:07             ` Yinghai Lu
2013-01-29  1:05             ` Thomas Renninger
2013-01-29  1:05               ` Thomas Renninger
2013-01-29  1:11               ` H. Peter Anvin
2013-01-29  1:11                 ` H. Peter Anvin
2013-01-29  2:10                 ` Yinghai Lu
2013-01-29  2:10                   ` Yinghai Lu
2013-01-29  2:11                   ` H. Peter Anvin
2013-01-29  2:11                     ` H. Peter Anvin
2013-01-29  2:19                     ` Yinghai Lu
2013-01-29  2:19                       ` Yinghai Lu
2013-01-29  2:20                       ` H. Peter Anvin
2013-01-29  2:20                         ` H. Peter Anvin
2013-01-29  2:27                       ` H. Peter Anvin
2013-01-29  2:27                         ` H. Peter Anvin
2013-01-29  2:31                         ` Yinghai Lu
2013-01-29  2:31                           ` Yinghai Lu
2013-01-29  3:33                           ` H. Peter Anvin
2013-01-29  3:33                             ` H. Peter Anvin
2013-01-29  9:47                   ` Thomas Renninger [this message]
2013-01-29  9:47                     ` Thomas Renninger

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=201301291047.34957.trenn@suse.de \
    --to=trenn@suse.de \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vgoyal@redhat.com \
    --cc=x86@kernel.org \
    --cc=yinghai@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.