Patchwork [168/270] x86: Exclude E820_RESERVED regions and memory holes above 4 GB from direct mapping.

login
register
mail settings
Submitter Herton Ronaldo Krzesinski
Date Nov. 26, 2012, 4:57 p.m.
Message ID <1353949160-26803-169-git-send-email-herton.krzesinski@canonical.com>
Download mbox | patch
Permalink /patch/201901/
State New
Headers show

Comments

Herton Ronaldo Krzesinski - Nov. 26, 2012, 4:57 p.m.
3.5.7u1 -stable review patch.  If anyone has any objections, please let me know.

------------------

From: Jacob Shin <jacob.shin@amd.com>

commit 1bbbbe779aabe1f0768c2bf8f8c0a5583679b54a upstream.

On systems with very large memory (1 TB in our case), BIOS may report a
reserved region or a hole in the E820 map, even above the 4 GB range. Exclude
these from the direct mapping.

[ hpa: this should be done not just for > 4 GB but for everything above the legacy
  region (1 MB), at the very least.  That, however, turns out to require significant
  restructuring.  That work is well underway, but is not suitable for rc/stable. ]

Signed-off-by: Jacob Shin <jacob.shin@amd.com>
Link: http://lkml.kernel.org/r/1319145326-13902-1-git-send-email-jacob.shin@amd.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
---
 arch/x86/kernel/setup.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)
H. Peter Anvin - Nov. 26, 2012, 6:02 p.m.
On 11/26/2012 08:57 AM, Herton Ronaldo Krzesinski wrote:
> 3.5.7u1 -stable review patch.  If anyone has any objections, please let me know.

What kind of version number is that?

	-hpa
Herton Ronaldo Krzesinski - Nov. 26, 2012, 8:08 p.m.
On Mon, Nov 26, 2012 at 10:02:09AM -0800, H. Peter Anvin wrote:
> On 11/26/2012 08:57 AM, Herton Ronaldo Krzesinski wrote:
> > 3.5.7u1 -stable review patch.  If anyone has any objections, please let me know.
> 
> What kind of version number is that?

This is an "extended stable" tree, a fork from the last 3.5 stable
update (3.5 isn't maintained anymore by stable upstream). Thus
it seemed better to just follow last released 3.5 stable version, and
append an extraversion to it, which I chose in the end to be u<n>
(u == update). It's unlikely that other 3.5 stable upstream update will
be done, in any case I expect this way to avoid any issue.

> 
> 	-hpa
> 
>
H. Peter Anvin - Nov. 26, 2012, 8:09 p.m.
On 11/26/2012 12:08 PM, Herton Ronaldo Krzesinski wrote:
> On Mon, Nov 26, 2012 at 10:02:09AM -0800, H. Peter Anvin wrote:
>> On 11/26/2012 08:57 AM, Herton Ronaldo Krzesinski wrote:
>>> 3.5.7u1 -stable review patch.  If anyone has any objections, please let me know.
>>
>> What kind of version number is that?
> 
> This is an "extended stable" tree, a fork from the last 3.5 stable
> update (3.5 isn't maintained anymore by stable upstream). Thus
> it seemed better to just follow last released 3.5 stable version, and
> append an extraversion to it, which I chose in the end to be u<n>
> (u == update). It's unlikely that other 3.5 stable upstream update will
> be done, in any case I expect this way to avoid any issue.
> 

Why not 3.5.7.1 sticking with the pre-established version numbering scheme?

	-hpa
Herton Ronaldo Krzesinski - Nov. 26, 2012, 8:18 p.m.
On Mon, Nov 26, 2012 at 12:09:52PM -0800, H. Peter Anvin wrote:
> On 11/26/2012 12:08 PM, Herton Ronaldo Krzesinski wrote:
> > On Mon, Nov 26, 2012 at 10:02:09AM -0800, H. Peter Anvin wrote:
> >> On 11/26/2012 08:57 AM, Herton Ronaldo Krzesinski wrote:
> >>> 3.5.7u1 -stable review patch.  If anyone has any objections, please let me know.
> >>
> >> What kind of version number is that?
> > 
> > This is an "extended stable" tree, a fork from the last 3.5 stable
> > update (3.5 isn't maintained anymore by stable upstream). Thus
> > it seemed better to just follow last released 3.5 stable version, and
> > append an extraversion to it, which I chose in the end to be u<n>
> > (u == update). It's unlikely that other 3.5 stable upstream update will
> > be done, in any case I expect this way to avoid any issue.
> > 
> 
> Why not 3.5.7.1 sticking with the pre-established version numbering scheme?

That looks better indeed. Since this is the first release, I'll turn it
this way.

> 
> 	-hpa
> 
>

Patch

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 16be6dc..e615c31 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -919,8 +919,21 @@  void __init setup_arch(char **cmdline_p)
 
 #ifdef CONFIG_X86_64
 	if (max_pfn > max_low_pfn) {
-		max_pfn_mapped = init_memory_mapping(1UL<<32,
-						     max_pfn<<PAGE_SHIFT);
+		int i;
+		for (i = 0; i < e820.nr_map; i++) {
+			struct e820entry *ei = &e820.map[i];
+
+			if (ei->addr + ei->size <= 1UL << 32)
+				continue;
+
+			if (ei->type == E820_RESERVED)
+				continue;
+
+			max_pfn_mapped = init_memory_mapping(
+				ei->addr < 1UL << 32 ? 1UL << 32 : ei->addr,
+				ei->addr + ei->size);
+		}
+
 		/* can we preseve max_low_pfn ?*/
 		max_low_pfn = max_pfn;
 	}