public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Hurley <peter@hurleysoftware.com>
To: Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	"x86@kernel.org" <x86@kernel.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Zhenzhong Duan <zhenzhong.duan@oracle.com>
Subject: [RFC] x86: mtrr: Constrain WB MTRR to max phys mem prior to cleanup
Date: Fri, 7 Sep 2012 13:44:14 -0400	[thread overview]
Message-ID: <1347039854.6288.8.camel@thor> (raw)

If BIOS maps all or most of the phys address space as write-back,
regardless of the amount of actual RAM, then mtrr_cleanup may create
superfluous MTRR entries, or may be unable to create an optimal map
(or may use all MTRRs attempting to do so, thus making cleanup
pointless). Ideally, WB MTRRs should not be used for physical memory
addresses where memory does not exist (Intel SDM, Vol 3A, 11.11.2.1).

For example, Dell Precision T5400 wkstn w/ rev. A04 BIOS constructs
the following MTRR map for 10GB memory:
 kernel: [    0.000000] MTRR variable ranges enabled:
 kernel: [    0.000000]   0 base 0000000000 mask 2000000000 write-back
 kernel: [    0.000000]   1 base 00CFF00000 mask 3FFFF00000 uncachable
 kernel: [    0.000000]   2 base 00D0000000 mask 3FF0000000 uncachable
 kernel: [    0.000000]   3 base 00E0000000 mask 3FE0000000 uncachable
 kernel: [    0.000000]   4 base 1FF0000000 mask 3FF0000000 uncachable
 kernel: [    0.000000]   5 disabled
 kernel: [    0.000000]   6 disabled
 kernel: [    0.000000]   7 disabled
 kernel: [    0.000000] x86 PAT enabled: cpu 0 ......
 kernel: [    0.000000] original variable MTRRs
 kernel: [    0.000000] reg 0, base: 0GB, range: 128GB, type WB
 kernel: [    0.000000] reg 1, base: 3327MB, range: 1MB, type UC
 kernel: [    0.000000] reg 2, base: 3328MB, range: 256MB, type UC
 kernel: [    0.000000] reg 3, base: 3584MB, range: 512MB, type UC
 kernel: [    0.000000] reg 4, base: 130816MB, range: 256MB, type UC
 kernel: [    0.000000] total RAM covered: 130047M

mtrr_cleanup cannot construct an optimal map for this configuration.
Additionally, if the mtrr_gran_size/mtrr_chunk_size is specified,
mtrr_cleanup will use all entries attempting to map the full 128GB
phys address range.

If a WB MTRR entry which maps phys addr range [0, > max_pfn) exists,
constrain the entry to [0, roundup_pow_of_two(max_pfn) ) prior to
generating potential solutions. The example MTRR map is optimized to:
 kernel: [    0.000000] New variable MTRRs
 kernel: [    0.000000] reg 0, base: 0GB, range: 2GB, type WB
 kernel: [    0.000000] reg 1, base: 2GB, range: 1GB, type WB
 kernel: [    0.000000] reg 2, base: 3GB, range: 256MB, type WB
 kernel: [    0.000000] reg 3, base: 3327MB, range: 1MB, type UC
 kernel: [    0.000000] reg 4, base: 4GB, range: 4GB, type WB
 kernel: [    0.000000] reg 5, base: 8GB, range: 8GB, type WB

Signed-off-by: Peter Hurley <peter@hurleysoftware.com>
---
 arch/x86/kernel/cpu/mtrr/cleanup.c |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/x86/kernel/cpu/mtrr/cleanup.c b/arch/x86/kernel/cpu/mtrr/cleanup.c
index bdda2e6..ee399c3 100644
--- a/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ b/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -714,6 +714,16 @@ int __init mtrr_cleanup(unsigned address_bits)
 	if (mtrr_tom2)
 		x_remove_size = (mtrr_tom2 >> PAGE_SHIFT) - x_remove_base;
 
+	/* Constrain a WB entry that maps entire phys addr space to max mem */
+	for (i = 0; i < num_var_ranges; i++) {
+		if (range_state[i].type == MTRR_TYPE_WRBACK &&
+		    range_state[i].base_pfn == 0 &&
+		    range_state[i].size_pfn > max_pfn) {
+			range_state[i].size_pfn = roundup_pow_of_two(max_pfn);
+			break;
+		}
+	}
+
 	nr_range = x86_get_mtrr_mem_range(range, 0, x_remove_base, x_remove_size);
 	/*
 	 * [0, 1M) should always be covered by var mtrr with WB
-- 
1.7.5.4


             reply	other threads:[~2012-09-07 17:51 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-07 17:44 Peter Hurley [this message]
2012-09-07 18:40 ` [RFC] x86: mtrr: Constrain WB MTRR to max phys mem prior to cleanup H. Peter Anvin
2012-09-10  3:54   ` zhenzhong.duan
2012-09-28 17:37     ` Peter Hurley
2012-09-29  2:41       ` Zhenzhong Duan
2012-09-29  3:16       ` H. Peter Anvin
2012-09-29 10:46         ` Henrique de Moraes Holschuh
2012-09-29 15:05           ` H. Peter Anvin
2012-09-29 20:11             ` Henrique de Moraes Holschuh
2012-09-29 20:16               ` H. Peter Anvin
2012-09-29 20:17               ` H. Peter Anvin
2012-09-29 21:25                 ` Henrique de Moraes Holschuh
  -- strict thread matches above, loose matches on Subject: below --
2012-07-24 20:51 Peter Hurley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1347039854.6288.8.camel@thor \
    --to=peter@hurleysoftware.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=zhenzhong.duan@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox