Limit E820 map and /proc/iomem for mem parameter on x86-64

This patch tries to unify the behaviour of i386 and x86-64 when parsing the memory (mem/memmap) parameter of the kernel command line:

On i386, the view was limited (i.e. the actual view was presented). On x86-64, the view was full (i.e. the BIOS view was presented).

This patch moves the limit_regions() function and the print_memory_map() function to a new file e820.c, shared between the two x86 flavours. Then it adds calls to limit_regions() in 64 bit code.

I gave the patch a bit testing. However, it's not for merging, it's just to get early feedback to see if that goes into the right direction.

---
 arch/x86/kernel/Makefile   |    2 -
 arch/x86/kernel/e820.c     |   75 +++++++++++++++++++++++++++++++++++++++++++++
 arch/x86/kernel/e820_32.c  |   60 +-----------------------------------
 arch/x86/kernel/e820_64.c  |    4 ++
 arch/x86/kernel/setup_32.c |    4 +-
 include/asm-x86/e820.h     |    4 ++
 6 files changed, 88 insertions(+), 61 deletions(-)

@@ -22,7 +22,7 @@ obj-y			+= setup_$(BITS).o i8259_$(BITS)
 obj-$(CONFIG_X86_32)	+= sys_i386_32.o i386_ksyms_32.o
 obj-$(CONFIG_X86_64)	+= sys_x86_64.o x8664_ksyms_64.o
 obj-$(CONFIG_X86_64)	+= syscall_64.o vsyscall_64.o setup64.o
-obj-y			+= bootflag.o e820_$(BITS).o
+obj-y			+= bootflag.o e820_$(BITS).o e820.o
 obj-y			+= pci-dma.o quirks.o i8237.o topology.o kdebugfs.o
 obj-y			+= alternative.o i8253.o pci-nommu.o
 obj-$(CONFIG_X86_64)	+= bugs_64.o

@@ -761,9 +761,12 @@ char * __init machine_specific_memory_se
 
 static int __init parse_memopt(char *p)
 {
+	printk(KERN_INFO "parse_memopt\n");
 	if (!p)
 		return -EINVAL;
 	end_user_pfn = memparse(p, &p);
+	limit_regions(&e820, end_user_pfn);
+
 	end_user_pfn >>= PAGE_SHIFT;
 	return 0;
 }

@@ -809,6 +812,7 @@ static int __init parse_memmap_opt(char
 		start_at = memparse(p+1, &p);
 		add_memory_region(start_at, mem_size, E820_RESERVED);
 	} else {
+		limit_regions(&e820, mem_size);
 		end_user_pfn = (mem_size >> PAGE_SHIFT);
 	}
 	return *p == '\0' ? 0 : -EINVAL;

@@ -787,7 +787,7 @@ void __init setup_arch(char **cmdline_p)
 	ARCH_SETUP
 
 	printk(KERN_INFO "BIOS-provided physical RAM map:\n");
-	print_memory_map(memory_setup());
+	print_memory_map(&e820, memory_setup());
 
 	copy_edd();
 

@@ -809,7 +809,7 @@ void __init setup_arch(char **cmdline_p)
 
 	if (user_defined_memmap) {
 		printk(KERN_INFO "user-defined physical RAM map:\n");
-		print_memory_map("user");
+		print_memory_map(&e820, "user");
 	}
 
 	strlcpy(command_line, boot_command_line, COMMAND_LINE_SIZE);

@@ -20,6 +20,10 @@ struct e820map {
 	__u32 nr_map;
 	struct e820entry map[E820MAX];
 };
+
+void limit_regions(struct e820map *e820, unsigned long long size);
+void print_memory_map(struct e820map *e820, char *who);
+
 #endif /* __ASSEMBLY__ */
 
 #define ISA_START_ADDRESS	0xa0000

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

I would like to have consistent behavior of /proc/iomem across i386 and x86_64, so this sounds like right direction to me.

Also I would like to have another interface (say /proc/iomem_kernel)which actually gets modified based on the user specified options. So effectively we can have both the views. BIOS view and user defined view.

As discussed on kexec mailing list, it helps kexec and kdump operation. In the case of kexec, we want to know the actual resources present in the system so that new kernel can see it (Irrespective of the fact what first kernel was actually using).

In case of kdump, we want to see truncated view so that we don't end up capturing the contents of memory not being used by kernel.

Thanks
Vivek

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

Yes, of course, I just don't have time to work full-time on that, so be a bit patient. :)

Bernhard

Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec

can you check tip/master about that e820 merge?

http://people.redhat.com/mingo/tip.git/readme.txt

it made 32bit using e820_register_active_region...and limit_region in 32bit is remove.

YH

_______________________________________________
kexec mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/kexec