From: Thomas Renninger <trenn@suse.de> To: Yinghai Lu <yinghai@kernel.org> Cc: "H. Peter Anvin" <hpa@zytor.com>, MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>, Takao Indoh <indou.takao@jp.fujitsu.com>, linux-pci@vger.kernel.org, x86@kernel.org, linux-kernel@vger.kernel.org, andi@firstfloor.org, tokunaga.keiich@jp.fujitsu.com, kexec@lists.infradead.org, hbabu@us.ibm.com, mingo@redhat.com, ddutile@redhat.com, vgoyal@redhat.com, ishii.hironobu@jp.fujitsu.com, bhelgaas@google.com, tglx@linutronix.de, khalid@gonehiking.org, horms@verge.net.au Subject: Re: [PATCH] x86 e820: only void usable memory areas in memmap=exactmap case Date: Mon, 14 Jan 2013 16:05:43 +0100 [thread overview] Message-ID: <201301141605.43428.trenn@suse.de> (raw) In-Reply-To: <CAE9FiQV+W21WcZuuWJYJKXhN4sf0mi=iAFgjX644c3EytPXptw@mail.gmail.com> On Monday, January 14, 2013 03:43:46 AM Yinghai Lu wrote: > On Sun, Jan 13, 2013 at 6:08 PM, Thomas Renninger <trenn@suse.de> wrote: > > On Saturday, January 12, 2013 09:07:12 AM Yinghai Lu wrote: ... > everyone could understand it straightforward: > exactmap: memmap will be specified, and it should be honored without > considering old any memmap. > exactusablemap: will make sure only old ram range get removed, and > specified usable ranges will become final usable > ranges in the final memmap. so we need to remove overlapping to old > reserved ranges. > > aka: exact means EXACT ... The naming is not my point... Anyway after a quick talk with Alexander Graf, I guess I won't have much of a chance: rule is rule and a boot param is a public interface which must not change just like that (deprecation phase, etc.). ... > those just some kind of improvement without considering kdump. > because kdump/scripts already does good job to provide right exactmap > with usable and acpi reserved areas. No it's conceptional wrong to provide the reserved areas via memmap while the original ones are declared already via boot loader structures. There are store ACPI NVS memory in suspend/resume workarounds (suspend does not fit that much for kdump, but there may be more than this and mmconf). The reserved areas in kdump kernel should be the same than with the original e820 table to avoid any unforseen issues. And kdump got them already passed and should use this info. > for mmconf, some system that range reserved in e820, and some have that in ACPI. > and those systems will have that mmconf enabled in kdumped kernel. > attached is what I like to have with exactusablemap, but maybe is not > needed, and we can just stay with exactmap... > > ps: we don't need to add e820_remove_type... I thought this tiny loop: + 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; + } + } would be easier to evaluate what it's doing (cmp to. e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);) But I do not have a strong opinion on that. What is this for?: @@ -871,6 +879,11 @@ static int __init parse_memmap_one(char userdef = 1; if (*p == '@') { start_at = memparse(p+1, &p); + if (exactusablemap_parsed) { + /* remove all range with other types */ + e820_remove_range(start_at, mem_size, + E820_RAM, 0); + } e820_add_region(start_at, mem_size, E820_RAM); } else if (*p == '#') { start_at = memparse(p+1, &p); Thomas
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Renninger <trenn@suse.de> To: Yinghai Lu <yinghai@kernel.org> Cc: horms@verge.net.au, Takao Indoh <indou.takao@jp.fujitsu.com>, MUNEDA Takahiro <muneda.takahiro@jp.fujitsu.com>, tokunaga.keiich@jp.fujitsu.com, linux-pci@vger.kernel.org, x86@kernel.org, kexec@lists.infradead.org, linux-kernel@vger.kernel.org, hbabu@us.ibm.com, andi@firstfloor.org, ddutile@redhat.com, ishii.hironobu@jp.fujitsu.com, "H. Peter Anvin" <hpa@zytor.com>, bhelgaas@google.com, tglx@linutronix.de, mingo@redhat.com, vgoyal@redhat.com, khalid@gonehiking.org Subject: Re: [PATCH] x86 e820: only void usable memory areas in memmap=exactmap case Date: Mon, 14 Jan 2013 16:05:43 +0100 [thread overview] Message-ID: <201301141605.43428.trenn@suse.de> (raw) In-Reply-To: <CAE9FiQV+W21WcZuuWJYJKXhN4sf0mi=iAFgjX644c3EytPXptw@mail.gmail.com> On Monday, January 14, 2013 03:43:46 AM Yinghai Lu wrote: > On Sun, Jan 13, 2013 at 6:08 PM, Thomas Renninger <trenn@suse.de> wrote: > > On Saturday, January 12, 2013 09:07:12 AM Yinghai Lu wrote: ... > everyone could understand it straightforward: > exactmap: memmap will be specified, and it should be honored without > considering old any memmap. > exactusablemap: will make sure only old ram range get removed, and > specified usable ranges will become final usable > ranges in the final memmap. so we need to remove overlapping to old > reserved ranges. > > aka: exact means EXACT ... The naming is not my point... Anyway after a quick talk with Alexander Graf, I guess I won't have much of a chance: rule is rule and a boot param is a public interface which must not change just like that (deprecation phase, etc.). ... > those just some kind of improvement without considering kdump. > because kdump/scripts already does good job to provide right exactmap > with usable and acpi reserved areas. No it's conceptional wrong to provide the reserved areas via memmap while the original ones are declared already via boot loader structures. There are store ACPI NVS memory in suspend/resume workarounds (suspend does not fit that much for kdump, but there may be more than this and mmconf). The reserved areas in kdump kernel should be the same than with the original e820 table to avoid any unforseen issues. And kdump got them already passed and should use this info. > for mmconf, some system that range reserved in e820, and some have that in ACPI. > and those systems will have that mmconf enabled in kdumped kernel. > attached is what I like to have with exactusablemap, but maybe is not > needed, and we can just stay with exactmap... > > ps: we don't need to add e820_remove_type... I thought this tiny loop: + 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; + } + } would be easier to evaluate what it's doing (cmp to. e820_remove_range(0, ULLONG_MAX, E820_RAM, 1);) But I do not have a strong opinion on that. What is this for?: @@ -871,6 +879,11 @@ static int __init parse_memmap_one(char userdef = 1; if (*p == '@') { start_at = memparse(p+1, &p); + if (exactusablemap_parsed) { + /* remove all range with other types */ + e820_remove_range(start_at, mem_size, + E820_RAM, 0); + } e820_add_region(start_at, mem_size, E820_RAM); } else if (*p == '#') { start_at = memparse(p+1, &p); Thomas _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
next prev parent reply other threads:[~2013-01-14 15:05 UTC|newest] Thread overview: 98+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-11-27 0:42 [PATCH v7 0/5] Reset PCIe devices to address DMA problem on kdump with iommu Takao Indoh 2012-11-27 0:42 ` Takao Indoh 2012-11-27 0:42 ` [PATCH v7 1/5] x86, pci: add dummy pci device for early stage Takao Indoh 2012-11-27 0:42 ` Takao Indoh 2012-11-27 0:42 ` [PATCH v7 2/5] PCI: Define the maximum number of PCI function Takao Indoh 2012-11-27 0:42 ` Takao Indoh 2012-11-27 0:42 ` [PATCH v7 3/5] Make reset_devices available at early stage Takao Indoh 2012-11-27 0:42 ` Takao Indoh 2012-11-27 0:43 ` [PATCH v7 4/5] x86, pci: Reset PCIe devices at boot time Takao Indoh 2012-11-27 0:43 ` Takao Indoh 2012-11-27 0:43 ` [PATCH v7 5/5] x86, pci: Enable PCI INTx when MSI is disabled Takao Indoh 2012-11-27 0:43 ` Takao Indoh 2012-11-30 15:49 ` [PATCH v7 0/5] Reset PCIe devices to address DMA problem on kdump with iommu MUNEDA Takahiro 2012-11-30 15:49 ` MUNEDA Takahiro 2012-12-21 16:19 ` Yinghai Lu 2012-12-21 16:19 ` Yinghai Lu 2013-01-07 19:09 ` Thomas Renninger 2013-01-07 19:09 ` Thomas Renninger 2013-01-07 20:16 ` Yinghai Lu 2013-01-07 20:16 ` Yinghai Lu 2013-01-08 0:42 ` Thomas Renninger 2013-01-08 0:42 ` Thomas Renninger 2013-01-08 3:04 ` Yinghai Lu 2013-01-08 3:04 ` Yinghai Lu 2013-01-08 16:47 ` [PATCH] Only reset e820 once, even with multiple memmap=exactmap params Thomas Renninger 2013-01-08 16:47 ` Thomas Renninger 2013-01-08 17:19 ` Yinghai Lu 2013-01-08 17:19 ` Yinghai Lu 2013-01-10 3:21 ` Thomas Renninger 2013-01-10 3:21 ` Thomas Renninger 2013-01-10 14:26 ` Vivek Goyal 2013-01-10 14:26 ` Vivek Goyal 2013-01-10 16:53 ` Yinghai Lu 2013-01-10 16:53 ` Yinghai Lu 2013-01-10 17:01 ` Vivek Goyal 2013-01-10 17:01 ` Vivek Goyal 2013-01-10 17:11 ` Yinghai Lu 2013-01-10 17:11 ` Yinghai Lu 2013-01-10 23:34 ` Yinghai Lu 2013-01-11 12:33 ` [PATCH] x86 e820: only void usable memory areas in memmap=exactmap case Thomas Renninger 2013-01-11 12:33 ` Thomas Renninger 2013-01-11 16:16 ` Yinghai Lu 2013-01-11 16:16 ` Yinghai Lu 2013-01-11 18:24 ` Thomas Renninger 2013-01-11 18:24 ` Thomas Renninger 2013-01-11 19:59 ` Yinghai Lu 2013-01-11 19:59 ` Yinghai Lu 2013-01-11 20:06 ` H. Peter Anvin 2013-01-11 20:06 ` H. Peter Anvin 2013-01-11 21:09 ` Yinghai Lu 2013-01-11 21:09 ` Yinghai Lu 2013-01-11 22:16 ` H. Peter Anvin 2013-01-11 22:16 ` H. Peter Anvin 2013-01-12 11:31 ` Thomas Renninger 2013-01-12 11:31 ` Thomas Renninger 2013-01-12 17:07 ` Yinghai Lu 2013-01-12 17:07 ` Yinghai Lu 2013-01-14 2:08 ` Thomas Renninger 2013-01-14 2:08 ` Thomas Renninger 2013-01-14 2:43 ` Yinghai Lu 2013-01-14 2:43 ` Yinghai Lu 2013-01-14 15:05 ` Thomas Renninger [this message] 2013-01-14 15:05 ` Thomas Renninger 2013-01-14 19:04 ` Yinghai Lu 2013-01-14 19:04 ` Yinghai Lu 2013-01-15 0:54 ` Thomas Renninger 2013-01-15 0:54 ` Thomas Renninger 2013-01-15 4:45 ` Yinghai Lu 2013-01-15 4:45 ` Yinghai Lu 2013-01-22 15:21 ` Thomas Renninger 2013-01-22 15:21 ` Thomas Renninger 2013-01-08 16:50 ` [PATCH v7 0/5] Reset PCIe devices to address DMA problem on kdump with iommu Thomas Renninger 2013-01-08 16:50 ` Thomas Renninger 2013-01-08 17:27 ` Yinghai Lu 2013-01-08 17:27 ` Yinghai Lu 2013-01-09 2:32 ` Thomas Renninger 2013-01-09 2:32 ` Thomas Renninger 2013-01-09 4:39 ` Takao Indoh 2013-01-09 4:39 ` Takao Indoh 2013-01-21 1:11 ` Takao Indoh 2013-01-21 1:11 ` Takao Indoh 2013-01-23 0:47 ` Thomas Renninger 2013-01-23 0:47 ` Thomas Renninger 2013-01-24 0:23 ` Takao Indoh 2013-01-24 0:23 ` Takao Indoh 2013-01-29 1:14 ` Thomas Renninger 2013-01-29 1:14 ` Thomas Renninger 2013-01-30 5:01 ` Takao Indoh 2013-01-30 5:01 ` Takao Indoh 2013-03-04 0:56 ` Takao Indoh 2013-03-04 0:56 ` Takao Indoh 2013-03-04 22:00 ` Don Dutile 2013-03-04 22:00 ` Don Dutile 2013-03-05 0:56 ` Takao Indoh 2013-03-05 0:56 ` Takao Indoh 2012-12-21 9:59 ` oliver yang 2012-12-21 10:37 ` Takao Indoh 2012-12-21 10:37 ` Takao Indoh
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=201301141605.43428.trenn@suse.de \ --to=trenn@suse.de \ --cc=andi@firstfloor.org \ --cc=bhelgaas@google.com \ --cc=ddutile@redhat.com \ --cc=hbabu@us.ibm.com \ --cc=horms@verge.net.au \ --cc=hpa@zytor.com \ --cc=indou.takao@jp.fujitsu.com \ --cc=ishii.hironobu@jp.fujitsu.com \ --cc=kexec@lists.infradead.org \ --cc=khalid@gonehiking.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pci@vger.kernel.org \ --cc=mingo@redhat.com \ --cc=muneda.takahiro@jp.fujitsu.com \ --cc=tglx@linutronix.de \ --cc=tokunaga.keiich@jp.fujitsu.com \ --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: linkBe 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.