| Message ID | 201301111333.49238.trenn@suse.de (mailing list archive) |
|---|---|
| State | New, archived |
| Delegated to: | Bjorn Helgaas |
| Headers | show |
On Fri, Jan 11, 2013 at 4:33 AM, Thomas Renninger <trenn@suse.de> wrote: >> yes, we have other user for debug like simulating user memmap for some >> bugs. >> current problem for exactmap is that we don't scan that at first. >> attached patch could help that. > > Yep, this is what I would have come up as well or similar. I looked > at it, but I had no time for doing it and trying out. > > You may want to add: > Reviewed-by: Thomas Renninger <trenn@suse.de> > if someone reposts. ok, I will add wrap it up and add changelog and test it then post it with my for-x86-boot. > > Thomas > > ------------------- > x86 e820: only void usable memory areas in memmap=exactmap case > > All unusable (reserved, ACPI, ACPI NVS,...) areas have to be > honored in kdump case. > Othwerise ACPI parts will quickly run into trouble when trying > to for example early_ioremap reserved areas which are not > declared reserved in kdump kernel. > mmconf area must also be a reserved mem region. > ... > > Passing unusable memory via memmap= is a design flaw as > this information is already (exactly for this purpose) passed > via bootloader structure. > In kdump case (when memmap=exactmap is passed), only void > (do not use) usable memory regions from the passed e820 table > and use memory areas defined via memmap=X@Y boot parameter instead. > But do still use the "unusable" memory regions from the original e820 > table. > > Signed-off-by: Thomas Renninger <trenn@suse.de> > > --- > arch/x86/kernel/e820.c | 19 ++++++++++++++++++- > 1 files changed, 18 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c > index dc0b9f0..ae2d657 100644 > --- a/arch/x86/kernel/e820.c > +++ b/arch/x86/kernel/e820.c > @@ -559,6 +559,19 @@ u64 __init e820_remove_range(u64 start, u64 size, unsigned old_type, > return real_removed_size; > } > > +static void __init e820_remove_range_type(u32 type) > +{ > + int i; > + > + for (i = 0; i < e820.nr_map; i++) { > + struct e820entry *ei = &e820.map[i]; > + if (ei->type == type) { > + memset(ei, 0, sizeof(struct e820entry)); > + continue; > + } > + } > +} > + > void __init update_e820(void) > { > u32 nr_map; > @@ -858,7 +871,11 @@ static int __init parse_memmap_one(char *p) > */ > saved_max_pfn = e820_end_of_ram_pfn(); > #endif > - e820.nr_map = 0; > + /* > + * Remove all usable memory (this is for kdump), usable > + * memory will be passed via memmap=X@Y parameter > + */ > + e820_remove_range_type(E820_RAM); We may need to keep exactmap intact. but could add another one like exact_ram_map or extend to have memmap=exactmap=ram or etc. > userdef = 1; > return 0; > } -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Friday, January 11, 2013 08:16:52 AM Yinghai Lu wrote: > On Fri, Jan 11, 2013 at 4:33 AM, Thomas Renninger <trenn@suse.de> wrote: ... > > - e820.nr_map = 0; > > + /* > > + * Remove all usable memory (this is for kdump), usable > > + * memory will be passed via memmap=X@Y parameter > > + */ > > + e820_remove_range_type(E820_RAM); > > We may need to keep exactmap intact. Why? Kexec/kdump should have been the only user? If older/current kexec calls still add ACPI maps via memmap=X#Y, they should already exist in the original e820 map and fall off or get glued to one region if (wrongly) overlapping via sanitize_map. > but could add another one like exact_ram_map > or extend to have memmap=exactmap=ram or etc. I would avoid that if anyhow possible because then you run into kexec vs kernel version problems. Maybe I should explicitly post (out of this thread) the patch to the kexec list. If nobody can come up with a strong reason, it should be ok? Thomas -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 11, 2013 at 10:24 AM, Thomas Renninger <trenn@suse.de> wrote: >> We may need to keep exactmap intact. > Why? > Kexec/kdump should have been the only user? > If older/current kexec calls still add ACPI maps via memmap=X#Y, > they should already exist in the original e820 map and fall off or > get glued to one region if (wrongly) overlapping via sanitize_map. No, kexec/kdump is not the only user for memmap=exactmap. Thanks Yinghai -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/11/2013 11:59 AM, Yinghai Lu wrote: > On Fri, Jan 11, 2013 at 10:24 AM, Thomas Renninger <trenn@suse.de> wrote: >>> We may need to keep exactmap intact. >> Why? >> Kexec/kdump should have been the only user? >> If older/current kexec calls still add ACPI maps via memmap=X#Y, >> they should already exist in the original e820 map and fall off or >> get glued to one region if (wrongly) overlapping via sanitize_map. > > No, kexec/kdump is not the only user for memmap=exactmap. > Who is using it then, since you seem to know? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Fri, Jan 11, 2013 at 12:06 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 01/11/2013 11:59 AM, Yinghai Lu wrote: >> On Fri, Jan 11, 2013 at 10:24 AM, Thomas Renninger <trenn@suse.de> wrote: >>>> We may need to keep exactmap intact. >>> Why? >>> Kexec/kdump should have been the only user? >>> If older/current kexec calls still add ACPI maps via memmap=X#Y, >>> they should already exist in the original e820 map and fall off or >>> get glued to one region if (wrongly) overlapping via sanitize_map. >> >> No, kexec/kdump is not the only user for memmap=exactmap. >> > > Who is using it then, since you seem to know? http://forums.gentoo.org/viewtopic-t-487476-highlight-proliant.html http://forums.fedoraforum.org/archive/index.php/t-225347.html -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/11/2013 01:09 PM, Yinghai Lu wrote: > On Fri, Jan 11, 2013 at 12:06 PM, H. Peter Anvin <hpa@zytor.com> wrote: >> On 01/11/2013 11:59 AM, Yinghai Lu wrote: >>> On Fri, Jan 11, 2013 at 10:24 AM, Thomas Renninger <trenn@suse.de> wrote: >>>>> We may need to keep exactmap intact. >>>> Why? >>>> Kexec/kdump should have been the only user? >>>> If older/current kexec calls still add ACPI maps via memmap=X#Y, >>>> they should already exist in the original e820 map and fall off or >>>> get glued to one region if (wrongly) overlapping via sanitize_map. >>> >>> No, kexec/kdump is not the only user for memmap=exactmap. >>> >> >> Who is using it then, since you seem to know? > > http://forums.gentoo.org/viewtopic-t-487476-highlight-proliant.html > > http://forums.fedoraforum.org/archive/index.php/t-225347.html > Hm... both of those seem to be someone trying memmap=exactmap to hack around a problem which really was elsewhere, with a different solution. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c index dc0b9f0..ae2d657 100644 --- a/arch/x86/kernel/e820.c +++ b/arch/x86/kernel/e820.c @@ -559,6 +559,19 @@ u64 __init e820_remove_range(u64 start, u64 size, unsigned old_type, return real_removed_size; } +static void __init e820_remove_range_type(u32 type) +{ + int i; + + for (i = 0; i < e820.nr_map; i++) { + struct e820entry *ei = &e820.map[i]; + if (ei->type == type) { + memset(ei, 0, sizeof(struct e820entry)); + continue; + } + } +} + void __init update_e820(void) { u32 nr_map; @@ -858,7 +871,11 @@ static int __init parse_memmap_one(char *p) */ saved_max_pfn = e820_end_of_ram_pfn(); #endif - e820.nr_map = 0; + /* + * Remove all usable memory (this is for kdump), usable + * memory will be passed via memmap=X@Y parameter + */ + e820_remove_range_type(E820_RAM); userdef = 1; return 0; }