linux-kernel - Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c to fw

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4BA6EA62.1030603@kernel.org>
Date:	Sun, 21 Mar 2010 20:56:18 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
CC:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	"H. Peter Anvin" <hpa@...or.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	David Miller <davem@...emloft.net>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 06/20] early_res: seperate common memmap func from e820.c
 to fw_memmap.c

On 03/21/2010 07:37 PM, Benjamin Herrenschmidt wrote:
> On Sun, 2010-03-21 at 00:13 -0700, Yinghai Lu wrote:
>> move it to kernel/fw_memmap.c from arch/x86/kernel/e820.c
>>
>> -v2: add fw_memmap wrapper to some func...
>>      move some functions back to e820.c
> 
> NAK
at this point, kernel/early_res.c and kernel/fw_memmap.c is protected with HAVE_EARLY_RES

obj-$(CONFIG_HAVE_EARLY_RES) += early_res.o fw_memmap.o

so it will not increase size that doesn't support early_res/bootmem yet.
 
> 
> This is even worse than before. You are now moving that entire pile of
> x86 gunk into "generic" code, but even keep it names e820 there !

not all of the e820 code. arch/x86/kernel/e820.c are still there.

linux-2.6> wc -l  arch/x86/kernel/e820.c
690 arch/x86/kernel/e820.c
linux-2.6> wc -l kernel/fw_memmap.c
625 kernel/fw_memmap.c

and interface header file

yhlu@...ux-siqj:~/xx/xx/kernel/tip/linux-2.6> cat include/linux/fw_memmap.h 
#ifndef _LINUX_FW_MEMMAP_H
#define _LINUX_FW_MEMMAP_H
#define E820MAX	128		/* number of entries in E820MAP */

#define FW_MEMMAP_RAM	1
#define FW_MEMMAP_RESERVED	2

#define E820_RAM	FW_MEMMAP_RAM
#define E820_RESERVED	FW_MEMMAP_RESERVED

#define E820_ACPI	3
#define E820_NVS	4
#define E820_UNUSABLE	5

#ifndef __ASSEMBLY__
#include <linux/types.h>
struct e820entry {
	__u64 addr;	/* start of memory segment */
	__u64 size;	/* size of memory segment */
	__u32 type;	/* type of memory segment */
} __attribute__((packed));

#ifdef __KERNEL__

void fw_memmap_add_region(u64 start, u64 size, int type);
void fw_memmap_print_map(char *who);
int sanitize_fw_memmap(void);
void finish_fw_memmap_parsing(void);

#include <linux/early_res.h>

unsigned long fw_memmap_end_of_ram_pfn(void);
void fw_memmap_register_active_regions(int nid, unsigned long start_pfn,
					 unsigned long end_pfn);
u64 fw_memmap_hole_size(u64 start, u64 end);

#endif /* __KERNEL__ */
#endif /* __ASSEMBLY__ */

#endif /* _LINUX_FW_MEMMAP_H */

and new arch that support early_res/bootmem, will normally only need to call those six functions
like

+void __init setup_memory_map(void)
+{
+       int i;
+       unsigned long phys_base;
+       /* Find available physical memory...
+        *
+        * Read it twice in order to work around a bug in openfirmware.
+        * The call to grab this table itself can cause openfirmware to
+        * allocate memory, which in turn can take away some space from
+        * the list of available memory.  Reading it twice makes sure
+        * we really do get the final value.
+        */
+       read_obp_translations();
+       read_obp_memory("reg", &pall[0], &pall_ents);
+       read_obp_memory("available", &pavail[0], &pavail_ents);
+       read_obp_memory("available", &pavail[0], &pavail_ents);
+
+       phys_base = 0xffffffffffffffffUL;
+       for (i = 0; i < pavail_ents; i++) {
+               phys_base = min(phys_base, pavail[i].phys_addr);
+               fw_memmap_add_region(pavail[i].phys_addr, pavail[i].reg_size,
+                                FW_MEMMAP_RAM);
+       }
+
+       sanitize_fw_memmap();
+
+       fw_memmap_print_map("obp memmap:");


> 
> What happened to the discussion we had earlier, which iirc concluded
> that a better approach would be to adapt x86 to use LMB ?

e820/early_res is more complicated than lmb. to make x86, we still need to keep e820 related code.
and early_res already can be used to replace bootmem code.

maybe we should find other user other than previous lmb users at first.

attached is the one for sparc64/lmb converting...- i have no chance to debug it.
qemu seems doesn't support sparc64 well yet.


Yinghai

View attachment "e820_static_4.patch" of type "text/x-patch" (19607 bytes)