Limit E820 map when specifying mem parameter

Limit E820 map when specifying mem parameter

[Bernhard Walle]

This patch modifies the E820 map when specifying the mem kernel command line
parameter. That's the behaviour i386 had before the merging work in the
current "tip" tree.

As Yinghai Lu pointed out in email discussion, e820_update_range() should be
used for the updating instead of an own function. Two modifications in
e820_update_range() are necessary:

 1. Fix a small bug that prevented the partically covered entry from
    being stripped (size is not updated).
 
 2. Small API extension to be able to specify size == ULLONG_MAX to 
    update the whole map from size to the end.

The modification is necessary that kexec can build the ELF core headers only
for the used memory. Once the exporting of the real, unmodified memory map is
in the kernel, kexec can use the raw map and still reboot with full memory
size.

The patch is against 2.6.26-rc7-tip and has been successfully tested on i386
and x86-64, with and without "mem" parameter.

[PATCH 1/3] e820_update_range(): Strip size of original region

[Bernhard Walle]

This patch fixes a bug in e820_update_range(): Previously, if a region was
partially covered, then e820_update_range() only added a new E820 range but
didn't update the end/size of the previous range. That lead to duplicate
covering of a region.

Patch tested on i386 and x86-64 with patch that uses e820_update_range()
to limit the E820 map when "mem" parameter is specified on the command line.


Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
 arch/x86/kernel/e820.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index e285ea3..e466073 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -422,6 +422,7 @@ u64 __init e820_update_range(u64 start, u64 size, unsigned old_type,
 		final_end = min(start + size, ei->addr + ei->size);
 		if (final_start >= final_end)
 			continue;
+		ei->size -= final_end - final_start;
 		e820_add_region(final_start, final_end - final_start,
 					 new_type);
 		real_updated_size += final_end - final_start;
-- 
1.5.4.5

Re: [PATCH 1/3] e820_update_range(): Strip size of original region

[Yinghai Lu]

On Wed, Jun 25, 2008 at 5:02 AM, Bernhard Walle <bwalle@suse.de> wrote:
> This patch fixes a bug in e820_update_range(): Previously, if a region was
> partially covered, then e820_update_range() only added a new E820 range but
> didn't update the end/size of the previous range. That lead to duplicate
> covering of a region.
>
> Patch tested on i386 and x86-64 with patch that uses e820_update_range()
> to limit the E820 map when "mem" parameter is specified on the command line.
>
>
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> ---
>  arch/x86/kernel/e820.c |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index e285ea3..e466073 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -422,6 +422,7 @@ u64 __init e820_update_range(u64 start, u64 size, unsigned old_type,
>                final_end = min(start + size, ei->addr + ei->size);
>                if (final_start >= final_end)
>                        continue;
> +               ei->size -= final_end - final_start;
>                e820_add_region(final_start, final_end - final_start,
>                                         new_type);
>                real_updated_size += final_end - final_start;
> --

this one is not needed, I sent one updated to Ingo, and it is in
tip/setup-memory
[PATCH] x86: change size if e820_update/remove_range

YH

[PATCH 2/3] e820_update_range(): Allow specifying ULLONG_MAX

[Bernhard Walle]

Allow the specifying of ULLONG_MAX to limit the whole E820 map from the
specified start to the end. Without the patch, there would be integer
overflows.


Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
 arch/x86/kernel/e820.c |   11 +++++++++--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index e466073..7d1109b 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -397,6 +397,9 @@ int __init copy_e820_map(struct e820entry *biosmap, int nr_map)
 	return __copy_e820_map(biosmap, nr_map);
 }
 
+/*
+ * Pass size == ULLONG_MAX to update until the end.
+ */
 u64 __init e820_update_range(u64 start, u64 size, unsigned old_type,
 				unsigned new_type)
 {
@@ -412,14 +415,18 @@ u64 __init e820_update_range(u64 start, u64 size, unsigned old_type,
 			continue;
 		/* totally covered? */
 		if (ei->addr >= start &&
-		    (ei->addr + ei->size) <= (start + size)) {
+		    (((ei->addr + ei->size) <= (start + size)) ||
+			    (size == ULLONG_MAX))) {
 			ei->type = new_type;
 			real_updated_size += ei->size;
 			continue;
 		}
 		/* partially covered */
 		final_start = max(start, ei->addr);
-		final_end = min(start + size, ei->addr + ei->size);
+		if (size == ULLONG_MAX)
+			final_end = ei->addr + ei->size;
+		else
+			final_end = min(start + size, ei->addr + ei->size);
 		if (final_start >= final_end)
 			continue;
 		ei->size -= final_end - final_start;
-- 
1.5.4.5

[PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

This patch brings back limiting of the E820 map when a user-defined
E820 map is specified. While the behaviour of i386 (32 bit) was to limit
the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
limit.

That patch limits the E820 map again for both x86 architectures.

Code was tested for compilation and booting on a 32 bit and 64 bit system.


Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
 arch/x86/kernel/e820.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7d1109b..19b7f05 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -979,6 +979,8 @@ static int __init parse_memopt(char *p)
 
 	mem_size = memparse(p, &p);
 	end_user_pfn = mem_size>>PAGE_SHIFT;
+	e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
+
 	return 0;
 }
 early_param("mem", parse_memopt);
@@ -1023,6 +1025,7 @@ static int __init parse_memmap_opt(char *p)
 		e820_add_region(start_at, mem_size, E820_RESERVED);
 	} else {
 		end_user_pfn = (mem_size >> PAGE_SHIFT);
+		e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
 	}
 	return *p == '\0' ? 0 : -EINVAL;
 }
-- 
1.5.4.5

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Yinghai Lu]

On Wed, Jun 25, 2008 at 5:02 AM, Bernhard Walle <bwalle@suse.de> wrote:
> This patch brings back limiting of the E820 map when a user-defined
> E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> limit.
>
> That patch limits the E820 map again for both x86 architectures.
>
> Code was tested for compilation and booting on a 32 bit and 64 bit system.
>
>
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> ---
>  arch/x86/kernel/e820.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index 7d1109b..19b7f05 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -979,6 +979,8 @@ static int __init parse_memopt(char *p)
>
>        mem_size = memparse(p, &p);
>        end_user_pfn = mem_size>>PAGE_SHIFT;
> +       e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
> +
>        return 0;
>  }
>  early_param("mem", parse_memopt);
> @@ -1023,6 +1025,7 @@ static int __init parse_memmap_opt(char *p)
>                e820_add_region(start_at, mem_size, E820_RESERVED);
>        } else {
>                end_user_pfn = (mem_size >> PAGE_SHIFT);
> +               e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
>        }
>        return *p == '\0' ? 0 : -EINVAL;
>  }
> --

only this one is needed now. but please change ULLONG_MAX to
ULLONG_MAX - mem_size

YH

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

* Yinghai Lu [2008-06-25 09:01]:
> On Wed, Jun 25, 2008 at 5:02 AM, Bernhard Walle <bwalle@suse.de> wrote:
> >  }
> >  early_param("mem", parse_memopt);
> > @@ -1023,6 +1025,7 @@ static int __init parse_memmap_opt(char *p)
> >                e820_add_region(start_at, mem_size, E820_RESERVED);
> >        } else {
> >                end_user_pfn = (mem_size >> PAGE_SHIFT);
> > +               e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
> >        }
> >        return *p == '\0' ? 0 : -EINVAL;
> >  }
> > --
> 
> only this one is needed now. but please change ULLONG_MAX to
> ULLONG_MAX - mem_size

Why can't we add that check at the beginning of e820_update_range() as
you suggested?


Bernhard

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Yinghai Lu]

On Wed, Jun 25, 2008 at 9:03 AM, Bernhard Walle <bwalle@suse.de> wrote:
> * Yinghai Lu [2008-06-25 09:01]:
>> On Wed, Jun 25, 2008 at 5:02 AM, Bernhard Walle <bwalle@suse.de> wrote:
>> >  }
>> >  early_param("mem", parse_memopt);
>> > @@ -1023,6 +1025,7 @@ static int __init parse_memmap_opt(char *p)
>> >                e820_add_region(start_at, mem_size, E820_RESERVED);
>> >        } else {
>> >                end_user_pfn = (mem_size >> PAGE_SHIFT);
>> > +               e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
>> >        }
>> >        return *p == '\0' ? 0 : -EINVAL;
>> >  }
>> > --
>>
>> only this one is needed now. but please change ULLONG_MAX to
>> ULLONG_MAX - mem_size
>
> Why can't we add that check at the beginning of e820_update_range() as
> you suggested?
that patch about fixing e820_update_rang is in tip/setup-memory.

so the one is supposed to be ok, but it is good to keep good input
parameter too.

YH

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

* "Yinghai Lu" <yhlu.kernel@gmail.com> [2008-06-25 09:58]:
> On Wed, Jun 25, 2008 at 9:03 AM, Bernhard Walle <bwalle@suse.de> wrote:
> >> only this one is needed now. but please change ULLONG_MAX to
> >> ULLONG_MAX - mem_size
> >
> > Why can't we add that check at the beginning of e820_update_range() as
> > you suggested?
> that patch about fixing e820_update_rang is in tip/setup-memory.
> 
> so the one is supposed to be ok, but it is good to keep good input
> parameter too.

Okay, thanks for review and comments. Patch sent.



Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

Limit E820 map when specifying mem parameter

[Bernhard Walle]

This patch modifies the E820 map when specifying the mem kernel command line
parameter. That's the behaviour i386 had before the merging work in the
current "tip" tree.

As Yinghai Lu pointed out in email discussion, e820_update_range() should be
used for the updating instead of an own function. Two modifications in
e820_update_range() are necessary:

 1. Fix a small bug that prevented the partically covered entry from
    being stripped (size is not updated).
 
 2. Small API extension to be able to specify size == ULLONG_MAX to 
    update the whole map from size to the end.

The modification is necessary that kexec can build the ELF core headers only
for the used memory. Once the exporting of the real, unmodified memory map is
in the kernel, kexec can use the raw map and still reboot with full memory
size.

The patch is against 2.6.26-rc7-tip and has been successfully tested on i386
and x86-64, with and without "mem" parameter.


Signed-off-by: Bernhard Walle <bwalle@suse.de>

[PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

This patch brings back limiting of the E820 map when a user-defined
E820 map is specified. While the behaviour of i386 (32 bit) was to limit
the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
limit.

That patch limits the E820 map again for both x86 architectures.

Code was tested for compilation and booting on a 32 bit and 64 bit system.


Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
 arch/x86/kernel/e820.c |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 7d1109b..19b7f05 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -979,6 +979,8 @@ static int __init parse_memopt(char *p)
 
 	mem_size = memparse(p, &p);
 	end_user_pfn = mem_size>>PAGE_SHIFT;
+	e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
+
 	return 0;
 }
 early_param("mem", parse_memopt);
@@ -1023,6 +1025,7 @@ static int __init parse_memmap_opt(char *p)
 		e820_add_region(start_at, mem_size, E820_RESERVED);
 	} else {
 		end_user_pfn = (mem_size >> PAGE_SHIFT);
+		e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
 	}
 	return *p == '\0' ? 0 : -EINVAL;
 }
-- 
1.5.4.5

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Yinghai Lu]

On Tue, Jun 24, 2008 at 7:35 AM, Bernhard Walle <bwalle@suse.de> wrote:
> This patch brings back limiting of the E820 map when a user-defined
> E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> limit.
>
> That patch limits the E820 map again for both x86 architectures.
>
> Code was tested for compilation and booting on a 32 bit and 64 bit system.
>
>
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> ---
>  arch/x86/kernel/e820.c |    3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index 7d1109b..19b7f05 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -979,6 +979,8 @@ static int __init parse_memopt(char *p)
>
>        mem_size = memparse(p, &p);
>        end_user_pfn = mem_size>>PAGE_SHIFT;
> +       e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
==>
+       e820_update_range(mem_size, ULLONG_MAX - mem_size, E820_RAM,
E820_RESERVED);
> +
>        return 0;
>  }
>  early_param("mem", parse_memopt);
> @@ -1023,6 +1025,7 @@ static int __init parse_memmap_opt(char *p)
>                e820_add_region(start_at, mem_size, E820_RESERVED);
>        } else {
>                end_user_pfn = (mem_size >> PAGE_SHIFT);
> +               e820_update_range(mem_size, ULLONG_MAX, E820_RAM, E820_RESERVED);
==>
+       e820_update_range(mem_size, ULLONG_MAX - mem_size, E820_RAM,
E820_RESERVED);

YH

Introduce userspace interface for Firmware-provided memory map

[Bernhard Walle]

This patch (as request for comments) introduces a new userspace interface
/proc/firmware_mem that provides the unfiltered view of the BIOS on
memory configuration. That's usable for two reasons:

 1) Debugging (yes, the E820 memory is printed in kernel ring buffer, but that's
    not the case for all platforms, on IA64 you have to enable some magic define
    to print the EFI memory map, for example),
 
 2) Kexec. When the user or the system uses a special command line to modify the
    memory configuration, kexec still needs a method to get the original memory
    map.  While the filtered view is useful for generating ELF core headers for
    crashdumps, the unfiltered view is necessary to boot the next kernel without
    the "limitations" the original kernel has.

We had the discussion to add iomem_used on kexec mailing list. However, I think
it's better to let /proc/iomem represent the *filtered* (i.e. "used") view of
the I/O resources and introduce a new interface for the *unfiltered* view.
There are two reasons:

 1) On i386 (the oldest architectures), /proc/iomem always represented the
    *filtered* view (i.e. "mem" parameter was also visible in /proc/iomem).
    I think we should not change the semantics of an interface without a reason.
 
 2) /proc/iomem_used would it make necessary to duplicate all registration between
    /proc/iomem and /proc/iomem_used. Because currently the resource root
    is exported and used everywhere in the kernel source, that would make
    changes of the whole resource infrastructure necessary if code duplication
    should be avoided.

Maybe you think that /proc/firmware_mem is not the right place to export that.
I don't know, I also don't care that much about the naming or the way to export
that. So, please advise me if you agree that it's ok for kexec to export an
unfiltered view of the memory map.

The patch has been tested on i386 and x86_64.



Signed-off-by: Bernhard Walle <bwalle@suse.de>

[PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

This patch brings back limiting of the E820 map when a user-defined
E820 map is specified. While the behaviour of i386 (32 bit) was to limit
the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
limit.

That patch limits the E820 map again for both x86 architectures.

Code was tested for compilation and booting on a 32 bit and 64 bit system.


Signed-off-by: Bernhard Walle <bwalle@suse.de>
---
 arch/x86/kernel/e820.c |   30 ++++++++++++++++++++++++++++++
 1 files changed, 30 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index f5b1736..2e7d385 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -934,6 +934,33 @@ static void early_panic(char *msg)
 	panic(msg);
 }
 
+void __init e820_limit_regions(unsigned long long size)
+{
+	unsigned long long current_addr;
+	int i;
+
+	for (i = 0; i < e820.nr_map; i++) {
+		current_addr = e820.map[i].addr + e820.map[i].size;
+		if (current_addr < size)
+			continue;
+
+		if (e820.map[i].type != E820_RAM)
+			continue;
+
+		if (e820.map[i].addr >= size) {
+			/*
+			 * This region starts past the end of the
+			 * requested size, skip it completely.
+			 */
+			e820.nr_map = i;
+		} else {
+			e820.nr_map = i + 1;
+			e820.map[i].size -= current_addr - size;
+		}
+		return;
+	}
+}
+
 /* "mem=nopentium" disables the 4MB page tables. */
 static int __init parse_memopt(char *p)
 {
@@ -951,6 +978,8 @@ static int __init parse_memopt(char *p)
 
 	mem_size = memparse(p, &p);
 	end_user_pfn = mem_size>>PAGE_SHIFT;
+	e820_limit_regions(mem_size);
+
 	return 0;
 }
 early_param("mem", parse_memopt);
