From: Thomas Renninger <trenn@suse.de>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: x86@kernel.org, kexec@lists.infradead.org,
Simon Horman <horms@verge.net.au>,
"H. Peter Anvin" <hpa@zytor.com>,
yinghai@kernel.org, vgoyal@redhat.com
Subject: Re: [PATCH 0/3] Cleanup kdump memmap= passing and e820 usage
Date: Thu, 31 Jan 2013 01:15:34 +0100 [thread overview]
Message-ID: <2271353.GLUCBHDxBG@hammer82.arch.suse.de> (raw)
In-Reply-To: <87ehh2l2z3.fsf@xmission.com>
On Wednesday, January 30, 2013 02:29:04 PM Eric W. Biederman wrote:
> "H. Peter Anvin" <hpa@zytor.com> writes:
> > On 01/30/2013 01:57 PM, Eric W. Biederman wrote:
> >>> Yes, those seem to be the options, and we're currently discussing which
> >>> one.
> >>>
> >>> The second seems to make more sense to me. The kexec tools build the
> >>> memory map anyway, and it makes sense to me at least to just build a
> >>> memory map with the appropriate regions marked as a dumpable type.
> >>
> >> This dumpable type doesn't make sense to me. Are you suggesting making
> >> regions that are memory but that we should not use a special memory
> >> type?
> >
> > Yes.
> >
> >> I think I would prefer that to call that new type RESERVED_MEM or
> >> RESERVED_CACHABLE. Being more specific is fine but dumpable certainly
> >> doesn't bring to mind what we are saying. Especially since we already
> >> communicate which areas were memory to the last kernel in an
> >> architecture generic format.
> >
> > I was thinking that marking them differently might help debugging, at
> > least, but yes, we can have a RESERVED_MEM type.
> >
> > However, Thomas does have a point that the current use of fairly small
> > positive values for Linux-defined types is a bad idea. We should use
> > negative types, or at least something north of 0x40000000 or so.
>
> Yes. It doesn't much matter in the kernel but when it because part of
> the ABI it is a real issue.
That's one point (self made up e820 type should better be kept kernel
internal).
> Since old kernels treat any value they don't understand as reserved
> passing a modified e820 map seems reasonable to me once we have reserved
> a special linux value for it.
The other one: Why should several instances modify the e820 table
if this is not necessary?
I guess both ways are a huge enhancement compared to what we have now.
Which approach to finally take should not matter that much, but because
of above I still prefer to go this way:
- Pass a kernel command line option that just changes the kernels idea
of which memory it can touch
Whether the value(s) of these types should be ramped up is a different
discussion then. If they still should have bigger values, this can be
addressed by a separate patch now or later to whatever you like to see.
Thomas
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-01-31 0:15 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-22 15:02 [PATCH 0/3] Make use of new memmap= kernel parameter syntax Thomas Renninger
2013-01-22 15:02 ` [PATCH 1/3] kexec: Split kernel_version() to also be able to pass a release string Thomas Renninger
2013-01-22 15:02 ` [PATCH 2/3] kexec x86: Extract kernel version and convert it to KERNEL_VERSION() style Thomas Renninger
2013-01-22 15:02 ` [PATCH 3/3] kexec x86: Make kexec aware of new memmap= kernel parameter possibilities Thomas Renninger
2013-01-30 4:31 ` [PATCH 0/3] Make use of new memmap= kernel parameter syntax Simon Horman
2013-01-30 5:40 ` H. Peter Anvin
2013-01-30 5:52 ` Simon Horman
2013-01-30 16:03 ` Thomas Renninger
2013-01-30 16:06 ` [PATCH 1/3] x86 e820: Check for exactmap appearance when parsing first memmap option Thomas Renninger
2013-01-30 16:09 ` H. Peter Anvin
2013-01-30 16:08 ` [PATCH 2/3] x86: Introduce Linux kernel specific E820_RESERVED_KDUMP e820 memory range type Thomas Renninger
2013-01-30 16:10 ` [PATCH 3/3] x86 e820: Introduce memmap=kdump_reserve_usable for kdump usage Thomas Renninger
2013-01-30 16:10 ` [PATCH 0/3] Make use of new memmap= kernel parameter syntax H. Peter Anvin
2013-01-30 16:13 ` [PATCH 0/3] Cleanup kdump memmap= passing and e820 usage Thomas Renninger
2013-01-30 16:16 ` H. Peter Anvin
2013-01-30 16:39 ` Thomas Renninger
2013-01-30 16:52 ` H. Peter Anvin
2013-01-30 17:41 ` Yinghai Lu
2013-01-30 18:52 ` Eric W. Biederman
2013-01-30 21:38 ` H. Peter Anvin
2013-01-30 21:57 ` Eric W. Biederman
2013-01-30 22:10 ` H. Peter Anvin
2013-01-30 22:29 ` Eric W. Biederman
2013-01-30 22:41 ` H. Peter Anvin
2013-01-30 22:49 ` Yinghai Lu
2013-01-31 0:15 ` Thomas Renninger [this message]
2013-01-31 0:18 ` H. Peter Anvin
2013-01-31 9:11 ` Thomas Renninger
2013-02-06 15:23 ` Thomas Renninger
2013-02-06 23:04 ` Eric W. Biederman
2013-02-06 23:11 ` H. Peter Anvin
2013-02-06 23:39 ` Eric W. Biederman
2013-02-08 20:08 ` Thomas Renninger
2013-02-08 20:25 ` Eric W. Biederman
2013-02-08 20:56 ` 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=2271353.GLUCBHDxBG@hammer82.arch.suse.de \
--to=trenn@suse.de \
--cc=ebiederm@xmission.com \
--cc=horms@verge.net.au \
--cc=hpa@zytor.com \
--cc=kexec@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox