x86, boot, 64bit: Add support for loading ramdisk and bzImage above 4G

PATCH In review Yinghai Lu 12 participants 199 messages Jan 4, 2013 – Jan 31, 2013 Page 2 of 2

Subsystems (13)

Memory management Documentation x86 Library code +9 more subsystems

lore

Share & tools

lore

Yinghai Lu

author

2013-01-04 00:51 UTC #178 lore raw

PATCH 30/31 x86, 64bit, mm: Mark data/bss/brk to nx

In reply to Yinghai Lu

HPA said, we should not have RW and +x set at the time.

for kernel layout:

[    0.000000] Kernel Layout:
[    0.000000]   .text: [0x01000000-0x021434f8]
[    0.000000] .rodata: [0x02200000-0x02a13fff]
[    0.000000]   .data: [0x02c00000-0x02dc763f]
[    0.000000]   .init: [0x02dc9000-0x0312cfff]
[    0.000000]    .bss: [0x0313b000-0x03dd6fff]
[    0.000000]    .brk: [0x03dd7000-0x03dfffff]

before the patch, we have
---[ High Kernel Mapping ]---

0xffffffff80000000-0xffffffff81000000          16M                           pmd
0xffffffff81000000-0xffffffff82200000          18M     ro         PSE GLB x  pmd
0xffffffff82200000-0xffffffff82c00000          10M     ro         PSE GLB NX pmd
0xffffffff82c00000-0xffffffff82dc9000        1828K     RW             GLB x  pte
0xffffffff82dc9000-0xffffffff82e00000         220K     RW             GLB NX pte
0xffffffff82e00000-0xffffffff83000000           2M     RW         PSE GLB NX pmd
0xffffffff83000000-0xffffffff8313a000        1256K     RW             GLB NX pte
0xffffffff8313a000-0xffffffff83200000         792K     RW             GLB x  pte
0xffffffff83200000-0xffffffff83e00000          12M     RW         PSE GLB x  pmd

0xffffffff83e00000-0xffffffffa0000000 450M pmd

after patch,, we get
---[ High Kernel Mapping ]---

0xffffffff80000000-0xffffffff81000000          16M                           pmd
0xffffffff81000000-0xffffffff82200000          18M     ro         PSE GLB x  pmd
0xffffffff82200000-0xffffffff82c00000          10M     ro         PSE GLB NX pmd
0xffffffff82c00000-0xffffffff82e00000           2M     RW             GLB NX pte
0xffffffff82e00000-0xffffffff83000000           2M     RW         PSE GLB NX pmd
0xffffffff83000000-0xffffffff83200000           2M     RW             GLB NX pte
0xffffffff83200000-0xffffffff83e00000          12M     RW         PSE GLB NX pmd

0xffffffff83e00000-0xffffffffa0000000 450M pmd

so data, bss, brk get NX ...

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/mm/init_64.c |    7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

arch/x86/mm/init_64.c +4 -3

index 98385a2..9653411 100644
@@ -820,6 +820,7 @@ void mark_rodata_ro(void)
 	unsigned long end = (unsigned long) &__end_rodata_hpage_align;
 	unsigned long text_end = PFN_ALIGN(&__stop___ex_table);
 	unsigned long rodata_end = PFN_ALIGN(&__end_rodata);
+	unsigned long all_end = PFN_ALIGN(&_end);
 
 	printk(KERN_INFO "Write protecting the kernel read-only data: %luk\n",
 	       (end - start) >> 10);

@@ -828,10 +829,10 @@ void mark_rodata_ro(void)
 	kernel_set_to_readonly = 1;
 
 	/*
-	 * The rodata section (but not the kernel text!) should also be
-	 * not-executable.
+	 * The rodata/data/bss/brk section (but not the kernel text!)
+	 * should also be not-executable.
 	 */
-	set_memory_nx(rodata_start, (end - rodata_start) >> PAGE_SHIFT);
+	set_memory_nx(rodata_start, (all_end - rodata_start) >> PAGE_SHIFT);
 
 	rodata_test();

Signature · 1 line

1.7.10.4

Yinghai Lu

author

2013-01-04 00:48 UTC #179 lore raw

PATCH 31/31 x86, 64bit, mm: hibernate use generic mapping_init

In reply to Yinghai Lu

Make it only map range in pfn_mapped array.

and it has kernel mapping with EXEC.

Signed-off-by Yinghai Lu <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Rafael J. Wysocki <[email protected]>

Cc [email protected]

---
 arch/x86/power/hibernate_64.c |   66 ++++++++++++++---------------------------
 1 file changed, 22 insertions(+), 44 deletions(-)

arch/x86/power/hibernate_64.c +22 ~~-44~~

index 460f314..a0fde91 100644
@@ -11,6 +11,8 @@
 #include <linux/gfp.h>
 #include <linux/smp.h>
 #include <linux/suspend.h>
+
+#include <asm/init.h>
 #include <asm/proto.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>

@@ -39,41 +41,21 @@ pgd_t *temp_level4_pgt;
 
 void *relocated_restore_code;
 