@@ -995,6 +1024,7 @@ static int __init parse_memmap_opt(char *p)
 		e820_add_region(start_at, mem_size, E820_RESERVED);
 	} else {
 		end_user_pfn = (mem_size >> PAGE_SHIFT);
+		e820_limit_regions(mem_size);
 	}
 	return *p == '\0' ? 0 : -EINVAL;
 }
-- 
1.5.4.5

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Vivek Goyal]

On Fri, Jun 20, 2008 at 05:57:00PM +0200, Bernhard Walle wrote:
> This patch brings back limiting of the E820 map when a user-defined
> E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> limit.
> 
> That patch limits the E820 map again for both x86 architectures.
> 
> Code was tested for compilation and booting on a 32 bit and 64 bit system.
> 
> 
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> ---
>  arch/x86/kernel/e820.c |   30 ++++++++++++++++++++++++++++++
>  1 files changed, 30 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index f5b1736..2e7d385 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -934,6 +934,33 @@ static void early_panic(char *msg)
>  	panic(msg);
>  }
>  
> +void __init e820_limit_regions(unsigned long long size)
> +{
> +	unsigned long long current_addr;
> +	int i;
> +
> +	for (i = 0; i < e820.nr_map; i++) {
> +		current_addr = e820.map[i].addr + e820.map[i].size;
> +		if (current_addr < size)
> +			continue;
> +
> +		if (e820.map[i].type != E820_RAM)
> +			continue;
> +
> +		if (e820.map[i].addr >= size) {
> +			/*
> +			 * This region starts past the end of the
> +			 * requested size, skip it completely.
> +			 */
> +			e820.nr_map = i;
> +		} else {
> +			e820.nr_map = i + 1;
> +			e820.map[i].size -= current_addr - size;
> +		}
> +		return;
> +	}
> +}
> +
>  /* "mem=nopentium" disables the 4MB page tables. */
>  static int __init parse_memopt(char *p)
>  {
> @@ -951,6 +978,8 @@ static int __init parse_memopt(char *p)
>  
>  	mem_size = memparse(p, &p);
>  	end_user_pfn = mem_size>>PAGE_SHIFT;
> +	e820_limit_regions(mem_size);
> +
>  	return 0;
>  }
>  early_param("mem", parse_memopt);
> @@ -995,6 +1024,7 @@ static int __init parse_memmap_opt(char *p)
>  		e820_add_region(start_at, mem_size, E820_RESERVED);
>  	} else {
>  		end_user_pfn = (mem_size >> PAGE_SHIFT);
> +		e820_limit_regions(mem_size);
>  	}

Hi Bernhard,

Just curious, when do we hit this bottom else condition?

In Documentation/kernel-parameters.txt file, I see, there are four
types of memmap= options. "exactmap" "@" "#" and "$". In the code
above we have already parsed all these option. So default condition
should be an error. Instead we seem to be limiting the memory size,
(something done by mem= parameter)..

Thanks
Vivek

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Yinghai Lu]

On Fri, Jun 20, 2008 at 8:57 AM, Bernhard Walle <bwalle@suse.de> wrote:
> This patch brings back limiting of the E820 map when a user-defined
> E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> limit.

then if you kexec new kernel, the second kernel will be have that
limitation too.

any problem that you encountered without this patch?

YH

