public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: x86@kernel.org, kexec@lists.infradead.org,
	Simon Horman <horms@verge.net.au>,
	yinghai@kernel.org, Thomas Renninger <trenn@suse.de>,
	vgoyal@redhat.com
Subject: Re: [PATCH 0/3] Cleanup kdump memmap= passing and e820 usage
Date: Wed, 30 Jan 2013 14:29:04 -0800	[thread overview]
Message-ID: <87ehh2l2z3.fsf@xmission.com> (raw)
In-Reply-To: <51099A3E.5090705@zytor.com> (H. Peter Anvin's message of "Wed, 30 Jan 2013 14:10:06 -0800")

"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.

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.

Eric


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

  reply	other threads:[~2013-01-30 22:29 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 [this message]
2013-01-30 22:41                         ` H. Peter Anvin
2013-01-30 22:49                           ` Yinghai Lu
2013-01-31  0:15                         ` Thomas Renninger
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=87ehh2l2z3.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=trenn@suse.de \
    --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