-static int res_phys_pud_init(pud_t *pud, unsigned long address, unsigned long end)
+static void *alloc_pgt_page(void *context)
 {
-	long i, j;
-
-	i = pud_index(address);
-	pud = pud + i;
-	for (; i < PTRS_PER_PUD; pud++, i++) {
-		unsigned long paddr;
-		pmd_t *pmd;
-
-		paddr = address + i*PUD_SIZE;
-		if (paddr >= end)
-			break;
-
-		pmd = (pmd_t *)get_safe_page(GFP_ATOMIC);
-		if (!pmd)
-			return -ENOMEM;
-		set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
-		for (j = 0; j < PTRS_PER_PMD; pmd++, j++, paddr += PMD_SIZE) {
-			unsigned long pe;
-
-			if (paddr >= end)
-				break;
-			pe = __PAGE_KERNEL_LARGE_EXEC | paddr;
-			pe &= __supported_pte_mask;
-			set_pmd(pmd, __pmd(pe));
-		}
-	}
-	return 0;
+	return (void *)get_safe_page(GFP_ATOMIC);
 }
 
 static int set_up_temporary_mappings(void)
 {
-	unsigned long start, end, next;
-	int error;
+	struct x86_mapping_info info = {
+		.alloc_pgt_page	= alloc_pgt_page,
+		.pmd_flag	= __PAGE_KERNEL_LARGE_EXEC,
+		.kernel_mapping = true,
+	};
+	unsigned long mstart, mend;
+	int result;
+	int i;
 
 	temp_level4_pgt = (pgd_t *)get_safe_page(GFP_ATOMIC);
 	if (!temp_level4_pgt)

@@ -84,21 +66,17 @@ static int set_up_temporary_mappings(void)
 		init_level4_pgt[pgd_index(__START_KERNEL_map)]);
 
 	/* Set up the direct mapping from scratch */
-	start = (unsigned long)pfn_to_kaddr(0);
-	end = (unsigned long)pfn_to_kaddr(max_pfn);
-
-	for (; start < end; start = next) {
-		pud_t *pud = (pud_t *)get_safe_page(GFP_ATOMIC);
-		if (!pud)
-			return -ENOMEM;
-		next = start + PGDIR_SIZE;
-		if (next > end)
-			next = end;
-		if ((error = res_phys_pud_init(pud, __pa(start), __pa(next))))
-			return error;
-		set_pgd(temp_level4_pgt + pgd_index(start),
-			mk_kernel_pgd(__pa(pud)));
+	for (i = 0; i < nr_pfn_mapped; i++) {
+		mstart = pfn_mapped[i].start << PAGE_SHIFT;
+		mend   = pfn_mapped[i].end << PAGE_SHIFT;
+
+		result = kernel_ident_mapping_init(&info, temp_level4_pgt,
+						   mstart, mend);
+
+		if (result)
+			return result;
 	}
+
 	return 0;
 }

Signature · 1 line

1.7.10.4

Rafael J. Wysocki

2013-01-04 11:38 UTC #180 lore raw

Re: [PATCH v7u1 31/31] x86, 64bit, mm: hibernate use generic mapping_init

Quoted 1 line · Yinghai Lu

Make it only map range in pfn_mapped array.

Can you please explain why that should be sufficient?

Have you tested it?

Quoted 1 line

and it has kernel mapping with EXEC.

That's because it needs to execute code from one of those pages and it doesn't know in advance which one that's going to be.

Thanks,
Rafael

Quoted 106 lines

Signed-off-by Yinghai Lu <[email protected]>

Cc Pavel Machek <[email protected]>

Cc Rafael J. Wysocki <[email protected]>

Cc [email protected]

---
 arch/x86/power/hibernate_64.c |   66 ++++++++++++++---------------------------
 1 file changed, 22 insertions(+), 44 deletions(-)

arch/x86/power/hibernate_64.c +22 ~~-44~~

index 460f314..a0fde91 100644
@@ -11,6 +11,8 @@
 #include <linux/gfp.h>
 #include <linux/smp.h>
 #include <linux/suspend.h>
+
+#include <asm/init.h>
 #include <asm/proto.h>
 #include <asm/page.h>
 #include <asm/pgtable.h>

@@ -39,41 +41,21 @@ pgd_t *temp_level4_pgt;
 
 void *relocated_restore_code;
 
-static int res_phys_pud_init(pud_t *pud, unsigned long address, unsigned long end)
+static void *alloc_pgt_page(void *context)
 {
-	long i, j;
-
-	i = pud_index(address);
-	pud = pud + i;
-	for (; i < PTRS_PER_PUD; pud++, i++) {
-		unsigned long paddr;
-		pmd_t *pmd;
-
-		paddr = address + i*PUD_SIZE;
-		if (paddr >= end)
-			break;
-
-		pmd = (pmd_t *)get_safe_page(GFP_ATOMIC);
-		if (!pmd)
-			return -ENOMEM;
-		set_pud(pud, __pud(__pa(pmd) | _KERNPG_TABLE));
-		for (j = 0; j < PTRS_PER_PMD; pmd++, j++, paddr += PMD_SIZE) {
-			unsigned long pe;
-
-			if (paddr >= end)
-				break;
-			pe = __PAGE_KERNEL_LARGE_EXEC | paddr;
-			pe &= __supported_pte_mask;
-			set_pmd(pmd, __pmd(pe));
-		}
-	}
-	return 0;
+	return (void *)get_safe_page(GFP_ATOMIC);
 }
 
 static int set_up_temporary_mappings(void)
 {
-	unsigned long start, end, next;
-	int error;
+	struct x86_mapping_info info = {
+		.alloc_pgt_page	= alloc_pgt_page,
+		.pmd_flag	= __PAGE_KERNEL_LARGE_EXEC,
+		.kernel_mapping = true,
+	};
+	unsigned long mstart, mend;
+	int result;
+	int i;
 
 	temp_level4_pgt = (pgd_t *)get_safe_page(GFP_ATOMIC);
 	if (!temp_level4_pgt)

@@ -84,21 +66,17 @@ static int set_up_temporary_mappings(void)
 		init_level4_pgt[pgd_index(__START_KERNEL_map)]);
 
 	/* Set up the direct mapping from scratch */
-	start = (unsigned long)pfn_to_kaddr(0);
-	end = (unsigned long)pfn_to_kaddr(max_pfn);
-
-	for (; start < end; start = next) {
-		pud_t *pud = (pud_t *)get_safe_page(GFP_ATOMIC);
-		if (!pud)
-			return -ENOMEM;
-		next = start + PGDIR_SIZE;
-		if (next > end)
-			next = end;
-		if ((error = res_phys_pud_init(pud, __pa(start), __pa(next))))
-			return error;
-		set_pgd(temp_level4_pgt + pgd_index(start),
-			mk_kernel_pgd(__pa(pud)));
+	for (i = 0; i < nr_pfn_mapped; i++) {
+		mstart = pfn_mapped[i].start << PAGE_SHIFT;
+		mend   = pfn_mapped[i].end << PAGE_SHIFT;
+
+		result = kernel_ident_mapping_init(&info, temp_level4_pgt,
+						   mstart, mend);
+
+		if (result)
+			return result;
 	}
+
 	return 0;
 }

Signature · 2 lines

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Yinghai Lu

author

2013-01-04 21:59 UTC #181 lore raw

Re: [PATCH v7u1 31/31] x86, 64bit, mm: hibernate use generic mapping_init

Quoted 4 lines · Rafael J. Wysocki

Quoted 1 line · Yinghai Lu
Make it only map range in pfn_mapped array.
Can you please explain why that should be sufficient?

It is needed.

http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=66520ebc2df3fe52eb4792f8101fac573b766baf

Subject: [PATCH] x86, mm: Only direct map addresses that are marked as
E820_RAM

Currently direct mappings are created for [ 0 to max_low_pfn<<PAGE_SHIFT ) and [ 4GB to max_pfn<<PAGE_SHIFT ), which may include regions that are not backed by actual DRAM. This is fine for holes under 4GB which are covered by fixed and variable range MTRRs to be UC. However, we run into trouble on higher memory addresses which cannot be covered by MTRRs.

Our system with 1TB of RAM has an e820 that looks like this:

BIOS-e820: [mem 0x0000000000000000-0x00000000000983ff] usable
BIOS-e820: [mem 0x0000000000098400-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000d0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x00000000c7ebffff] usable
BIOS-e820: [mem 0x00000000c7ec0000-0x00000000c7ed7fff] ACPI data
BIOS-e820: [mem 0x00000000c7ed8000-0x00000000c7ed9fff] ACPI NVS
BIOS-e820: [mem 0x00000000c7eda000-0x00000000c7ffffff] reserved
BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000e037ffffff] usable
BIOS-e820: [mem 0x000000e038000000-0x000000fcffffffff] reserved
BIOS-e820: [mem 0x0000010000000000-0x0000011ffeffffff] usable

and so direct mappings are created for huge memory hole between 0x000000e038000000 to 0x0000010000000000. Even though the kernel never generates memory accesses in that region, since the page tables mark them incorrectly as being WB, our (AMD) processor ends up causing a MCE while doing some memory bookkeeping/optimizations around that area.

This patch iterates through e820 and only direct maps ranges that are marked as E820_RAM, and keeps track of those pfn ranges. Depending on the alignment of E820 ranges, this may possibly result in using smaller size (i.e. 4K instead of 2M or 1G) page tables.

Quoted 3 lines

Have you tested it?

will update to

Subject: [PATCH] x86, 64bit, mm: hibernate use generic mapping_init

We should not set mapping for all under max_pfn.
That causes same problem that is fixed by
x86, mm: Only direct map addresses that are marked as E820_RAM

Make it only map range in pfn_mapped array.

Rafael J. Wysocki

2013-01-04 22:02 UTC #182 lore raw

Re: [PATCH v7u1 31/31] x86, 64bit, mm: hibernate use generic mapping_init

Quoted 54 lines · Yinghai Lu

Quoted 4 lines · Rafael J. Wysocki
Quoted 1 line · Yinghai Lu
Make it only map range in pfn_mapped array.
Can you please explain why that should be sufficient?
It is needed.
http://git.kernel.org/?p=linux/kernel/git/tip/tip.git;a=commitdiff;h=66520ebc2df3fe52eb4792f8101fac573b766baf
Subject: [PATCH] x86, mm: Only direct map addresses that are marked as
E820_RAM
Currently direct mappings are created for [ 0 to max_low_pfn<<PAGE_SHIFT ) and [ 4GB to max_pfn<<PAGE_SHIFT ), which may include regions that are not backed by actual DRAM. This is fine for holes under 4GB which are covered by fixed and variable range MTRRs to be UC. However, we run into trouble on higher memory addresses which cannot be covered by MTRRs.
Our system with 1TB of RAM has an e820 that looks like this:
BIOS-e820: [mem 0x0000000000000000-0x00000000000983ff] usable
BIOS-e820: [mem 0x0000000000098400-0x000000000009ffff] reserved
BIOS-e820: [mem 0x00000000000d0000-0x00000000000fffff] reserved
BIOS-e820: [mem 0x0000000000100000-0x00000000c7ebffff] usable
BIOS-e820: [mem 0x00000000c7ec0000-0x00000000c7ed7fff] ACPI data
BIOS-e820: [mem 0x00000000c7ed8000-0x00000000c7ed9fff] ACPI NVS
BIOS-e820: [mem 0x00000000c7eda000-0x00000000c7ffffff] reserved
BIOS-e820: [mem 0x00000000fec00000-0x00000000fec0ffff] reserved
BIOS-e820: [mem 0x00000000fee00000-0x00000000fee00fff] reserved
BIOS-e820: [mem 0x00000000fff00000-0x00000000ffffffff] reserved
BIOS-e820: [mem 0x0000000100000000-0x000000e037ffffff] usable
BIOS-e820: [mem 0x000000e038000000-0x000000fcffffffff] reserved
BIOS-e820: [mem 0x0000010000000000-0x0000011ffeffffff] usable
and so direct mappings are created for huge memory hole between 0x000000e038000000 to 0x0000010000000000. Even though the kernel never generates memory accesses in that region, since the page tables mark them incorrectly as being WB, our (AMD) processor ends up causing a MCE while doing some memory bookkeeping/optimizations around that area.
This patch iterates through e820 and only direct maps ranges that are marked as E820_RAM, and keeps track of those pfn ranges. Depending on the alignment of E820 ranges, this may possibly result in using smaller size (i.e. 4K instead of 2M or 1G) page tables.
Quoted 3 lines
Have you tested it?
No
will update to

Quoted 7 lines

Subject: [PATCH] x86, 64bit, mm: hibernate use generic mapping_init
We should not set mapping for all under max_pfn.
That causes same problem that is fixed by
x86, mm: Only direct map addresses that are marked as E820_RAM
Make it only map range in pfn_mapped array.

Thanks,
Rafael

Signature · 2 lines

I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.

Borislav Petkov

maintainer

2013-01-04 07:09 UTC #183 lore raw

In reply to Yinghai Lu

Quoted 4 lines · Yinghai Lu

git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot
and it is on top of linus's tree 2013-01-03
plus tip:x86/mm, tip:x86/mm2

This is causing a merge conflict when merging tip:x86/mm2 after having merged tip:x86/mm ontop of -rc2+ (today's Linus' tree) in mm/nobootmem.c. free_all_bootmem_node has gained a reset_node_lowmem_managed_pages() call which got added in 9feedc9d831e18ae6d0d15aa562e5e46ba53647b.

Now, you have a patch in tip:x86/mm2 which kills that free_all_bootmem_node() function but the commit above adds that reset_node_lowmem_managed_pages() call to it.

A proper merge conflict resolve would need to be added to the pull request which sends tip:x86/mm2 upstream and then you'd need to rebase your stuff ontop. Or something better which I'm not thinking of right now...

Thanks.

Signature · 2 lines

Regards/Gruss,
Boris.

Yinghai Lu

author

2013-01-04 21:45 UTC #184 lore raw

Quoted 13 lines · Borislav Petkov

Quoted 4 lines · Yinghai Lu
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot
and it is on top of linus's tree 2013-01-03
plus tip:x86/mm, tip:x86/mm2
This is causing a merge conflict when merging tip:x86/mm2 after having merged tip:x86/mm ontop of -rc2+ (today's Linus' tree) in mm/nobootmem.c. free_all_bootmem_node has gained a reset_node_lowmem_managed_pages() call which got added in 9feedc9d831e18ae6d0d15aa562e5e46ba53647b.

Quoted 8 lines

Now, you have a patch in tip:x86/mm2 which kills that free_all_bootmem_node() function but the commit above adds that reset_node_lowmem_managed_pages() call to it.
A proper merge conflict resolve would need to be added to the pull request which sends tip:x86/mm2 upstream and then you'd need to rebase your stuff ontop. Or something better which I'm not thinking of right now...

Peter or Linus could figure it out.

H. Peter Anvin

reviewer

2013-01-14 20:46 UTC #185 lore raw

In reply to Yinghai Lu

This is getting extremely unwieldy and we need to get it broken up a bit.

I would really like to get the boot protocol changes earlier in the series, because it has interactions with work other people are doing and may need additional surgery. That is, the additions of flags and fields to make it possible for the kernel to indicate that > 4 GB booting is possible, not the actual implementation thereof. This split between protocol changes and implementation will also be useful for bisection.

-hpa

Yinghai Lu

author

2013-01-14 22:44 UTC #186 lore raw

Quoted 8 lines · H. Peter Anvin

This is getting extremely unwieldy and we need to get it broken up a bit.
I would really like to get the boot protocol changes earlier in the series, because it has interactions with work other people are doing and may need additional surgery. That is, the additions of flags and fields to make it possible for the kernel to indicate that > 4 GB booting is possible, not the actual implementation thereof. This split between protocol changes and implementation will also be useful for bisection.

When will we actually change protocol version number in the code?

We need to refer that number in the protocol doc.

Yinghai

H. Peter Anvin

reviewer

2013-01-14 23:17 UTC #187 lore raw

Quoted 10 lines · Yinghai Lu

Quoted 8 lines · H. Peter Anvin
This is getting extremely unwieldy and we need to get it broken up a bit.
I would really like to get the boot protocol changes earlier in the series, because it has interactions with work other people are doing and may need additional surgery. That is, the additions of flags and fields to make it possible for the kernel to indicate that > 4 GB booting is possible, not the actual implementation thereof. This split between protocol changes and implementation will also be useful for bisection.

Quoted 4 lines

When will we actually change protocol version number in the code?
We need to refer that number in the protocol doc.

The protocol change and the documentation go together (as separate but adjacent patches). We bump the number when we change the structure to accommodate the necessary fields and flags (i.e. a vacuous implementation), not when we add the full functionality.

The reason I want to do this this way is that I want to also make David Woodhouse's protocol fixes to make the EFI stub work correctly at the same time, so we get a single protocol level bump. I think it is better I merge both sets, and I was hoping to do that tomorrow if possible.

-hpa

David Woodhouse

2013-01-14 23:40 UTC #188 lore raw

Quoted 3 lines · H. Peter Anvin

The reason I want to do this this way is that I want to also make David Woodhouse's protocol fixes to make the EFI stub work correctly at the same time, so we get a single protocol level bump.

My changes don't need a protocol level bump. It's just two new bits in load_flags that old loaders won't care about.

Signature · 1 line

dwmw2

H. Peter Anvin

reviewer

2013-01-14 23:50 UTC #189 lore raw

Quoted 8 lines · David Woodhouse

Quoted 3 lines · H. Peter Anvin
The reason I want to do this this way is that I want to also make David Woodhouse's protocol fixes to make the EFI stub work correctly at the same time, so we get a single protocol level bump.
My changes don't need a protocol level bump. It's just two new bits in load_flags that old loaders won't care about.

I'm wondering if we should put your new flags in xloadflags instead just because some boot loaders have been known to clobber the loadflags when setting the upper bits. In theory it shouldn't matter... I'm wondering if it does in practice. The other bit is that Yinghai's changes want even more flags.

Either way might as well see if we can do it as closely adjacently as possible (but no, I don't want to drag this out.)

-hpa

David Woodhouse

2013-01-15 00:13 UTC #190 lore raw

Quoted 3 lines · H. Peter Anvin

I'm wondering if we should put your new flags in xloadflags instead just because some boot loaders have been known to clobber the loadflags when setting the upper bits.

It doesn't matter. Old broken bootloaders won't use the EFI stub entry point if they don't see the flags that indicate it's available. But they weren't going to anyway.

Signature · 1 line

dwmw2

Stefano Stabellini

2013-01-15 12:20 UTC #191 lore raw

In reply to Yinghai Lu

Quoted 14 lines · Yinghai Lu

Now we have limit kdump reseved under 896M, because kexec has the limitation. and also bzImage need to stay under 4g.
To make kexec/kdump could use range above 4g, we need to make bzImage and ramdisk could be loaded above 4g.
During booting bzImage will be unpacked on same postion and stay high.
The patches add fields in setup_header and boot_params to
1. get info about ramdisk position info above 4g from bootloader/kexec
2. get info about cmd_line_ptr info above 4g from bootloader/kexec
3. set xloadflags bit0 in header for bzImage and bootloader/kexec load could check that to decide if it could to put bzImage high.
4. use sentinel to make sure ext_* fields in boot_params could be used.

Quoted 6 lines

This patches is tested with kexec tools with local changes and they are sent to kexec list later.
could be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot

I tried to boot this kernel as PV guest with 2GB of RAM, but unfortunately it crashes early on at boot (earlyprintk=xen log appended).

mapping kernel into physical memory
about to get started...

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 3.8.0-rc3+ (sstabellini@st22) (gcc version 4.4.5 (Debian 4.4.5-8) ) #4 SMP Tue Jan 15 12:11:59 UTC 2013
[    0.000000] Command line: root=/dev/xvda1 rw loglevel=9 debug console=hvc0 earlyprintk=xen
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007fffffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x7fe00000-0x7fffffff]
[    0.000000]  [mem 0x7fe00000-0x7fffffff] page 4k
[    0.000000] BRK [0x023b8000, 0x023b8fff] PGTABLE
[    0.000000] BRK [0x023b9000, 0x023b9fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x7c000000-0x7fdfffff]
[    0.000000]  [mem 0x7c000000-0x7fdfffff] page 4k
[    0.000000] BRK [0x023ba000, 0x023bafff] PGTABLE
[    0.000000] BRK [0x023bb000, 0x023bbfff] PGTABLE
[    0.000000] BRK [0x023bc000, 0x023bcfff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0x7bffffff]
[    0.000000]  [mem 0x00100000-0x7bffffff] page 4k

(XEN) d15:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea0000080330:
(XEN) L4[0x1d4] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S
(XEN) Domain 15 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]----
(XEN) CPU: 3
(XEN) RIP: e033:[<ffffffff810052e4>]
(XEN) RFLAGS: 0000000000000206 EM: 1 CONTEXT: pv guest

(XEN) rax: ffffea0000000000   rbx: 000000000200c000   rcx: 0000000080000000
(XEN) rdx: 0000000000080300   rsi: 000000000200c000   rdi: 0000000000000000
(XEN) rbp: ffffffff82001dd8   rsp: ffffffff82001d90   r8:  0000000000000000
(XEN) r9:  0000000000000083   r10: 0000000000000000   r11: 0000000000000000
(XEN) r12: 0000000000000000   r13: 0000001000000000   r14: 0000000000000000
(XEN) r15: 0000000000100000   cr0: 000000008005003b   cr4: 00000000000026f0
(XEN) cr3: 0000000184cc8000   cr2: ffffea0000080330
(XEN) ds: 0000   es: 0000   fs: 0000   gs: 0000   ss: e02b   cs: e033
(XEN) Guest stack trace from rsp=ffffffff82001d90:
(XEN)    0000000080000000 0000000000000000 0000000000000000 ffffffff810052e4
(XEN)    000000010000e030 0000000000010006 ffffffff82001dd8 000000000000e02b
(XEN)    ffffffff81005299 ffffffff82001e08 ffffffff8100768c 0000000080000000
(XEN)    0000000080000000 0000001000000000 000000007ff00000 ffffffff82001e48
(XEN)    ffffffff82161b3a ffffffff82001e48 0000000001000000 00000000017cb000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff82001ed8
(XEN)    ffffffff821529cc ffffffff821d7920 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffff82001f00 ffffffff819a8e6f 0000000000000010
(XEN)    ffffffff82001ee8 ffffffff82001ea8 0000000000000000 ffffffff82001ec8
(XEN)    ffffffffffffffff ffffffff821d7920 0000000000000000 0000000000000000
(XEN)    0000000000000000 ffffffff82001f28 ffffffff8214bb69 ffffffff82001f28
(XEN)    ffffffff810556e6 ae32416208683d40 ffffffff821e12e0 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 ffffffff82001f38
(XEN)    ffffffff8214b4fc ffffffff82001ff8 ffffffff8214f3b3 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000 0000000000000000
(XEN)    0000000000000000 809822011f898975 000106a506100800 0000000000000001
(XEN)    0000000000000000 0000000000000000 0f00000060c0c748 ccccccccccccc305

