[PATCH] linux/x86: Initialize high_memory as early as possible

[PATCH] linux/x86: Initialize high_memory as early as possible

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 202 bytes --]

Also all other variables dependent on the same input(s). This is a prerequisite patch for two ones to follow. I will
post a similar change for mainline Linux soon.

Signed-off-by: jbeulich@novell.com 


[-- Attachment #2: xenlinux-x86-high_memory-early.patch --]
[-- Type: text/plain, Size: 3294 bytes --]

Index: 2006-06-29/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c
===================================================================
--- 2006-06-29.orig/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c	2006-06-12 08:24:28.000000000 +0200
+++ 2006-06-29/linux-2.6-xen-sparse/arch/i386/kernel/setup-xen.c	2006-06-29 15:26:47.000000000 +0200
@@ -1210,6 +1210,14 @@ static unsigned long __init setup_memory
 	}
 	printk(KERN_NOTICE "%ldMB HIGHMEM available.\n",
 		pages_to_mb(highend_pfn - highstart_pfn));
+	num_physpages = highend_pfn;
+	high_memory = (void *) __va(highstart_pfn * PAGE_SIZE - 1) + 1;
+#else
+	num_physpages = max_low_pfn;
+	high_memory = (void *) __va(max_low_pfn * PAGE_SIZE - 1) + 1;
+#endif
+#ifdef CONFIG_FLATMEM
+	max_mapnr = num_physpages;
 #endif
 	printk(KERN_NOTICE "%ldMB LOWMEM available.\n",
 			pages_to_mb(max_low_pfn));
Index: 2006-06-29/linux-2.6-xen-sparse/arch/i386/mm/init-xen.c
===================================================================
--- 2006-06-29.orig/linux-2.6-xen-sparse/arch/i386/mm/init-xen.c	2006-06-14 18:10:51.000000000 +0200
+++ 2006-06-29/linux-2.6-xen-sparse/arch/i386/mm/init-xen.c	2006-06-29 15:26:47.000000000 +0200
@@ -600,18 +600,6 @@ static void __init test_wp_bit(void)
 	}
 }
 
-static void __init set_max_mapnr_init(void)
-{
-#ifdef CONFIG_HIGHMEM
-	num_physpages = highend_pfn;
-#else
-	num_physpages = max_low_pfn;
-#endif
-#ifdef CONFIG_FLATMEM
-	max_mapnr = num_physpages;
-#endif
-}
-
 static struct kcore_list kcore_mem, kcore_vmalloc; 
 
 void __init mem_init(void)
@@ -648,13 +636,6 @@ void __init mem_init(void)
 	}
 #endif
  
-	set_max_mapnr_init();
-
-#ifdef CONFIG_HIGHMEM
-	high_memory = (void *) __va(highstart_pfn * PAGE_SIZE - 1) + 1;
-#else
-	high_memory = (void *) __va(max_low_pfn * PAGE_SIZE - 1) + 1;
-#endif
 	printk("vmalloc area: %lx-%lx, maxmem %lx\n",
 	       VMALLOC_START,VMALLOC_END,MAXMEM);
 	BUG_ON(VMALLOC_START > VMALLOC_END);
Index: 2006-06-29/linux-2.6-xen-sparse/arch/x86_64/kernel/setup-xen.c
===================================================================
--- 2006-06-29.orig/linux-2.6-xen-sparse/arch/x86_64/kernel/setup-xen.c	2006-06-12 08:24:28.000000000 +0200
+++ 2006-06-29/linux-2.6-xen-sparse/arch/x86_64/kernel/setup-xen.c	2006-06-29 15:26:47.000000000 +0200
@@ -706,6 +706,11 @@ void __init setup_arch(char **cmdline_p)
 	 * we are rounding upwards:
 	 */
 	end_pfn = e820_end_of_ram();
+	/* How many end-of-memory variables you have, grandma! */
+	max_low_pfn = end_pfn;
+	max_pfn = end_pfn;
+	num_physpages = end_pfn;
+	high_memory = (void *)__va(end_pfn * PAGE_SIZE - 1) + 1;
 
 	check_efer();
 
Index: 2006-06-29/linux-2.6-xen-sparse/arch/x86_64/mm/init-xen.c
===================================================================
--- 2006-06-29.orig/linux-2.6-xen-sparse/arch/x86_64/mm/init-xen.c	2006-06-12 08:24:28.000000000 +0200
+++ 2006-06-29/linux-2.6-xen-sparse/arch/x86_64/mm/init-xen.c	2006-06-29 15:26:47.000000000 +0200
@@ -894,12 +894,6 @@ void __init mem_init(void)
 #endif
 	no_iommu_init();
 
-	/* How many end-of-memory variables you have, grandma! */
-	max_low_pfn = end_pfn;
-	max_pfn = end_pfn;
-	num_physpages = end_pfn;
-	high_memory = (void *) __va(end_pfn * PAGE_SIZE);
-
 	/* clear the zero-page */
 	memset(empty_zero_page, 0, PAGE_SIZE);
 

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Re: [PATCH] linux/x86: Initialize high_memory as early as possible

[Keir Fraser]

On 29 Jun 2006, at 14:42, Jan Beulich wrote:

> Also all other variables dependent on the same input(s). This is a 
> prerequisite patch for two ones to follow. I will
> post a similar change for mainline Linux soon.
>
> Signed-off-by: jbeulich@novell.com

Is this just for the usage in kunmap_atomic? Why did you change that, 
by the way: FIXADDR_START looked like a safe enough test to me.

  -- Keir

Re: [PATCH] linux/x86: Initialize high_memory as early as possible

[Jan Beulich]

>>> Keir Fraser <Keir.Fraser@cl.cam.ac.uk> 29.06.06 15:55 >>>
>
>On 29 Jun 2006, at 14:42, Jan Beulich wrote:
>
>> Also all other variables dependent on the same input(s). This is a 
>> prerequisite patch for two ones to follow. I will
>> post a similar change for mainline Linux soon.
>>
>> Signed-off-by: jbeulich@novell.com 
>
>Is this just for the usage in kunmap_atomic? Why did you change that, 

Not only, also for the added check in xen_{create,destroy}_contiguous_region
in another of the patches just sent.

>by the way: FIXADDR_START looked like a safe enough test to me.

This didn't seem safe enough to me, and apparently also not to the original
author (at least I attribute the FIXME comment to this) - after all not
everything before FIXADDR_START is high memory.
One could say that under DEBUG_HIGHMEM the check should be more strict
(so that the subsequent BUG() condition fires in more broken cases), but
without DEBUG_HIGHMEM it might be left as-is to avoid zapping incorrect
page table entries.

Jan

Re: [PATCH] linux/x86: Initialize high_memory as early as possible

[Keir Fraser]

On 29 Jun 2006, at 15:03, Jan Beulich wrote:

> This didn't seem safe enough to me, and apparently also not to the 
> original
> author (at least I attribute the FIXME comment to this) - after all not
> everything before FIXADDR_START is high memory.
> One could say that under DEBUG_HIGHMEM the check should be more strict
> (so that the subsequent BUG() condition fires in more broken cases), 
> but
> without DEBUG_HIGHMEM it might be left as-is to avoid zapping incorrect
> page table entries.

Any kmap_atomic virtual address should be above FIXADDR_START. You have 
a point about debugging though (e.g., passing a non-atomic kmap address 
to kunmap_atomic).

  -- Keir