[PATCH 1/8] x86 boot: x86_64 build reserve_bootmem_generic fix

[PATCH 1/8] x86 boot: x86_64 build reserve_bootmem_generic fix

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Fix x86_64 build.  The addition of a third 'flags' argument
to reserve_bootmem() and similar routines missed one instance.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/e820.c |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux.orig/arch/x86/kernel/e820.c	2008-06-10 21:31:21.000000000 -0700
+++ linux/arch/x86/kernel/e820.c	2008-06-10 22:37:27.256448098 -0700
@@ -636,7 +636,8 @@ void __init early_res_to_bootmem(u64 sta
 		printk(KERN_INFO "  early res: %d [%llx-%llx] %s\n", i,
 			final_start, final_end - 1, r->name);
 #ifdef CONFIG_X86_64
-		reserve_bootmem_generic(final_start, final_end - final_start);
+		reserve_bootmem_generic(final_start, final_end - final_start,
+				BOOTMEM_DEFAULT);
 #else
 		reserve_bootmem(final_start, final_end - final_start,
 				BOOTMEM_DEFAULT);

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 2/8] x86 boot: e820 code indentation fix

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Fix indentation.  An earlier code merge got the
indentation of four lines of code off by a tab.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/e820.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- linux.orig/arch/x86/kernel/e820.c	2008-06-10 22:37:27.000000000 -0700
+++ linux/arch/x86/kernel/e820.c	2008-06-10 23:04:17.728936162 -0700
@@ -207,10 +207,10 @@ int __init sanitize_e820_map(struct e820
 		struct e820entry *pbios; /* pointer to original bios entry */
 		unsigned long long addr; /* address for this change point */
 	};
-static struct change_member change_point_list[2*E820_X_MAX] __initdata;
-static struct change_member *change_point[2*E820_X_MAX] __initdata;
-static struct e820entry *overlap_list[E820_X_MAX] __initdata;
-static struct e820entry new_bios[E820_X_MAX] __initdata;
+	static struct change_member change_point_list[2*E820_X_MAX] __initdata;
+	static struct change_member *change_point[2*E820_X_MAX] __initdata;
+	static struct e820entry *overlap_list[E820_X_MAX] __initdata;
+	static struct e820entry new_bios[E820_X_MAX] __initdata;
 	struct change_member *change_tmp;
 	unsigned long current_type, last_type;
 	unsigned long long last_addr;

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 3/8] x86 boot: x86_64 efi compiler warning fix

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Fix a compiler warning.  Rather than always casting a u32 to a pointer
(which generates a warning on x86_64 systems) instead separate the
x86_32 and x86_64 assignments entirely with ifdefs.  Until other recent
changes to this code, it used to have x86_64 separated like this.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/efi.c |   14 +++++++++-----
 1 file changed, 9 insertions(+), 5 deletions(-)

--- linux.orig/arch/x86/kernel/efi.c	2008-06-12 17:18:57.000000000 -0700
+++ linux/arch/x86/kernel/efi.c	2008-06-12 17:32:14.984928792 -0700
@@ -242,9 +242,11 @@ void __init efi_reserve_early(void)
 {
 	unsigned long pmap;
 
+#ifdef CONFIG_X86_32
 	pmap = boot_params.efi_info.efi_memmap;
-#ifdef CONFIG_X86_64
-	pmap += (__u64)boot_params.efi_info.efi_memmap_hi << 32;
+#else
+	pmap = (boot_params.efi_info.efi_memmap |
+		((__u64)boot_params.efi_info.efi_memmap_hi<<32));
 #endif
 	memmap.phys_map = (void *)pmap;
 	memmap.nr_map = boot_params.efi_info.efi_memmap_size /
@@ -284,10 +286,12 @@ void __init efi_init(void)
 	int i = 0;
 	void *tmp;
 
+#ifdef CONFIG_X86_32
 	efi_phys.systab = (efi_system_table_t *)boot_params.efi_info.efi_systab;
-#ifdef CONFIG_X86_64
-	efi_phys.systab = (void *)efi_phys.systab +
-		((__u64)boot_params.efi_info.efi_systab_hi<<32);
+#else
+	efi_phys.systab = (efi_system_table_t *)
+		(boot_params.efi_info.efi_systab |
+		 ((__u64)boot_params.efi_info.efi_systab_hi<<32));
 #endif
 
 	efi.systab = early_ioremap((unsigned long)efi_phys.systab,

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

In order to support EFI firmware which places the EFI memmap within
the EBDA (Extended BIOS Data Area), allow for the possibility that we
might try to reserve_early() the "EFI memmap" area twice, once as part
of the larger EBDA area and once by itself.  Since the reserve_early()
mechanism does not allow such double reservations, detect and avoid the
"EFI memmap" reserve_early() call if it would overlap the EBDA area.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/efi.c       |    3 ++-
 arch/x86/kernel/head.c      |   12 +++++++++++-
 include/asm-x86/bios_ebda.h |    1 +
 include/asm-x86/e820.h      |    1 +
 4 files changed, 15 insertions(+), 2 deletions(-)

--- linux.orig/arch/x86/kernel/efi.c	2008-06-13 00:51:17.350774123 -0700
+++ linux/arch/x86/kernel/efi.c	2008-06-13 00:53:10.053599898 -0700
@@ -253,7 +253,8 @@ void __init efi_reserve_early(void)
 		boot_params.efi_info.efi_memdesc_size;
 	memmap.desc_version = boot_params.efi_info.efi_memdesc_version;
 	memmap.desc_size = boot_params.efi_info.efi_memdesc_size;
-	reserve_early(pmap, pmap + memmap.nr_map * memmap.desc_size,
+	if (!range_in_ebda_area(pmap, pmap + memmap.nr_map * memmap.desc_size))
+		reserve_early(pmap, pmap + memmap.nr_map * memmap.desc_size,
 		      "EFI memmap");
 }
 
--- linux.orig/arch/x86/kernel/head.c	2008-06-13 00:51:17.350774123 -0700
+++ linux/arch/x86/kernel/head.c	2008-06-13 00:52:45.208095174 -0700
@@ -6,6 +6,9 @@
 
 #define BIOS_LOWMEM_KILOBYTES 0x413
 
+static unsigned int __initdata ebda_start;
+static unsigned int __initdata ebda_end;
+
 /*
  * The BIOS places the EBDA/XBDA at the top of conventional
  * memory, and usually decreases the reported amount of
@@ -51,7 +54,14 @@ void __init reserve_ebda_region(void)
 		lowmem = 0x9f000;
 
 	/* reserve all memory between lowmem and the 1MB mark */
-	reserve_early(lowmem, 0x100000, "BIOS reserved");
+	ebda_start = lowmem;
+	ebda_end = 0x100000;
+	reserve_early(ebda_start, ebda_end, "BIOS reserved");
+}
+
+int __init range_in_ebda_area(u64 start, u64 end)
+{
+	return start >= ebda_start && end <= ebda_end;
 }
 
 void __init reserve_setup_data(void)
--- linux.orig/include/asm-x86/bios_ebda.h	2008-06-13 00:51:17.350774123 -0700
+++ linux/include/asm-x86/bios_ebda.h	2008-06-13 00:51:31.819650439 -0700
@@ -15,5 +15,6 @@ static inline unsigned int get_bios_ebda
 }
 
 void reserve_ebda_region(void);