Yinghai Lu

author

2013-01-15 16:43 UTC #192 lore raw

Quoted 41 lines · Stefano Stabellini

Quoted 3 lines

could be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot

I tried to boot this kernel as PV guest with 2GB of RAM, but unfortunately it crashes early on at boot (earlyprintk=xen log appended).

mapping kernel into physical memory
about to get started...

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 3.8.0-rc3+ (sstabellini@st22) (gcc version 4.4.5 (Debian 4.4.5-8) ) #4 SMP Tue Jan 15 12:11:59 UTC 2013
[    0.000000] Command line: root=/dev/xvda1 rw loglevel=9 debug console=hvc0 earlyprintk=xen
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007fffffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x7fe00000-0x7fffffff]
[    0.000000]  [mem 0x7fe00000-0x7fffffff] page 4k
[    0.000000] BRK [0x023b8000, 0x023b8fff] PGTABLE
[    0.000000] BRK [0x023b9000, 0x023b9fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x7c000000-0x7fdfffff]
[    0.000000]  [mem 0x7c000000-0x7fdfffff] page 4k
[    0.000000] BRK [0x023ba000, 0x023bafff] PGTABLE
[    0.000000] BRK [0x023bb000, 0x023bbfff] PGTABLE
[    0.000000] BRK [0x023bc000, 0x023bcfff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0x7bffffff]
[    0.000000]  [mem 0x00100000-0x7bffffff] page 4k

Quoted 6 lines

(XEN) d15:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea0000080330:
(XEN) L4[0x1d4] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S
(XEN) Domain 15 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]----

ok, i think i know the cause for now, will check if there is good way to fix it.

Thanks

Yinghai

Yinghai Lu

author

2013-01-15 19:28 UTC #193 lore raw

Quoted 50 lines · Yinghai Lu

Quoted 41 lines · Stefano Stabellini

Quoted 3 lines

could be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot

I tried to boot this kernel as PV guest with 2GB of RAM, but unfortunately it crashes early on at boot (earlyprintk=xen log appended).

mapping kernel into physical memory
about to get started...

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 3.8.0-rc3+ (sstabellini@st22) (gcc version 4.4.5 (Debian 4.4.5-8) ) #4 SMP Tue Jan 15 12:11:59 UTC 2013
[    0.000000] Command line: root=/dev/xvda1 rw loglevel=9 debug console=hvc0 earlyprintk=xen
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007fffffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x7fe00000-0x7fffffff]
[    0.000000]  [mem 0x7fe00000-0x7fffffff] page 4k
[    0.000000] BRK [0x023b8000, 0x023b8fff] PGTABLE
[    0.000000] BRK [0x023b9000, 0x023b9fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x7c000000-0x7fdfffff]
[    0.000000]  [mem 0x7c000000-0x7fdfffff] page 4k
[    0.000000] BRK [0x023ba000, 0x023bafff] PGTABLE
[    0.000000] BRK [0x023bb000, 0x023bbfff] PGTABLE
[    0.000000] BRK [0x023bc000, 0x023bcfff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0x7bffffff]
[    0.000000]  [mem 0x00100000-0x7bffffff] page 4k

Quoted 6 lines

(XEN) d15:v0: unhandled page fault (ec=0000)
(XEN) Pagetable walk from ffffea0000080330:
(XEN) L4[0x1d4] = 0000000000000000 ffffffffffffffff (XEN) domain_crash_sync called from entry.S
(XEN) Domain 15 (vcpu#0) crashed on cpu#3:
(XEN) ----[ Xen-4.3-unstable x86_64 debug=y Not tainted ]----

Quoted 2 lines

ok, i think i know the cause for now, will check if there is good way to fix it.

Can you please test attached patch?

Thanks

Yinghai

---
 arch/x86/mm/init.c |   11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

arch/x86/mm/init.c +10 -1

Index: linux-2.6/arch/x86/mm/init.c
===================================================================
@@ -25,6 +25,8 @@ static unsigned long __initdata pgt_buf_
 
 static unsigned long min_pfn_mapped;
 
+static bool __initdata can_use_brk_pgt = true;
+
 /*
  * Pages returned are already directly mapped.
  *

@@ -47,7 +49,7 @@ __ref void *alloc_low_pages(unsigned int
 						__GFP_ZERO, order);
 	}
 
-	if ((pgt_buf_end + num) > pgt_buf_top) {
+	if ((pgt_buf_end + num) > pgt_buf_top || !can_use_brk_pgt) {
 		unsigned long ret;
 		if (min_pfn_mapped >= max_pfn_mapped)
 			panic("alloc_low_page: ran out of memory");

@@ -372,8 +374,15 @@ static unsigned long __init init_range_m
 		if (start >= end)
 			continue;
 
+		/*
+		 * if it is overlapping with brk pgt, we need to
+		 * alloc pgt buf from memblock instead.
+		 */
+		can_use_brk_pgt = max(start, (u64)pgt_buf_end<<PAGE_SHIFT) >=
+				    min(end, (u64)pgt_buf_top<<PAGE_SHIFT);
 		init_memory_mapping(start, end);
 		mapped_ram_size += end - start;
+		can_use_brk_pgt = true;
 	}
 
 	return mapped_ram_size;

