On Saturday, January 12, 2013 09:07:12 AM Yinghai Lu wrote:
> On Sat, Jan 12, 2013 at 3:31 AM, Thomas Renninger <tr...@suse.de> wrote:
> > memmap=exactmap [KNL,X86] Enable setting of an exact
> >
> > - E820 memory map, as specified by the user.
> > - Such memmap=exactmap lines can be constructed
> > based on - BIOS output or other requirements. See
> > the memmap=nn@ss - option description.
> > + E820 usable memory map, as specified by the user.
> > + All unusable (reserved, ACPI, NVS,...) ranges from
> > the + original e820 table are preserved.
> > + But the usable memory regions from the original
> > e820 + table are removed.
> > + This parameter is explicitly for kdump usage:
> > + The memory the kdump kernel is allowed to use must
> > + be passed via below memmap=nn[KMG]@ss[KMG] param.
> > + All reserved regions the kernel may use for
> > ioremapping + and similar are still considered.
> > +
> > + memmap=voidmap [KNL,X86] Do not use any e820 ranges from BIOS or
> > + bootloader. Instead you have to pass regions via
> > + below memmap= options.
>
> I would suggest to keep memmap=exactmap meaning not changed, and add
> memmap=exactusablemap
> instead.
I disagree.
I would like to change memmap=exactmap behavior.
Why:
1)
This is a sever bug (for kdump/kexec). I could imagine quite a lot
kdump related bugs get silently solved by this fix.
I expect we agree that the change, however it looks like in the end, should
still get in in this kernel round?
With my approach, I would also suggest to spread this to stable kernels.
-> No need to update/patch kexec-tools, things will just work as they should.
2)
I would introduce 2 new memmap= options. However they look like, for example:
=void_usable_map
=void_orig_map
and deprecated exactmap= via
printk(KERN_INFO "exactmap usage changed and is deprecated\n");
but still fix it.
Latest kexec-tools will just use memmap=void_usable_map, old ones
are still fixed via stable kernel updates.
> kexec-tools could be updated to support exactusablemap with
> kernelversion checking for kdump.
No, please not. It will be a maintenance/compatibility issue that will remain
for years or ever in kdump and/or the kernel and it's not necessary.
> also we need to double check to make sure:
> 1. exactmap should override exactusablemap, even the out of order sequence.
So that one can override the whole map in kdump case (which was broken until
today)?
I agree. But in my case it would be:
=void_orig_map overrides =void_usable_map
> 2. when exactusablemap is used, not just remove old usable type range,
> also need to remove overlapped range
> with new usable range.
Why should this be necessary?
The e820 map passed by BIOS/bootloader should already be sanity checked
-> no overlaps.
Then usable ranges are removed and the memmap= defined are added and
sanity check is called again.
-> no overlaps.
Sanity checking prefers reserved/unusable memory ranges (in this case always
using the original ones from BIOS) over usable ones and this is a good idea to
do...
I guess it's up to further votes/comments/ideas and a final maintainer
(kexec/x86?) decision?
Thomas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