+int range_in_ebda_area(u64 start, u64 end);
 
 #endif /* _MACH_BIOS_EBDA_H */
--- linux.orig/include/asm-x86/e820.h	2008-06-13 00:51:17.354774365 -0700
+++ linux/include/asm-x86/e820.h	2008-06-13 00:51:31.831651166 -0700
@@ -84,6 +84,7 @@ extern unsigned long end_user_pfn;
 extern u64 find_e820_area(u64 start, u64 end, u64 size, u64 align);
 extern u64 find_e820_area_size(u64 start, u64 *sizep, u64 align);
 extern void reserve_early(u64 start, u64 end, char *name);
+extern int range_in_ebda_area(u64 start, u64 end);
 extern void free_early(u64 start, u64 end);
 extern void early_res_to_bootmem(u64 start, u64 end);
 extern int page_is_reserved_early(unsigned long pagenr);

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Yinghai Lu]

On Sun, Jun 15, 2008 at 11:30 PM, Paul Jackson <pj@sgi.com> wrote:
> From: Paul Jackson <pj@sgi.com>
>
> In order to support EFI firmware which places the EFI memmap within
> the EBDA (Extended BIOS Data Area), allow for the possibility that we
> might try to reserve_early() the "EFI memmap" area twice, once as part
> of the larger EBDA area and once by itself.  Since the reserve_early()
> mechanism does not allow such double reservations, detect and avoid the
> "EFI memmap" reserve_early() call if it would overlap the EBDA area.
>
> Signed-off-by: Paul Jackson <pj@sgi.com>
>
> ---
>  arch/x86/kernel/efi.c       |    3 ++-
>  arch/x86/kernel/head.c      |   12 +++++++++++-
>  include/asm-x86/bios_ebda.h |    1 +
>  include/asm-x86/e820.h      |    1 +
>  4 files changed, 15 insertions(+), 2 deletions(-)
>
> --- linux.orig/arch/x86/kernel/efi.c    2008-06-13 00:51:17.350774123 -0700
> +++ linux/arch/x86/kernel/efi.c 2008-06-13 00:53:10.053599898 -0700
> @@ -253,7 +253,8 @@ void __init efi_reserve_early(void)
>                boot_params.efi_info.efi_memdesc_size;
>        memmap.desc_version = boot_params.efi_info.efi_memdesc_version;
>        memmap.desc_size = boot_params.efi_info.efi_memdesc_size;
> -       reserve_early(pmap, pmap + memmap.nr_map * memmap.desc_size,
> +       if (!range_in_ebda_area(pmap, pmap + memmap.nr_map * memmap.desc_size))
> +               reserve_early(pmap, pmap + memmap.nr_map * memmap.desc_size,
>                      "EFI memmap");
>  }
>
> --- linux.orig/arch/x86/kernel/head.c   2008-06-13 00:51:17.350774123 -0700
> +++ linux/arch/x86/kernel/head.c        2008-06-13 00:52:45.208095174 -0700
> @@ -6,6 +6,9 @@
>
>  #define BIOS_LOWMEM_KILOBYTES 0x413
>
> +static unsigned int __initdata ebda_start;
> +static unsigned int __initdata ebda_end;
> +
>  /*
>  * The BIOS places the EBDA/XBDA at the top of conventional
>  * memory, and usually decreases the reported amount of
> @@ -51,7 +54,14 @@ void __init reserve_ebda_region(void)
>                lowmem = 0x9f000;
>
>        /* reserve all memory between lowmem and the 1MB mark */
> -       reserve_early(lowmem, 0x100000, "BIOS reserved");
> +       ebda_start = lowmem;
> +       ebda_end = 0x100000;
> +       reserve_early(ebda_start, ebda_end, "BIOS reserved");
> +}
> +
> +int __init range_in_ebda_area(u64 start, u64 end)
> +{
> +       return start >= ebda_start && end <= ebda_end;
>  }
>
>  void __init reserve_setup_data(void)
> --- linux.orig/include/asm-x86/bios_ebda.h      2008-06-13 00:51:17.350774123 -0700
> +++ linux/include/asm-x86/bios_ebda.h   2008-06-13 00:51:31.819650439 -0700
> @@ -15,5 +15,6 @@ static inline unsigned int get_bios_ebda
>  }
>
>  void reserve_ebda_region(void);
> +int range_in_ebda_area(u64 start, u64 end);
>
>  #endif /* _MACH_BIOS_EBDA_H */
> --- linux.orig/include/asm-x86/e820.h   2008-06-13 00:51:17.354774365 -0700
> +++ linux/include/asm-x86/e820.h        2008-06-13 00:51:31.831651166 -0700
> @@ -84,6 +84,7 @@ extern unsigned long end_user_pfn;
>  extern u64 find_e820_area(u64 start, u64 end, u64 size, u64 align);
>  extern u64 find_e820_area_size(u64 start, u64 *sizep, u64 align);
>  extern void reserve_early(u64 start, u64 end, char *name);
> +extern int range_in_ebda_area(u64 start, u64 end);
>  extern void free_early(u64 start, u64 end);
>  extern void early_res_to_bootmem(u64 start, u64 end);
>  extern int page_is_reserved_early(unsigned long pagenr);