Stefano Stabellini

2013-01-16 11:32 UTC #194 lore raw

Quoted 51 lines · Yinghai Lu

Quoted 50 lines · Yinghai Lu

Quoted 47 lines · Stefano Stabellini

Quoted 3 lines

could be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot

I tried to boot this kernel as PV guest with 2GB of RAM, but unfortunately it crashes early on at boot (earlyprintk=xen log appended).

mapping kernel into physical memory
about to get started...

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 3.8.0-rc3+ (sstabellini@st22) (gcc version 4.4.5 (Debian 4.4.5-8) ) #4 SMP Tue Jan 15 12:11:59 UTC 2013
[    0.000000] Command line: root=/dev/xvda1 rw loglevel=9 debug console=hvc0 earlyprintk=xen
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007fffffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x7fe00000-0x7fffffff]
[    0.000000]  [mem 0x7fe00000-0x7fffffff] page 4k
[    0.000000] BRK [0x023b8000, 0x023b8fff] PGTABLE
[    0.000000] BRK [0x023b9000, 0x023b9fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x7c000000-0x7fdfffff]
[    0.000000]  [mem 0x7c000000-0x7fdfffff] page 4k
[    0.000000] BRK [0x023ba000, 0x023bafff] PGTABLE
[    0.000000] BRK [0x023bb000, 0x023bbfff] PGTABLE
[    0.000000] BRK [0x023bc000, 0x023bcfff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0x7bffffff]
[    0.000000]  [mem 0x00100000-0x7bffffff] page 4k

Quoted 4 lines

Quoted 2 lines
ok, i think i know the cause for now, will check if there is good way to fix it.
Can you please test attached patch?

Yes, this patch seems to fix the problem.
I have also run the kernel with this patch as dom0 and PV domU with various memory configurations up to 8GB, and I have no errors to report.

Yinghai Lu

author

2013-01-16 17:31 UTC #195 lore raw

Quoted 52 lines · Stefano Stabellini

Quoted 51 lines · Yinghai Lu

Quoted 50 lines · Yinghai Lu

Quoted 47 lines · Stefano Stabellini

Quoted 3 lines

could be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-x86-boot

I tried to boot this kernel as PV guest with 2GB of RAM, but unfortunately it crashes early on at boot (earlyprintk=xen log appended).

mapping kernel into physical memory
about to get started...

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 3.8.0-rc3+ (sstabellini@st22) (gcc version 4.4.5 (Debian 4.4.5-8) ) #4 SMP Tue Jan 15 12:11:59 UTC 2013
[    0.000000] Command line: root=/dev/xvda1 rw loglevel=9 debug console=hvc0 earlyprintk=xen
[    0.000000] ACPI in unprivileged domain disabled
[    0.000000] e820: BIOS-provided physical RAM map:
[    0.000000] Xen: [mem 0x0000000000000000-0x000000000009ffff] usable
[    0.000000] Xen: [mem 0x00000000000a0000-0x00000000000fffff] reserved
[    0.000000] Xen: [mem 0x0000000000100000-0x000000007fffffff] usable
[    0.000000] bootconsole [xenboot0] enabled
[    0.000000] NX (Execute Disable) protection: active
[    0.000000] DMI not present or invalid.
[    0.000000] e820: update [mem 0x00000000-0x0000ffff] usable ==> reserved
[    0.000000] e820: remove [mem 0x000a0000-0x000fffff] usable
[    0.000000] No AGP bridge found
[    0.000000] e820: last_pfn = 0x80000 max_arch_pfn = 0x400000000
[    0.000000] Base memory trampoline at [ffff88000009a000] 9a000 size 24576
[    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
[    0.000000]  [mem 0x00000000-0x000fffff] page 4k
[    0.000000] init_memory_mapping: [mem 0x7fe00000-0x7fffffff]
[    0.000000]  [mem 0x7fe00000-0x7fffffff] page 4k
[    0.000000] BRK [0x023b8000, 0x023b8fff] PGTABLE
[    0.000000] BRK [0x023b9000, 0x023b9fff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x7c000000-0x7fdfffff]
[    0.000000]  [mem 0x7c000000-0x7fdfffff] page 4k
[    0.000000] BRK [0x023ba000, 0x023bafff] PGTABLE
[    0.000000] BRK [0x023bb000, 0x023bbfff] PGTABLE
[    0.000000] BRK [0x023bc000, 0x023bcfff] PGTABLE
[    0.000000] init_memory_mapping: [mem 0x00100000-0x7bffffff]
[    0.000000]  [mem 0x00100000-0x7bffffff] page 4k

Quoted 8 lines

Quoted 4 lines
Quoted 2 lines
ok, i think i know the cause for now, will check if there is good way to fix it.
Can you please test attached patch?
Yes, this patch seems to fix the problem.
I have also run the kernel with this patch as dom0 and PV domU with various memory configurations up to 8GB, and I have no errors to report.

Thanks a lot for testing all those conf out.

Hi, Peter,
this bug is in tip:x86/mm2 already, but looks like it is only triggered on with one patch in for-x86-boot.
http://git.kernel.org/?p=linux/kernel/git/yinghai/linux-yinghai.git;a=commitdiff;h=af4f3bc044d1556f89bd488c7ea75e2a162bb273

rom af4f3bc044d1556f89bd488c7ea75e2a162bb273 Mon Sep 17 00:00:00 2001
From: Yinghai Lu <[email protected]>
Date: Mon, 14 Jan 2013 21:11:05 -0800
Subject: [PATCH] x86, mm: Fix page table early allocation offset checking

During debugging loading kernel above 4G, found that one page is not used in pre-allocated BRK area for early page allocation.

pgt_buf_top is address that can not be used, so should check if that new end is above that top, otherwise last page will not be used.

Fix that checking and also add print out for allocation from pre-allocated BRK area to catch possible bugs later.

Signed-off-by Yinghai Lu <[email protected]>

---
 arch/x86/mm/init.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

arch/x86/mm/init.c +3 -1

index 6f85de8..c4293cf 100644
@@ -47,7 +47,7 @@ __ref void *alloc_low_pages(unsigned int num)
 						__GFP_ZERO, order);
 	}
 