>
> That patch limits the E820 map again for both x86 architectures.
>
> Code was tested for compilation and booting on a 32 bit and 64 bit system.
>
>
> Signed-off-by: Bernhard Walle <bwalle@suse.de>
> ---
>  arch/x86/kernel/e820.c |   30 ++++++++++++++++++++++++++++++
>  1 files changed, 30 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
> index f5b1736..2e7d385 100644
> --- a/arch/x86/kernel/e820.c
> +++ b/arch/x86/kernel/e820.c
> @@ -934,6 +934,33 @@ static void early_panic(char *msg)
>        panic(msg);
>  }
>
> +void __init e820_limit_regions(unsigned long long size)
> +{
> +       unsigned long long current_addr;
> +       int i;
> +
> +       for (i = 0; i < e820.nr_map; i++) {
> +               current_addr = e820.map[i].addr + e820.map[i].size;
> +               if (current_addr < size)
> +                       continue;
> +
> +               if (e820.map[i].type != E820_RAM)
> +                       continue;
> +
> +               if (e820.map[i].addr >= size) {
> +                       /*
> +                        * This region starts past the end of the
> +                        * requested size, skip it completely.
> +                        */
> +                       e820.nr_map = i;
> +               } else {
> +                       e820.nr_map = i + 1;
> +                       e820.map[i].size -= current_addr - size;
> +               }
> +               return;
> +       }
> +}
> +
>  /* "mem=nopentium" disables the 4MB page tables. */
>  static int __init parse_memopt(char *p)
>  {
> @@ -951,6 +978,8 @@ static int __init parse_memopt(char *p)
>
>        mem_size = memparse(p, &p);
>        end_user_pfn = mem_size>>PAGE_SHIFT;
> +       e820_limit_regions(mem_size);
> +
>        return 0;
>  }
>  early_param("mem", parse_memopt);
> @@ -995,6 +1024,7 @@ static int __init parse_memmap_opt(char *p)
>                e820_add_region(start_at, mem_size, E820_RESERVED);
>        } else {
>                end_user_pfn = (mem_size >> PAGE_SHIFT);
> +               e820_limit_regions(mem_size);
>        }
>        return *p == '\0' ? 0 : -EINVAL;
>  }
> --
> 1.5.4.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

* "Yinghai Lu" <yhlu.kernel@gmail.com> [2008-06-20 13:34]:
>
> On Fri, Jun 20, 2008 at 8:57 AM, Bernhard Walle <bwalle@suse.de> wrote:
> > This patch brings back limiting of the E820 map when a user-defined
> > E820 map is specified. While the behaviour of i386 (32 bit) was to limit
> > the E820 map (and /proc/iomem), the behaviour of x86-64 (64 bit) was not to
> > limit.
> 
> then if you kexec new kernel, the second kernel will be have that
> limitation too.
> 
> any problem that you encountered without this patch?

No, because the new kexec tool uses the /proc/firmware_mem or whatever
it is called.



Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

* "Yinghai Lu" <yhlu.kernel@gmail.com> [2008-06-20 13:34]:
> 
> any problem that you encountered without this patch?

Sorry, forgot to answer that question.

Yes, if you use mem=3G and take a dump, kexec builds the ELF core
headers for the full memory size, which means that the dump is as large
as the physical memory of the machine is, which doesn't make sense.



Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Yinghai Lu]

On Sun, Jun 22, 2008 at 12:56 PM, Bernhard Walle <bwalle@suse.de> wrote:
> * "Yinghai Lu" <yhlu.kernel@gmail.com> [2008-06-20 13:34]:
>>
>> any problem that you encountered without this patch?
>
> Sorry, forgot to answer that question.
>
> Yes, if you use mem=3G and take a dump, kexec builds the ELF core
> headers for the full memory size, which means that the dump is as large
> as the physical memory of the machine is, which doesn't make sense.

can we use e820_update_range instead? so e820_setup_gap still can get
correct value?

YH

Re: [PATCH 3/3] Limit E820 map when a user-defined memory map is specified

[Bernhard Walle]

* Yinghai Lu [2008-06-22 13:11]:
>
> On Sun, Jun 22, 2008 at 12:56 PM, Bernhard Walle <bwalle@suse.de> wrote:
> > * "Yinghai Lu" <yhlu.kernel@gmail.com> [2008-06-20 13:34]:
> >>
> >> any problem that you encountered without this patch?
> >
> > Sorry, forgot to answer that question.
> >
> > Yes, if you use mem=3G and take a dump, kexec builds the ELF core
> > headers for the full memory size, which means that the dump is as large
> > as the physical memory of the machine is, which doesn't make sense.
> 
> can we use e820_update_range instead? so e820_setup_gap still can get
> correct value?

Yes, good idea. Patch is in the queue ...


Bernhard
-- 
Bernhard Walle, SUSE LINUX Products GmbH, Architecture Development