how about patial overlapping?

YH

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

Yinghai wrote:
> how about patial overlapping?

I do not understand what you ask.

I suppose your question is a minor typo of:

> how about partial overlapping?

... however I don't understand that either - sorry.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Yinghai Lu]

On Mon, Jun 16, 2008 at 12:32 AM, Paul Jackson <pj@sgi.com> wrote:
> Yinghai wrote:
>> how about patial overlapping?
>
> I do not understand what you ask.
>
> I suppose your question is a minor typo of:
>
>> how about partial overlapping?
>
> ... however I don't understand that either - sorry.

EFI memmap and ebda is partial overlapping?

you may expand range_in_ebda_area(), and let it handle overlapping...

YH

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

Yinghai wrote:
> EFI memmap and ebda is partial overlapping?
> 
> you may expand range_in_ebda_area(), and let it handle overlapping...

Ok - now I understand your comment.

I hesitated at first to handle the overlapping case because it was
not clear to me how to handle it (and I didn't happen to need it ;).

I suppose that what I should do is reserve any additional range in the
memmap not already in the ebda reservation.

ugh ;).

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Huang, Ying]

On Sun, 2008-06-15 at 23:30 -0700, Paul Jackson wrote:
> From: Paul Jackson <pj@sgi.com>
> 
> In order to support EFI firmware which places the EFI memmap within
> the EBDA (Extended BIOS Data Area), allow for the possibility that we

Boot loader places the EFI memmap,  not EFI firmware. So I think it is
better to change boot loader to avoid memory area of EBDA. Or do not
reserve EBDA on EFI system.

Best Regards,
Huang Ying

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

Huang wrote:
>  I think it is better to change boot loader to avoid memory area of EBDA.

Would this require the bootloader to know the kernels rather arbitrary
heuristics for inventing and placing an EBDA area, in reserve_ebda_region()?

In general, I would think it better not to have to code into the EFI
firmware or bootloader such knowledge.  But perhaps I am wrong here.

If the kernel is going to reserve an EBDA region even if no EBDA is
requested by the BIOS, then I would think that the kernel should be
more tolerant of BIOS's that put something else in that place.

> Or do not reserve EBDA on EFI system.

I suppose.  This would have been a bigger change than I could
suggest.  For all I know, there are existing systems using EBDA
and EFI together.  Would this change break them?

If you have good reason to know that's essentially impossible then
I have no objections, so far as my needs go, to not reserving EBDA
on EFI systems.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Huang, Ying]

On Mon, 2008-06-16 at 03:24 -0500, Paul Jackson wrote:
> Huang wrote:
> >  I think it is better to change boot loader to avoid memory area of EBDA.
> 
> Would this require the bootloader to know the kernels rather arbitrary
> heuristics for inventing and placing an EBDA area, in reserve_ebda_region()?

I think it is sufficient for boot loader to avoid memory area from
0x9f000 to 0x100000. This can be seen as compatible code for legacy
BIOS.

> In general, I would think it better not to have to code into the EFI
> firmware or bootloader such knowledge.  But perhaps I am wrong here.
> 
> If the kernel is going to reserve an EBDA region even if no EBDA is
> requested by the BIOS, then I would think that the kernel should be
> more tolerant of BIOS's that put something else in that place.
> 
> > Or do not reserve EBDA on EFI system.
> 
> I suppose.  This would have been a bigger change than I could
> suggest.  For all I know, there are existing systems using EBDA
> and EFI together.  Would this change break them?
> 
> If you have good reason to know that's essentially impossible then
> I have no objections, so far as my needs go, to not reserving EBDA
> on EFI systems.

I think if EBDA area is used in EFI system, it should be reserved in EFI
memory map.

Best Regards,
Huang Ying

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

Huang wrote:
> I think it is sufficient for boot loader to avoid memory area from
> 0x9f000 to 0x100000. This can be seen as compatible code for legacy
> BIOS.

That might work -- I'll give it a try.

> I think if EBDA area is used in EFI system, it should be reserved in EFI
> memory map.

Would you recommend doing this with code in arch/x86/kernel/head.c,
that did not invoke reserve_ebda_region() if efi_enabled was set?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Huang, Ying]

On Mon, 2008-06-16 at 04:09 -0500, Paul Jackson wrote:
> Huang wrote:
> > I think it is sufficient for boot loader to avoid memory area from
> > 0x9f000 to 0x100000. This can be seen as compatible code for legacy
> > BIOS.
> 
> That might work -- I'll give it a try.
> 
> > I think if EBDA area is used in EFI system, it should be reserved in EFI
> > memory map.
> 
> Would you recommend doing this with code in arch/x86/kernel/head.c,
> that did not invoke reserve_ebda_region() if efi_enabled was set?

Yes.

Best Regards,
Huang Ying

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[H. Peter Anvin]

Huang, Ying wrote:
>>> Or do not reserve EBDA on EFI system.
>> I suppose.  This would have been a bigger change than I could
>> suggest.  For all I know, there are existing systems using EBDA
>> and EFI together.  Would this change break them?
>>
>> If you have good reason to know that's essentially impossible then
>> I have no objections, so far as my needs go, to not reserving EBDA
>> on EFI systems.
> 
> I think if EBDA area is used in EFI system, it should be reserved in EFI
> memory map.