-	if ((pgt_buf_end + num) >= pgt_buf_top) {
+	if ((pgt_buf_end + num) > pgt_buf_top) {
 		unsigned long ret;
 		if (min_pfn_mapped >= max_pfn_mapped)
 			panic("alloc_low_page: ran out of memory");

@@ -61,6 +61,8 @@ __ref void *alloc_low_pages(unsigned int num)
 	} else {
 		pfn = pgt_buf_end;
 		pgt_buf_end += num;
+		printk(KERN_DEBUG "BRK [%#010lx, %#010lx] PGTABLE\n",
+			pfn << PAGE_SHIFT, (pgt_buf_end << PAGE_SHIFT) - 1);
 	}
 
 	for (i = 0; i < num; i++) {

Signature · 13 lines

1.7.7.6


So we could
1. just put the fix as first one in for-x86-boot.
2. or fold uncovering patch and fix into x86/mm2, and I will send
patches again, and you rebase the whole tip:x86/mm2.

Please let me know which one you like.

Thanks

Yinghai

H. Peter Anvin

reviewer

2013-01-16 17:38 UTC #196 lore raw

Quoted 6 lines · Yinghai Lu

rom af4f3bc044d1556f89bd488c7ea75e2a162bb273 Mon Sep 17 00:00:00 2001
From: Yinghai Lu <[email protected]>
Date: Mon, 14 Jan 2013 21:11:05 -0800
Subject: [PATCH] x86, mm: Fix page table early allocation offset checking

Quoted 6 lines

During debugging loading kernel above 4G, found that one page is not used in pre-allocated BRK area for early page allocation.
pgt_buf_top is address that can not be used, so should check if that new end is above that top, otherwise last page will not be used.

The first sentence here doesn't parse, and this description doesn't give any hint to anyone who is researching this code in say, five years, what problems this caused.

I can't really figure it out, either; from looking at the thread and the patch I'm assuming the problem is somehow that the code failed to use the last page in the brk buffer, which somehow lead to a Xen boot failure... but the bits from here to there are totally unclear.

-hpa

Signature · 2 lines

H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

Yinghai Lu

author

2013-01-16 18:20 UTC #197 lore raw

Quoted 4 lines · H. Peter Anvin

Quoted 2 lines · Yinghai Lu

Quoted 8 lines

The first sentence here doesn't parse, and this description doesn't give any hint to anyone who is researching this code in say, five years, what problems this caused.
I can't really figure it out, either; from looking at the thread and the patch I'm assuming the problem is somehow that the code failed to use the last page in the brk buffer, which somehow lead to a Xen boot failure... but the bits from here to there are totally unclear.

ok, let me try again.
tip:x86/mm2 does not fail on xen testing from Stefano and Konrad.

Stefano found booting failure with PV xen with for-x86-boot.

for-x86-boot has one patch that is trying to get back an wasted page in pre-allocated BRK
and that cause xen pv fails with 2G setup.
that patch just uncover one bug in x86/mm2.

So questions:
1. do we need to rebase x86/mm2 to fold the two patches in. ?
2. or just put fixes at beginning for-x86-boot ?

Thanks

Yinghai

Yinghai Lu

author

2013-01-17 02:35 UTC #198 lore raw

Quoted 19 lines · Yinghai Lu

Quoted 4 lines · H. Peter Anvin
Quoted 2 lines · Yinghai Lu
Quoted 8 lines
The first sentence here doesn't parse, and this description doesn't give any hint to anyone who is researching this code in say, five years, what problems this caused.
I can't really figure it out, either; from looking at the thread and the patch I'm assuming the problem is somehow that the code failed to use the last page in the brk buffer, which somehow lead to a Xen boot failure... but the bits from here to there are totally unclear.
ok, let me try again.
tip:x86/mm2 does not fail on xen testing from Stefano and Konrad.
Stefano found booting failure with PV xen with for-x86-boot.

Quoted 9 lines

for-x86-boot has one patch that is trying to get back an wasted page in pre-allocated BRK
and that cause xen pv fails with 2G setup.
that patch just uncover one bug in x86/mm2.
So questions:
1. do we need to rebase x86/mm2 to fold the two patches in. ?
2. or just put fixes at beginning for-x86-boot ?

I updated for-x86-boot branch via second path.
git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git
for-x86-boot