This patch (as request for comments) introduces a new userspace interface
/proc/firmware_mem that provides the unfiltered view of the BIOS on
memory configuration. That's usable for two reasons:
1) Debugging (yes, the E820 memory is printed in kernel ring buffer, but that's
not the case for all platforms, on IA64 you have to enable some magic define
to print the EFI memory map, for example),
2) Kexec. When the user or the system uses a special command line to modify the
memory configuration, kexec still needs a method to get the original memory
map. While the filtered view is useful for generating ELF core headers for
crashdumps, the unfiltered view is necessary to boot the next kernel without
the "limitations" the original kernel has.
We had the discussion to add iomem_used on kexec mailing list. However, I think
it's better to let /proc/iomem represent the *filtered* (i.e. "used") view of
the I/O resources and introduce a new interface for the *unfiltered* view.
There are two reasons:
1) On i386 (the oldest architectures), /proc/iomem always represented the
*filtered* view (i.e. "mem" parameter was also visible in /proc/iomem).
I think we should not change the semantics of an interface without a reason.
2) /proc/iomem_used would it make necessary to duplicate all registration between
/proc/iomem and /proc/iomem_used. Because currently the resource root
is exported and used everywhere in the kernel source, that would make
changes of the whole resource infrastructure necessary if code duplication
should be avoided.
Maybe you think that /proc/firmware_mem is not the right place to export that.
I don't know, I also don't care that much about the naming or the way to export
that. So, please advise me if you agree that it's ok for kexec to export an
unfiltered view of the memory map.
The patch has been tested on i386 and x86_64.
Signed-off-by: Bernhard Walle <[email protected]>
This patch brings back limiting of the E820 map when a user-defined
E820 map is specified. While the behaviour of i386 (32 bit) was to limit
the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
limit.
That patch limits the E820 map again for both x86 architectures.
Code was tested for compilation and booting on a 32 bit and 64 bit system.
Signed-off-by: Bernhard Walle <[email protected]>
---
arch/x86/kernel/e820.c | 30 ++++++++++++++++++++++++++++++
1 files changed, 30 insertions(+), 0 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index f5b1736..2e7d385 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -934,6 +934,33 @@ static void early_panic(char *msg)
panic(msg);
}
+void __init e820_limit_regions(unsigned long long size)
+{
+ unsigned long long current_addr;
+ int i;
+
+ for (i = 0; i < e820.nr_map; i++) {
+ current_addr = e820.map[i].addr + e820.map[i].size;
+ if (current_addr < size)
+ continue;
+
+ if (e820.map[i].type != E820_RAM)
+ continue;
+
+ if (e820.map[i].addr >= size) {
+ /*
+ * This region starts past the end of the
+ * requested size, skip it completely.
+ */
+ e820.nr_map = i;
+ } else {
+ e820.nr_map = i + 1;
+ e820.map[i].size -= current_addr - size;
+ }
+ return;
+ }
+}
+
/* "mem=nopentium" disables the 4MB page tables. */
static int __init parse_memopt(char *p)
{
@@ -951,6 +978,8 @@ static int __init parse_memopt(char *p)
mem_size = memparse(p, &p);
end_user_pfn = mem_size>>PAGE_SHIFT;
+ e820_limit_regions(mem_size);
+
return 0;
}
early_param("mem", parse_memopt);
@@ -995,6 +1024,7 @@ static int __init parse_memmap_opt(char *p)
e820_add_region(start_at, mem_size, E820_RESERVED);
} else {
end_user_pfn = (mem_size >> PAGE_SHIFT);
+ e820_limit_regions(mem_size);
}
return *p == '\0' ? 0 : -EINVAL;
}
--
1.5.4.5
/proc/iomem contains mostly the view of the system about the memory resources.
However, when using kexec, it's necessary to get also the firmware view, i.e.
the original memory map the kernel got passed before applying command line
options like exactmap or mem=<value>. kexec needs both views:
a) When another kernel is booted, then the firmware view is needed. If you
boot your original kernel with mem=3G, then you don't necessarily expect
thew kexec'd kernel also to have a limited amount of memory.
b) When the ELF core headers for kernel dumps are generated, kexec needs the
kernel view about memory resources because it doesn't make sense to dump
memory that never has been used.
The patch only creates the interface and the resource tree. It has to be filled
by architecture code.
Signed-off-by: Bernhard Walle <[email protected]>
---
include/linux/ioport.h | 1 +
kernel/resource.c | 39 +++++++++++++++++++++++++++++++--------
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index c6801bf..4af561a 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -100,6 +100,7 @@ struct resource_list {
/* PC/ISA/whatever - the normal PC address spaces: IO and memory */
extern struct resource ioport_resource;
extern struct resource iomem_resource;
+extern struct resource firmware_mem_resource;
extern int request_resource(struct resource *root, struct resource *new);
extern int release_resource(struct resource *new);
diff --git a/kernel/resource.c b/kernel/resource.c
index 74af2d7..dee58a7 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -36,6 +36,15 @@ struct resource iomem_resource = {
};
EXPORT_SYMBOL(iomem_resource);
+struct resource firmware_mem_resource = {
+ .name = "Firmware memory map",
+ .start = 0,
+ .end = -1,
+ .flags = IORESOURCE_MEM,
+};
+EXPORT_SYMBOL(firmware_mem_resource);
+
+
static DEFINE_RWLOCK(resource_lock);
#ifdef CONFIG_PROC_FS
@@ -95,24 +104,30 @@ static const struct seq_operations resource_op = {
.show = r_show,
};
-static int ioports_open(struct inode *inode, struct file *file)
+static int resource_open(struct inode *inode, struct file *file,
+ struct resource *resource)
{
int res = seq_open(file, &resource_op);
if (!res) {
struct seq_file *m = file->private_data;
- m->private = &ioport_resource;
+ m->private = resource;
}
return res;
}
+static int ioports_open(struct inode *inode, struct file *file)
+{
+ return resource_open(inode, file, &ioport_resource);
+}
+
static int iomem_open(struct inode *inode, struct file *file)
{
- int res = seq_open(file, &resource_op);
- if (!res) {
- struct seq_file *m = file->private_data;
- m->private = &iomem_resource;
- }
- return res;
+ return resource_open(inode, file, &iomem_resource);
+}
+
+static int firmware_mem_open(struct inode *inode, struct file *file)
+{
+ return resource_open(inode, file, &firmware_mem_resource);
}
static const struct file_operations proc_ioports_operations = {
@@ -129,10 +144,18 @@ static const struct file_operations proc_iomem_operations = {
.release = seq_release,
};
+static const struct file_operations proc_firmware_mem_operations = {
+ .open = firmware_mem_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
static int __init ioresources_init(void)
{
proc_create("ioports", 0, NULL, &proc_ioports_operations);
proc_create("iomem", 0, NULL, &proc_iomem_operations);
+ proc_create("firmware_mem", 0, NULL, &proc_firmware_mem_operations);
return 0;
}
__initcall(ioresources_init);
--
1.5.4.5
This patch copies the E820 map very early, before the kernel applies various
operations. That copy is used later to register only the BIOS-provided E820
map later in the resource tree for /proc/firmware_mem.
Signed-off-by: Bernhard Walle <[email protected]>
---
arch/x86/kernel/e820.c | 44 ++++++++++++++++++++++++++++++++++----------
include/asm-x86/e820.h | 2 ++
2 files changed, 36 insertions(+), 10 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7b613d2..f5b1736 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -27,7 +27,22 @@
#include <asm/setup.h>
#include <asm/trampoline.h>
+/*
+ * The e820 map is the map that gets modified e.g. with command line parameters
+ * and that is also registered with modifications in the kernel resource tree
+ * with the iomem_resource as parent.
+ *
+ * The e820_saved is directly saved after the BIOS-provided memory map is
+ * copied. It doesn't get modified afterwards. It's registered in the
+ * resource system of the kernel with firmware_mem_resource as parent.
+ *
+ * That memory map is not modified and is used as base for kexec. The kexec'd
+ * kernel should get the same memory map as the firmware provides. Then the
+ * user can e.g. boot the original kernel with mem=1G while still booting the
+ * next kernel with full memory.
+ */
struct e820map e820;
+struct e820map e820_saved;
/* For PCI or other memory-mapped resources */
unsigned long pci_mem_start = 0xaeedbabe;
@@ -999,24 +1014,22 @@ void __init finish_e820_parsing(void)
}
}
-/*
- * Mark e820 reserved areas as busy for the resource manager.
- */
-void __init e820_reserve_resources(void)
+static void __init e820_reserve_resources_map(struct e820map *map,
+ struct resource *root)
{
int i;
struct resource *res;
- res = alloc_bootmem_low(sizeof(struct resource) * e820.nr_map);
- for (i = 0; i < e820.nr_map; i++) {
- switch (e820.map[i].type) {
+ res = alloc_bootmem_low(sizeof(struct resource) * map->nr_map);
+ for (i = 0; i < map->nr_map; i++) {
+ switch (map->map[i].type) {
case E820_RAM: res->name = "System RAM"; break;
case E820_ACPI: res->name = "ACPI Tables"; break;
case E820_NVS: res->name = "ACPI Non-volatile Storage"; break;
default: res->name = "reserved";
}
- res->start = e820.map[i].addr;
- res->end = res->start + e820.map[i].size - 1;
+ res->start = map->map[i].addr;
+ res->end = res->start + map->map[i].size - 1;
#ifndef CONFIG_RESOURCES_64BIT
if (res->end > 0x100000000ULL) {
res++;
@@ -1024,11 +1037,20 @@ void __init e820_reserve_resources(void)
}
#endif
res->flags = IORESOURCE_MEM | IORESOURCE_BUSY;
- insert_resource(&iomem_resource, res);
+ insert_resource(root, res);
res++;
}
}
+/*
+ * Mark e820 reserved areas as busy for the resource manager.
+ */
+void __init e820_reserve_resources(void)
+{
+ e820_reserve_resources_map(&e820, &iomem_resource);
+ e820_reserve_resources_map(&e820_saved, &firmware_mem_resource);
+}
+
char *__init default_machine_specific_memory_setup(void)
{
char *who = "BIOS-e820";
@@ -1062,6 +1084,8 @@ char *__init default_machine_specific_memory_setup(void)
e820_add_region(HIGH_MEMORY, mem_size << 10, E820_RAM);
}
+ memcpy(&e820_saved, &e820, sizeof(struct e820map));
+
/* In case someone cares... */
return who;
}
diff --git a/include/asm-x86/e820.h b/include/asm-x86/e820.h
index 668a0d7..48e7181 100644
--- a/include/asm-x86/e820.h
+++ b/include/asm-x86/e820.h
@@ -56,7 +56,9 @@ struct e820map {
struct e820entry map[E820_X_MAX];
};
+/* see comment in arch/x86/kernel/e820.c */
extern struct e820map e820;
+extern struct e820map e820_saved;
extern int e820_any_mapped(u64 start, u64 end, unsigned type);
extern int e820_all_mapped(u64 start, u64 end, unsigned type);
--
1.5.4.5
* Bernhard Walle [2008-06-20 17:56]:
>
> The patch has been tested on i386 and x86_64.
Forgot to mention that the patch is against linux-2.6/tip/master.
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
On Fri, Jun 20, 2008 at 05:56:57PM +0200, Bernhard Walle wrote:
> This patch (as request for comments) introduces a new userspace interface
> /proc/firmware_mem that provides the unfiltered view of the BIOS on
> memory configuration. That's usable for two reasons:
>
How about /proc/firmware_memmap. This is little longish but probably more
clear in intent.
Thanks
Vivek
On Fri, Jun 20, 2008 at 05:57:00PM +0200, Bernhard Walle wrote:
> This patch brings back limiting of the E820 map when a user-defined
> E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> limit.
>
> That patch limits the E820 map again for both x86 architectures.
>
> Code was tested for compilation and booting on a 32 bit and 64 bit system.
>
>
> Signed-off-by: Bernhard Walle <[email protected]>
> ---
> arch/x86/kernel/e820.c | 30 ++++++++++++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index f5b1736..2e7d385 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -934,6 +934,33 @@ static void early_panic(char *msg)
> panic(msg);
> }
>
> +void __init e820_limit_regions(unsigned long long size)
> +{
> + unsigned long long current_addr;
> + int i;
> +
> + for (i = 0; i < e820.nr_map; i++) {
> + current_addr = e820.map[i].addr + e820.map[i].size;
> + if (current_addr < size)
> + continue;
> +
> + if (e820.map[i].type != E820_RAM)
> + continue;
> +
> + if (e820.map[i].addr >= size) {
> + /*
> + * This region starts past the end of the
> + * requested size, skip it completely.
> + */
> + e820.nr_map = i;
> + } else {
> + e820.nr_map = i + 1;
> + e820.map[i].size -= current_addr - size;
> + }
> + return;
> + }
> +}
> +
> /* "mem=nopentium" disables the 4MB page tables. */
> static int __init parse_memopt(char *p)
> {
> @@ -951,6 +978,8 @@ static int __init parse_memopt(char *p)
>
> mem_size = memparse(p, &p);
> end_user_pfn = mem_size>>PAGE_SHIFT;
> + e820_limit_regions(mem_size);
> +
> return 0;
> }
> early_param("mem", parse_memopt);
> @@ -995,6 +1024,7 @@ static int __init parse_memmap_opt(char *p)
> e820_add_region(start_at, mem_size, E820_RESERVED);
> } else {
> end_user_pfn = (mem_size >> PAGE_SHIFT);
> + e820_limit_regions(mem_size);
> }
Hi Bernhard,
Just curious, when do we hit this bottom else condition?
In Documentation/kernel-parameters.txt file, I see, there are four
types of memmap= options. "exactmap" "@" "#" and "$". In the code
above we have already parsed all these option. So default condition
should be an error. Instead we seem to be limiting the memory size,
(something done by mem= parameter)..
Thanks
Vivek
On Fri, Jun 20, 2008 at 8:57 AM, Bernhard Walle <[email protected]> wrote:
> This patch brings back limiting of the E820 map when a user-defined
> E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> limit.
then if you kexec new kernel, the second kernel will be have that
limitation too.
any problem that you encountered without this patch?
YH
>
> That patch limits the E820 map again for both x86 architectures.
>
> Code was tested for compilation and booting on a 32 bit and 64 bit system.
>
>
> Signed-off-by: Bernhard Walle <[email protected]>
> ---
> arch/x86/kernel/e820.c | 30 ++++++++++++++++++++++++++++++
> 1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index f5b1736..2e7d385 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -934,6 +934,33 @@ static void early_panic(char *msg)
> panic(msg);
> }
>
> +void __init e820_limit_regions(unsigned long long size)
> +{
> + unsigned long long current_addr;
> + int i;
> +
> + for (i = 0; i < e820.nr_map; i++) {
> + current_addr = e820.map[i].addr + e820.map[i].size;
> + if (current_addr < size)
> + continue;
> +
> + if (e820.map[i].type != E820_RAM)
> + continue;
> +
> + if (e820.map[i].addr >= size) {
> + /*
> + * This region starts past the end of the
> + * requested size, skip it completely.
> + */
> + e820.nr_map = i;
> + } else {
> + e820.nr_map = i + 1;
> + e820.map[i].size -= current_addr - size;
> + }
> + return;
> + }
> +}
> +
> /* "mem=nopentium" disables the 4MB page tables. */
> static int __init parse_memopt(char *p)
> {
> @@ -951,6 +978,8 @@ static int __init parse_memopt(char *p)
>
> mem_size = memparse(p, &p);
> end_user_pfn = mem_size>>PAGE_SHIFT;
> + e820_limit_regions(mem_size);
> +
> return 0;
> }
> early_param("mem", parse_memopt);
> @@ -995,6 +1024,7 @@ static int __init parse_memmap_opt(char *p)
> e820_add_region(start_at, mem_size, E820_RESERVED);
> } else {
> end_user_pfn = (mem_size >> PAGE_SHIFT);
> + e820_limit_regions(mem_size);
> }
> return *p == '\0' ? 0 : -EINVAL;
> }
> --
> 1.5.4.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Vivek Goyal wrote:
> On Fri, Jun 20, 2008 at 05:56:57PM +0200, Bernhard Walle wrote:
>> This patch (as request for comments) introduces a new userspace interface
>> /proc/firmware_mem that provides the unfiltered view of the BIOS on
>> memory configuration. That's usable for two reasons:
>
> How about /proc/firmware_memmap. This is little longish but probably more
> clear in intent.
Perhaps even /proc/firmware/memmap (or /sys/firmware/memmap/...). I
realize introducing a new directory is annoying, but it's a namespace
that is likely to have other users.
-hpa
* "Yinghai Lu" <[email protected]> [2008-06-20 13:34]:
>
> On Fri, Jun 20, 2008 at 8:57 AM, Bernhard Walle <[email protected]> wrote:
> > This patch brings back limiting of the E820 map when a user-defined
> > E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> > the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> > limit.
>
> then if you kexec new kernel, the second kernel will be have that
> limitation too.
>
> any problem that you encountered without this patch?
No, because the new kexec tool uses the /proc/firmware_mem or whatever
it is called.
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
* "Yinghai Lu" <[email protected]> [2008-06-20 13:34]:
>
> any problem that you encountered without this patch?
Sorry, forgot to answer that question.
Yes, if you use mem=3G and take a dump, kexec builds the ELF core
headers for the full memory size, which means that the dump is as large
as the physical memory of the machine is, which doesn't make sense.
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
Hi,
* "H. Peter Anvin" <[email protected]> [2008-06-20 13:35]:
>
> Vivek Goyal wrote:
> > On Fri, Jun 20, 2008 at 05:56:57PM +0200, Bernhard Walle wrote:
> >> This patch (as request for comments) introduces a new userspace interface
> >> /proc/firmware_mem that provides the unfiltered view of the BIOS on
> >> memory configuration. That's usable for two reasons:
> >
> > How about /proc/firmware_memmap. This is little longish but probably more
> > clear in intent.
>
> Perhaps even /proc/firmware/memmap (or /sys/firmware/memmap/...). I
> realize introducing a new directory is annoying, but it's a namespace
> that is likely to have other users.
Since /sys/firmware is already used by ACPI and EDD, I think that's
quite a good idea! Maybe we should also export the raw E820 or EFI
memory map there. Just like EDD.
I'll send a new patch.
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
On Sun, Jun 22, 2008 at 12:56 PM, Bernhard Walle <[email protected]> wrote:
> * "Yinghai Lu" <[email protected]> [2008-06-20 13:34]:
>>
>> any problem that you encountered without this patch?
>
> Sorry, forgot to answer that question.
>
> Yes, if you use mem=3G and take a dump, kexec builds the ELF core
> headers for the full memory size, which means that the dump is as large
> as the physical memory of the machine is, which doesn't make sense.
can we use e820_update_range instead? so e820_setup_gap still can get
correct value?
YH
* Yinghai Lu [2008-06-22 13:11]:
>
> On Sun, Jun 22, 2008 at 12:56 PM, Bernhard Walle <[email protected]> wrote:
> > * "Yinghai Lu" <[email protected]> [2008-06-20 13:34]:
> >>
> >> any problem that you encountered without this patch?
> >
> > Sorry, forgot to answer that question.
> >
> > Yes, if you use mem=3G and take a dump, kexec builds the ELF core
> > headers for the full memory size, which means that the dump is as large
> > as the physical memory of the machine is, which doesn't make sense.
>
> can we use e820_update_range instead? so e820_setup_gap still can get
> correct value?
Yes, good idea. Patch is in the queue ...
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development
Hi!
> This patch copies the E820 map very early, before the kernel applies various
> operations. That copy is used later to register only the BIOS-provided E820
> map later in the resource tree for /proc/firmware_mem.
It is not process related -> it should not go to /proc. Talk to Greg.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
* Pavel Machek [2008-06-24 20:28]:
>
> > This patch copies the E820 map very early, before the kernel applies various
> > operations. That copy is used later to register only the BIOS-provided E820
> > map later in the resource tree for /proc/firmware_mem.
>
> It is not process related -> it should not go to /proc. Talk to Greg.
http://lkml.org/lkml/2008/6/26/75
Bernhard
--
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development