Realistically, we need the infrastructure to be able to make paranoia 
reservations, and you need to be able to deal with later finding they 
are actually in use.  That's part of why we *make* paranoia 
reservations.  It's not acceptable to say "oh, it's EFI, we don't need 
it" -- that's equivalent to saying "oh, EFI firmware won't have any 
bugs."  Although I know there are plenty of EFI fanboys who seem to have 
that idea, I consider it about as likely as the tooth fairy.

	-hpa

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

hpa wrote:
> Realistically, we need the infrastructure to be able to make paranoia 
> reservations, and you need to be able to deal with later finding they 
> are actually in use.

While the tone of your reply sounds like something I would naturally
agree with, I can't actually figure out what you mean in this case ;).

In particular, Peter, would you agree/disagree/other with the direction
that Huang and I agreed to last night:

> Would you recommend doing this with code in arch/x86/kernel/head.c,
> that did not invoke reserve_ebda_region() if efi_enabled was set?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[H. Peter Anvin]

Paul Jackson wrote:
> hpa wrote:
>> Realistically, we need the infrastructure to be able to make paranoia 
>> reservations, and you need to be able to deal with later finding they 
>> are actually in use.
> 
> While the tone of your reply sounds like something I would naturally
> agree with, I can't actually figure out what you mean in this case ;).
> 
> In particular, Peter, would you agree/disagree/other with the direction
> that Huang and I agreed to last night:
> 
>> Would you recommend doing this with code in arch/x86/kernel/head.c,
>> that did not invoke reserve_ebda_region() if efi_enabled was set?

I disagree with it, I do not consider it safe.  I think you have to 
consider the difference between a "safety reservation" and a "actual 
reservation", with the latter being allowed to overlap the former.

	-hpa

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

hpa, replying to pj:
> >> Would you recommend doing this with code in arch/x86/kernel/head.c,
> >> that did not invoke reserve_ebda_region() if efi_enabled was set?
> 
> I disagree with it

Ok - that's clear.

So it would seem that I am getting conflicting advice.

One person recommends code that only makes this safety reservation of
the ebda region in the non-EFI case:

    if (!efi_enabled)
	reserve_ebda_region();

and the other recommends code that always makes this safety reservation,
and that handles the possible resulting overlap with the EFI memmap:

    if (!range_in_ebda_area(pmap, pmap + memmap.nr_map * memmap.desc_size))
	reserve_early(pmap, pmap + memmap.nr_map * memmap.desc_size,
	    "EFI memmap");

(The above code should be adjusted in light of Yinghai's suggestion
that it handle partial overlap.)

The resolution of this conflict might be easy, however.

I will readily accept that there exist some 'classic' PCs for which
we need to reserve a 'safe' ebda area.

The question to me is this.  Are there PCs which (1) need such a safety
reservation of an ebda area -and- (2) boot with EFI enabled?  I am not
asking if there -could- be (in the abstract, there certainly is no law
of government or physics prohibiting such).  Rather I am asking as a
practical matter if there is, or is likely to be, such PCs "in the wild."

The safety reservation of this ebda area is a hack.  As hacks go, it is
a rather gentle hack, but still it is a hack.  As such, it is to be
avoided unless there is a practical need.  Some non-efi old PCs have that
need - no debate there.

Should we perpeturate this (gentle) hack for EFI systems as well?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Yinghai Lu]

On Mon, Jun 16, 2008 at 10:37 AM, Paul Jackson <pj@sgi.com> wrote:
> hpa, replying to pj:
>> >> Would you recommend doing this with code in arch/x86/kernel/head.c,
>> >> that did not invoke reserve_ebda_region() if efi_enabled was set?
>>
>> I disagree with it
>
> Ok - that's clear.
>
> So it would seem that I am getting conflicting advice.
>
> One person recommends code that only makes this safety reservation of
> the ebda region in the non-EFI case:
>
>    if (!efi_enabled)
>        reserve_ebda_region();
>
> and the other recommends code that always makes this safety reservation,
> and that handles the possible resulting overlap with the EFI memmap:
>
>    if (!range_in_ebda_area(pmap, pmap + memmap.nr_map * memmap.desc_size))
>        reserve_early(pmap, pmap + memmap.nr_map * memmap.desc_size,
>            "EFI memmap");
>
> (The above code should be adjusted in light of Yinghai's suggestion
> that it handle partial overlap.)
>
> The resolution of this conflict might be easy, however.
>
> I will readily accept that there exist some 'classic' PCs for which
> we need to reserve a 'safe' ebda area.
>
> The question to me is this.  Are there PCs which (1) need such a safety
> reservation of an ebda area -and- (2) boot with EFI enabled?  I am not
> asking if there -could- be (in the abstract, there certainly is no law
> of government or physics prohibiting such).  Rather I am asking as a
> practical matter if there is, or is likely to be, such PCs "in the wild."

like to see to make
reserve_ebda_region() more smart like the old way when andi introduced
ebda_size...
instead of reserve 0x9000 to 0x100000 all the way.

YH

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

Yinghai wrote:
> like to see to make reserve_ebda_region() more smart like the old
> way when andi introduced ebda_size... instead of reserve 0x9000 to
> 0x100000 all the way.

Looking back at some older kernels, that code seems to have setup an
ebda region only if there was a non-zero real mode pointer at 0x40E.

This is rather different than always setting up such a region.

I would hesitate myself to re-introduce that code, because I know
too little, and have no pressing need for it.

I will leave to others the desirability of such a change.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[H. Peter Anvin]

Paul Jackson wrote:
> Yinghai wrote:
>> like to see to make reserve_ebda_region() more smart like the old
>> way when andi introduced ebda_size... instead of reserve 0x9000 to
>> 0x100000 all the way.
> 
> Looking back at some older kernels, that code seems to have setup an
> ebda region only if there was a non-zero real mode pointer at 0x40E.
> 
> This is rather different than always setting up such a region.
> 

Well, sort of.  Only some very old systems will not have had one.

0x40E contains the pointer to the EBDA; this basically tests for the 
existence of an EBDA at all.

	-hpa

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Alan Cox]

On Mon, 16 Jun 2008 11:18:12 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> Paul Jackson wrote:
> > Yinghai wrote:
> >> like to see to make reserve_ebda_region() more smart like the old
> >> way when andi introduced ebda_size... instead of reserve 0x9000 to
> >> 0x100000 all the way.
> > 
> > Looking back at some older kernels, that code seems to have setup an
> > ebda region only if there was a non-zero real mode pointer at 0x40E.
> > 
> > This is rather different than always setting up such a region.
> > 
> 
> Well, sort of.  Only some very old systems will not have had one.
> 
> 0x40E contains the pointer to the EBDA; this basically tests for the 
> existence of an EBDA at all.

I'd disagree with the "very old". Machines without EBDA go right up to
the AMD Athlon era and maybe beyond that. My old dual Athlon box has no
EBDA.

Alan

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[H. Peter Anvin]

Alan Cox wrote:
>>
>> 0x40E contains the pointer to the EBDA; this basically tests for the 
>> existence of an EBDA at all.
> 
> I'd disagree with the "very old". Machines without EBDA go right up to
> the AMD Athlon era and maybe beyond that. My old dual Athlon box has no
> EBDA.
> 

Fair enough.

	-hpa

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[H. Peter Anvin]

Paul Jackson wrote:
> 
> The question to me is this.  Are there PCs which (1) need such a safety
> reservation of an ebda area -and- (2) boot with EFI enabled?  I am not
> asking if there -could- be (in the abstract, there certainly is no law
> of government or physics prohibiting such).  Rather I am asking as a
> practical matter if there is, or is likely to be, such PCs "in the wild."
> 
> The safety reservation of this ebda area is a hack.  As hacks go, it is
> a rather gentle hack, but still it is a hack.  As such, it is to be
> avoided unless there is a practical need.  Some non-efi old PCs have that
> need - no debate there.
> 
> Should we perpeturate this (gentle) hack for EFI systems as well?
> 

We *are* going to have similar hacks.  That's not a question.  At this 
point, the live pool of EFI systems is functionally zero, so it's 
pointless to try to draw conclusions from the live pool (the little I 
have heard about the incoming set of EFI machines make me think the 
problems we've had with BIOS will look like child's play compared to the 
EFI braindamages we'll have to suffer.)

Perpetuating this hack will cost a few kilobytes of memory on machines 
which may not care.  *Not* perpetuating may save a few kilobytes on 
machines which may cause odd behaviours that only are noticeable when 
you, say, boot from one OS into another.

Guess which option I think is saner.

	-hpa

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Paul Jackson]

hpa wrote:
> We *are* going to have similar hacks.  That's not a question.

I agree ;)  That's not the question.  I have no religious objection
to hacks.  I just try to keep their population in check.  In some
cases (PC BIOS and EFI come to mind ;) I am less successful than
in other cases.

> *Not* perpetuating may ... cause odd behaviours that only are
> noticeable when you, say, boot from one OS into another.

So I take it you are saying that the future permutations and, in this
case with nested boots, combinations are sufficiently diverse and
unpredictable that as a practical matter we should perpeturate this
(gentle) hack.

I'm fine with that.

Huang - would you agree to this safety reservation of the ebda area
even on EFI enabled systems?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 4/8] x86 boot: allow overlapping ebda and efi memmap memory ranges

[Huang, Ying]

On Mon, 2008-06-16 at 13:05 -0500, Paul Jackson wrote:
[...]
> Huang - would you agree to this safety reservation of the ebda area
> even on EFI enabled systems?

I am OK with this.

Best Regards,
Huang Ying

[PATCH 5/8] x86 boot: remap efi systab runtime from phys to virt

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

One more efi entry needs its address converted from physical
to virtual during boot: efi.systab->runtime.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/efi.c |    1 +
 1 file changed, 1 insertion(+)

--- linux.orig/arch/x86/kernel/efi.c	2008-06-13 00:53:10.053599898 -0700
+++ linux/arch/x86/kernel/efi.c	2008-06-13 00:53:21.762309008 -0700
@@ -486,6 +486,7 @@ void __init efi_enter_virtual_mode(void)
 		if (md->phys_addr <= systab && systab < end) {
 			systab += md->virt_addr - md->phys_addr;
 			efi.systab = (efi_system_table_t *) (unsigned long) systab;
+			efi.systab->runtime = __va(efi.systab->runtime);
 		}
 	}
 

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [PATCH 5/8] x86 boot: remap efi systab runtime from phys to virt

[Huang, Ying]

On Sun, 2008-06-15 at 23:30 -0700, Paul Jackson wrote:
> From: Paul Jackson <pj@sgi.com>
> 
> One more efi entry needs its address converted from physical
> to virtual during boot: efi.systab->runtime.
> 
> Signed-off-by: Paul Jackson <pj@sgi.com>
> 
> ---
>  arch/x86/kernel/efi.c |    1 +
>  1 file changed, 1 insertion(+)
> 
> --- linux.orig/arch/x86/kernel/efi.c	2008-06-13 00:53:10.053599898 -0700
> +++ linux/arch/x86/kernel/efi.c	2008-06-13 00:53:21.762309008 -0700
> @@ -486,6 +486,7 @@ void __init efi_enter_virtual_mode(void)
>  		if (md->phys_addr <= systab && systab < end) {
>  			systab += md->virt_addr - md->phys_addr;
>  			efi.systab = (efi_system_table_t *) (unsigned long) systab;
> +			efi.systab->runtime = __va(efi.systab->runtime);
>  		}
>  	}

Why do you need this? This should be done by firmware in
efi_set_virtual_address_map(). And this doesn't work on i386, because
runtime code/data area may be not in identity map area (that is > 768M).
even on x86_64, runtime code/data area can be non-identity mapped (For
example identity map is restricted by mem=xxx kernel parameter). Same
problem for

[PATCH 6/8] x86 boot: virtualize the efi runtime function callback
addresses

Best Regards,
Huang Ying

Re: [PATCH 5/8] x86 boot: remap efi systab runtime from phys to virt

[Paul Jackson]

Huang wrote:
> >  			efi.systab = (efi_system_table_t *) (unsigned long) systab;
> > +			efi.systab->runtime = __va(efi.systab->runtime);
> >  		}
> >  	}
> 
> Why do you need this?

I need this so that my kernel can callback into EFI runtime services
post-boot.


> This should be done by firmware in
> efi_set_virtual_address_map().

I don't understand this comment.  I don't see any routine named
'efi_set_virtual_address_map()' in the kernel.  I do see virt_*
and phys_* variants of that name; did you mean one of those?

In any case, I don't understand how this could "be done by firmware."
It is the kernel that is mapping in the firmware somehow to support EFI
runtime services.


> And this doesn't work on i386, because
> runtime code/data area may be not in identity map area (that is > 768M).

Ok ... what code should we add for i386?  Would it be code like I see
above in this efi_enter_virtual_mode() routine:

                if (PFN_UP(end) <= max_pfn_mapped)
                        va = __va(md->phys_addr);
                else
                        va = efi_ioremap(md->phys_addr, size);

I could write similar code for remapping efi.systab->runtime, but
I could not test such code -- could you assist me in that?

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

Re: [PATCH 5/8] x86 boot: remap efi systab runtime from phys to virt

[Huang, Ying]

On Mon, 2008-06-16 at 03:06 -0500, Paul Jackson wrote:
> Huang wrote:
> > >  			efi.systab = (efi_system_table_t *) (unsigned long) systab;
> > > +			efi.systab->runtime = __va(efi.systab->runtime);
> > >  		}
> > >  	}
> > 
> > Why do you need this?
> 
> I need this so that my kernel can callback into EFI runtime services
> post-boot.
> 
> 
> > This should be done by firmware in
> > efi_set_virtual_address_map().
> 
> I don't understand this comment.  I don't see any routine named
> 'efi_set_virtual_address_map()' in the kernel.  I do see virt_*
> and phys_* variants of that name; did you mean one of those?

I mean the EFI runtime service SetVirtualAddressMap() in spec.

> In any case, I don't understand how this could "be done by firmware."
> It is the kernel that is mapping in the firmware somehow to support EFI
> runtime services.

This should be done in firmware. That is, the EFI system table:
efi.systab and runtime services table: efi.systab->runtime) will be
updated in SetVirtualAddressMap() by firmware. This is specified in
UEFI2.1 spec: Unified Extensible Firmware Interface Specification,
section 7.4 Virtual Memory Services. If the firmware does not do that
for you, please report bug to firmware vendor.

Your patch makes Linux kernel doesn't work on machine with proper
firmware, because the effect is like __va(__va(phys_ptr)).

Best Regards,
Huang Ying

Re: [PATCH 5/8] x86 boot: remap efi systab runtime from phys to virt

[Paul Jackson]

Huang wrote:
> I mean the EFI runtime service SetVirtualAddressMap() in spec.

Now I understand your comment.  I will investigate this.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

[PATCH 6/8] x86 boot: virtualize the efi runtime function callback addresses

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

EFI runtime service calls are provided by the EFI firmware
during boot to the kernel as physical addresses.  They must
be mapped to virtual addresses when the running kernel
calls back down to these EFI service routines.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 include/asm-x86/efi.h |   14 +++++++-------
 1 file changed, 7 insertions(+), 7 deletions(-)

--- linux.orig/include/asm-x86/efi.h	2008-06-10 21:31:24.000000000 -0700
+++ linux/include/asm-x86/efi.h	2008-06-13 03:48:21.086399220 -0700
@@ -68,22 +68,22 @@ extern u64 efi_call6(void *fp, u64 arg1,
 		  (u64)(a4), (u64)(a5), (u64)(a6))
 
 #define efi_call_virt0(f)				\
-	efi_call0((void *)(efi.systab->runtime->f))
+	efi_call0((void *)__va(efi.systab->runtime->f))
 #define efi_call_virt1(f, a1)					\
-	efi_call1((void *)(efi.systab->runtime->f), (u64)(a1))
+	efi_call1((void *)__va(efi.systab->runtime->f), (u64)(a1))
 #define efi_call_virt2(f, a1, a2)					\
-	efi_call2((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2))
+	efi_call2((void *)__va(efi.systab->runtime->f), (u64)(a1), (u64)(a2))
 #define efi_call_virt3(f, a1, a2, a3)					\
-	efi_call3((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
+	efi_call3((void *)__va(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
 		  (u64)(a3))
 #define efi_call_virt4(f, a1, a2, a3, a4)				\
-	efi_call4((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
+	efi_call4((void *)__va(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
 		  (u64)(a3), (u64)(a4))
 #define efi_call_virt5(f, a1, a2, a3, a4, a5)				\
-	efi_call5((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
+	efi_call5((void *)__va(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
 		  (u64)(a3), (u64)(a4), (u64)(a5))
 #define efi_call_virt6(f, a1, a2, a3, a4, a5, a6)			\
-	efi_call6((void *)(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
+	efi_call6((void *)__va(efi.systab->runtime->f), (u64)(a1), (u64)(a2), \
 		  (u64)(a3), (u64)(a4), (u64)(a5), (u64)(a6))
 
 extern void *efi_ioremap(unsigned long addr, unsigned long size);

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

[PATCH 7/8] x86 boot: show pfn addresses in hex not decimal in some kernel info printks

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Page frame numbers (the portion of physical addresses above the low
order page offsets) are displayed in several kernel debug and info
prints in decimal, not hex.  Decimal addresse are unreadable.  Use hex.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 arch/x86/kernel/e820.c |    2 +-
 mm/page_alloc.c        |   12 ++++++------
 2 files changed, 7 insertions(+), 7 deletions(-)

--- linux.orig/arch/x86/kernel/e820.c	2008-06-15 21:51:59.643086905 -0700
+++ linux/arch/x86/kernel/e820.c	2008-06-15 21:51:59.787095630 -0700
@@ -816,7 +816,7 @@ unsigned long __init e820_end_of_ram(voi
 	if (last_pfn > end_user_pfn)
 		last_pfn = end_user_pfn;
 
-	printk(KERN_INFO "last_pfn = %lu max_arch_pfn = %lu\n",
+	printk(KERN_INFO "last_pfn = 0x%lx max_arch_pfn = 0x%lx\n",
 			 last_pfn, max_arch_pfn);
 	return last_pfn;
 }
--- linux.orig/mm/page_alloc.c	2008-06-15 21:51:56.890920168 -0700
+++ linux/mm/page_alloc.c	2008-06-15 21:57:04.525557420 -0700
@@ -529,7 +529,7 @@ static void __free_pages_ok(struct page 
 	int i;
 	int reserved = 0;
 
-	trace_mark(mm_page_free, "order %u pfn %lu",
+	trace_mark(mm_page_free, "order %u pfn 0x%lx",
 		order, page_to_pfn(page));
 
 	for (i = 0 ; i < (1 << order) ; ++i)
@@ -998,7 +998,7 @@ static void free_hot_cold_page(struct pa
 	struct per_cpu_pages *pcp;
 	unsigned long flags;
 
-	trace_mark(mm_page_free, "order %u pfn %lu", 0, page_to_pfn(page));
+	trace_mark(mm_page_free, "order %u pfn 0x%lx", 0, page_to_pfn(page));
 
 	if (PageAnon(page))
 		page->mapping = NULL;
@@ -1665,7 +1665,7 @@ nopage:
 	}
 got_pg:
 	if (page)
-		trace_mark(mm_page_alloc, "order %u pfn %lu", order,
+		trace_mark(mm_page_alloc, "order %u pfn 0x%lx", order,
 			   page_to_pfn(page));
 	return page;
 }
@@ -3546,7 +3546,7 @@ void __init add_active_range(unsigned in
 {
 	int i;
 
-	printk(KERN_DEBUG "Entering add_active_range(%d, %lu, %lu) "
+	printk(KERN_DEBUG "Entering add_active_range(%d, 0x%lx, 0x%lx) "
 			  "%d entries of %d used\n",
 			  nid, start_pfn, end_pfn,
 			  nr_nodemap_entries, MAX_ACTIVE_REGIONS);
@@ -3945,7 +3945,7 @@ void __init free_area_init_nodes(unsigne
 	for (i = 0; i < MAX_NR_ZONES; i++) {
 		if (i == ZONE_MOVABLE)
 			continue;
-		printk("  %-8s %8lu -> %8lu\n",
+		printk("  %-8s 0x%8lx -> 0x%8lx\n",
 				zone_names[i],
 				arch_zone_lowest_possible_pfn[i],
 				arch_zone_highest_possible_pfn[i]);
@@ -3961,7 +3961,7 @@ void __init free_area_init_nodes(unsigne
 	/* Print out the early_node_map[] */
 	printk("early_node_map[%d] active PFN ranges\n", nr_nodemap_entries);
 	for (i = 0; i < nr_nodemap_entries; i++)
-		printk("  %3d: %8lu -> %8lu\n", early_node_map[i].nid,
+		printk("  %3d: 0x%8lx -> 0x%8lx\n", early_node_map[i].nid,
 						early_node_map[i].start_pfn,
 						early_node_map[i].end_pfn);
 

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [PATCH 7/8] x86 boot: show pfn addresses in hex not decimal in some kernel info printks

[Yinghai Lu]

On Sun, Jun 15, 2008 at 11:30 PM, Paul Jackson <pj@sgi.com> wrote:
> From: Paul Jackson <pj@sgi.com>
>
> Page frame numbers (the portion of physical addresses above the low
> order page offsets) are displayed in several kernel debug and info
> prints in decimal, not hex.  Decimal addresse are unreadable.  Use hex.
>
> Signed-off-by: Paul Jackson <pj@sgi.com>
>
> ---
>  arch/x86/kernel/e820.c |    2 +-
>  mm/page_alloc.c        |   12 ++++++------
>  2 files changed, 7 insertions(+), 7 deletions(-)
>
> --- linux.orig/arch/x86/kernel/e820.c   2008-06-15 21:51:59.643086905 -0700
> +++ linux/arch/x86/kernel/e820.c        2008-06-15 21:51:59.787095630 -0700
> @@ -816,7 +816,7 @@ unsigned long __init e820_end_of_ram(voi
>        if (last_pfn > end_user_pfn)
>                last_pfn = end_user_pfn;
>
> -       printk(KERN_INFO "last_pfn = %lu max_arch_pfn = %lu\n",
> +       printk(KERN_INFO "last_pfn = 0x%lx max_arch_pfn = 0x%lx\n",
>                         last_pfn, max_arch_pfn);
>        return last_pfn;
>  }
> --- linux.orig/mm/page_alloc.c  2008-06-15 21:51:56.890920168 -0700
> +++ linux/mm/page_alloc.c       2008-06-15 21:57:04.525557420 -0700
> @@ -529,7 +529,7 @@ static void __free_pages_ok(struct page
>        int i;
>        int reserved = 0;
>
> -       trace_mark(mm_page_free, "order %u pfn %lu",
> +       trace_mark(mm_page_free, "order %u pfn 0x%lx",
>                order, page_to_pfn(page));
>
>        for (i = 0 ; i < (1 << order) ; ++i)
> @@ -998,7 +998,7 @@ static void free_hot_cold_page(struct pa
>        struct per_cpu_pages *pcp;
>        unsigned long flags;
>
> -       trace_mark(mm_page_free, "order %u pfn %lu", 0, page_to_pfn(page));
> +       trace_mark(mm_page_free, "order %u pfn 0x%lx", 0, page_to_pfn(page));
>
>        if (PageAnon(page))
>                page->mapping = NULL;
> @@ -1665,7 +1665,7 @@ nopage:
>        }
>  got_pg:
>        if (page)
> -               trace_mark(mm_page_alloc, "order %u pfn %lu", order,
> +               trace_mark(mm_page_alloc, "order %u pfn 0x%lx", order,
>                           page_to_pfn(page));
>        return page;
>  }
> @@ -3546,7 +3546,7 @@ void __init add_active_range(unsigned in
>  {
>        int i;
>
> -       printk(KERN_DEBUG "Entering add_active_range(%d, %lu, %lu) "
> +       printk(KERN_DEBUG "Entering add_active_range(%d, 0x%lx, 0x%lx) "
>                          "%d entries of %d used\n",
>                          nid, start_pfn, end_pfn,
>                          nr_nodemap_entries, MAX_ACTIVE_REGIONS);
> @@ -3945,7 +3945,7 @@ void __init free_area_init_nodes(unsigne
>        for (i = 0; i < MAX_NR_ZONES; i++) {
>                if (i == ZONE_MOVABLE)
>                        continue;
> -               printk("  %-8s %8lu -> %8lu\n",
> +               printk("  %-8s 0x%8lx -> 0x%8lx\n",
>                                zone_names[i],
>                                arch_zone_lowest_possible_pfn[i],
>                                arch_zone_highest_possible_pfn[i]);
> @@ -3961,7 +3961,7 @@ void __init free_area_init_nodes(unsigne
>        /* Print out the early_node_map[] */
>        printk("early_node_map[%d] active PFN ranges\n", nr_nodemap_entries);
>        for (i = 0; i < nr_nodemap_entries; i++)
> -               printk("  %3d: %8lu -> %8lu\n", early_node_map[i].nid,
> +               printk("  %3d: 0x%8lx -> 0x%8lx\n", early_node_map[i].nid,
>                                                early_node_map[i].start_pfn,
>                                                early_node_map[i].end_pfn);
>

wonder if we need 0x?

YH

Re: [PATCH 7/8] x86 boot: show pfn addresses in hex not decimal in some kernel info printks

[Paul Jackson]

Yinghai wrote:
> wonder if we need 0x?

It is not essential, but it seems like a good idea, to make it clear to
the reader that it is hex output, not decimal.  Especially since this
patch changes this from decimal to hex, we cannot count on some never
changing standard to help users disambiguate output.

Hex numbers that don't have A-F letters could be decimal numbers

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214

[PATCH 8/8] x86 boot: more consistently use type int for node ids

[Paul Jackson]

From: Paul Jackson <pj@sgi.com>

Everywhere I look, node id's are of type 'int', except in this one
case, which has 'unsigned long'.  Change this one to 'int' as well.
There is nothing special about the way this variable 'nid' is used in
this routine to justify using an unusual type here.

Signed-off-by: Paul Jackson <pj@sgi.com>

---
 mm/page_alloc.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- linux.orig/mm/page_alloc.c	2008-06-15 21:43:46.109185357 -0700
+++ linux/mm/page_alloc.c	2008-06-15 21:43:49.753406159 -0700
@@ -3678,7 +3678,7 @@ static void __init sort_node_map(void)
 }
 
 /* Find the lowest pfn for a node */
-unsigned long __init find_min_pfn_for_node(unsigned long nid)
+unsigned long __init find_min_pfn_for_node(int nid)
 {
 	int i;
 	unsigned long min_pfn = ULONG_MAX;
@@ -3689,7 +3689,7 @@ unsigned long __init find_min_pfn_for_no
 
 	if (min_pfn == ULONG_MAX) {
 		printk(KERN_WARNING
-			"Could not find start_pfn for node %lu\n", nid);
+			"Could not find start_pfn for node %d\n", nid);
 		return 0;
 	}
 

-- 
                          I won't rest till it's the best ...
                          Programmer, Linux Scalability
                          Paul Jackson <pj@sgi.com> 1.650.933.1373

Re: [PATCH 1/8] x86 boot: x86_64 build reserve_bootmem_generic fix

[Yinghai Lu]

On Sun, Jun 15, 2008 at 11:29 PM, Paul Jackson <pj@sgi.com> wrote:
> From: Paul Jackson <pj@sgi.com>
>
> Fix x86_64 build.  The addition of a third 'flags' argument
> to reserve_bootmem() and similar routines missed one instance.
>
> Signed-off-by: Paul Jackson <pj@sgi.com>
>
> ---
>  arch/x86/kernel/e820.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> --- linux.orig/arch/x86/kernel/e820.c   2008-06-10 21:31:21.000000000 -0700
> +++ linux/arch/x86/kernel/e820.c        2008-06-10 22:37:27.256448098 -0700
> @@ -636,7 +636,8 @@ void __init early_res_to_bootmem(u64 sta
>                printk(KERN_INFO "  early res: %d [%llx-%llx] %s\n", i,
>                        final_start, final_end - 1, r->name);
>  #ifdef CONFIG_X86_64
> -               reserve_bootmem_generic(final_start, final_end - final_start);
> +               reserve_bootmem_generic(final_start, final_end - final_start,
> +                               BOOTMEM_DEFAULT);
>  #else
>                reserve_bootmem(final_start, final_end - final_start,
>                                BOOTMEM_DEFAULT);
>
> --

can you check latest tip/master?

YH

Re: [PATCH 1/8] x86 boot: x86_64 build reserve_bootmem_generic fix

[Paul Jackson]

Yinghai wrote:
> can you check latest tip/master?

Ok - I suppose you mean tip/master in the linux-next tree.

I see there a slightly different writing of this code,
that does not need this fix.  Good.

I guess this current patch of mine should be dropped then,
as it is no longer needed.

Thanks.

-- 
                  I won't rest till it's the best ...
                  Programmer, Linux Scalability
                  Paul Jackson <pj@sgi.com> 1.940.382.4214