2005-04-16 16:20:36 -06:00
|
|
|
/* This only handles 32bit MTRR on 32bit hosts. This is strictly wrong
|
|
|
|
because MTRRs can span upto 40 bits (36bits on most modern x86) */
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/mm.h>
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
#include <linux/module.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <asm/io.h>
|
|
|
|
#include <asm/mtrr.h>
|
|
|
|
#include <asm/msr.h>
|
|
|
|
#include <asm/system.h>
|
|
|
|
#include <asm/cpufeature.h>
|
2008-01-30 05:30:39 -07:00
|
|
|
#include <asm/processor-flags.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include <asm/tlbflush.h>
|
2008-03-18 18:00:14 -06:00
|
|
|
#include <asm/pat.h>
|
2005-04-16 16:20:36 -06:00
|
|
|
#include "mtrr.h"
|
|
|
|
|
|
|
|
struct mtrr_state {
|
x86, 32-bit: trim memory not covered by wb mtrrs
On some machines, buggy BIOSes don't properly setup WB MTRRs to cover all
available RAM, meaning the last few megs (or even gigs) of memory will be
marked uncached. Since Linux tends to allocate from high memory addresses
first, this causes the machine to be unusably slow as soon as the kernel
starts really using memory (i.e. right around init time).
This patch works around the problem by scanning the MTRRs at boot and
figuring out whether the current end_pfn value (setup by early e820 code)
goes beyond the highest WB MTRR range, and if so, trimming it to match. A
fairly obnoxious KERN_WARNING is printed too, letting the user know that
not all of their memory is available due to a likely BIOS bug.
Something similar could be done on i386 if needed, but the boot ordering
would be slightly different, since the MTRR code on i386 depends on the
boot_cpu_data structure being setup.
This patch fixes a bug in the last patch that caused the code to run on
non-Intel machines (AMD machines apparently don't need it and it's untested
on other non-Intel machines, so best keep it off).
Further enhancements and fixes from:
Yinghai Lu <Yinghai.Lu@Sun.COM>
Andi Kleen <ak@suse.de>
Signed-off-by: Jesse Barnes <jesse.barnes@intel.com>
Tested-by: Justin Piszcz <jpiszcz@lucidpixels.com>
Cc: Andi Kleen <andi@firstfloor.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Yinghai Lu <yhlu.kernel@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
2008-01-30 05:33:18 -07:00
|
|
|
struct mtrr_var_range var_ranges[MAX_VAR_RANGES];
|
2005-04-16 16:20:36 -06:00
|
|
|
mtrr_type fixed_ranges[NUM_FIXED_RANGES];
|
|
|
|
unsigned char enabled;
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
unsigned char have_fixed;
|
2005-04-16 16:20:36 -06:00
|
|
|
mtrr_type def_type;
|
|
|
|
};
|
|
|
|
|
2007-05-02 11:27:17 -06:00
|
|
|
struct fixed_range_block {
|
|
|
|
int base_msr; /* start address of an MTRR block */
|
|
|
|
int ranges; /* number of MTRRs in this block */
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct fixed_range_block fixed_range_blocks[] = {
|
|
|
|
{ MTRRfix64K_00000_MSR, 1 }, /* one 64k MTRR */
|
|
|
|
{ MTRRfix16K_80000_MSR, 2 }, /* two 16k MTRRs */
|
|
|
|
{ MTRRfix4K_C0000_MSR, 8 }, /* eight 4k MTRRs */
|
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
static unsigned long smp_changes_mask;
|
|
|
|
static struct mtrr_state mtrr_state = {};
|
2008-03-18 18:00:14 -06:00
|
|
|
static int mtrr_state_set;
|
2008-04-29 04:52:33 -06:00
|
|
|
u64 mtrr_tom2;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
#undef MODULE_PARAM_PREFIX
|
|
|
|
#define MODULE_PARAM_PREFIX "mtrr."
|
|
|
|
|
2007-05-02 11:27:18 -06:00
|
|
|
static int mtrr_show;
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
module_param_named(show, mtrr_show, bool, 0);
|
|
|
|
|
2008-03-18 18:00:14 -06:00
|
|
|
/*
|
|
|
|
* Returns the effective MTRR type for the region
|
|
|
|
* Error returns:
|
|
|
|
* - 0xFE - when the range is "not entirely covered" by _any_ var range MTRR
|
|
|
|
* - 0xFF - when MTRR is not enabled
|
|
|
|
*/
|
|
|
|
u8 mtrr_type_lookup(u64 start, u64 end)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
u64 base, mask;
|
|
|
|
u8 prev_match, curr_match;
|
|
|
|
|
|
|
|
if (!mtrr_state_set)
|
|
|
|
return 0xFF;
|
|
|
|
|
|
|
|
if (!mtrr_state.enabled)
|
|
|
|
return 0xFF;
|
|
|
|
|
|
|
|
/* Make end inclusive end, instead of exclusive */
|
|
|
|
end--;
|
|
|
|
|
|
|
|
/* Look in fixed ranges. Just return the type as per start */
|
|
|
|
if (mtrr_state.have_fixed && (start < 0x100000)) {
|
|
|
|
int idx;
|
|
|
|
|
|
|
|
if (start < 0x80000) {
|
|
|
|
idx = 0;
|
|
|
|
idx += (start >> 16);
|
|
|
|
return mtrr_state.fixed_ranges[idx];
|
|
|
|
} else if (start < 0xC0000) {
|
|
|
|
idx = 1 * 8;
|
|
|
|
idx += ((start - 0x80000) >> 14);
|
|
|
|
return mtrr_state.fixed_ranges[idx];
|
|
|
|
} else if (start < 0x1000000) {
|
|
|
|
idx = 3 * 8;
|
|
|
|
idx += ((start - 0xC0000) >> 12);
|
|
|
|
return mtrr_state.fixed_ranges[idx];
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Look in variable ranges
|
|
|
|
* Look of multiple ranges matching this address and pick type
|
|
|
|
* as per MTRR precedence
|
|
|
|
*/
|
2008-04-26 22:00:17 -06:00
|
|
|
if (!(mtrr_state.enabled & 2)) {
|
2008-03-18 18:00:14 -06:00
|
|
|
return mtrr_state.def_type;
|
|
|
|
}
|
|
|
|
|
|
|
|
prev_match = 0xFF;
|
|
|
|
for (i = 0; i < num_var_ranges; ++i) {
|
|
|
|
unsigned short start_state, end_state;
|
|
|
|
|
|
|
|
if (!(mtrr_state.var_ranges[i].mask_lo & (1 << 11)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
base = (((u64)mtrr_state.var_ranges[i].base_hi) << 32) +
|
|
|
|
(mtrr_state.var_ranges[i].base_lo & PAGE_MASK);
|
|
|
|
mask = (((u64)mtrr_state.var_ranges[i].mask_hi) << 32) +
|
|
|
|
(mtrr_state.var_ranges[i].mask_lo & PAGE_MASK);
|
|
|
|
|
|
|
|
start_state = ((start & mask) == (base & mask));
|
|
|
|
end_state = ((end & mask) == (base & mask));
|
|
|
|
if (start_state != end_state)
|
|
|
|
return 0xFE;
|
|
|
|
|
|
|
|
if ((start & mask) != (base & mask)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
curr_match = mtrr_state.var_ranges[i].base_lo & 0xff;
|
|
|
|
if (prev_match == 0xFF) {
|
|
|
|
prev_match = curr_match;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (prev_match == MTRR_TYPE_UNCACHABLE ||
|
|
|
|
curr_match == MTRR_TYPE_UNCACHABLE) {
|
|
|
|
return MTRR_TYPE_UNCACHABLE;
|
|
|
|
}
|
|
|
|
|
|
|
|
if ((prev_match == MTRR_TYPE_WRBACK &&
|
|
|
|
curr_match == MTRR_TYPE_WRTHROUGH) ||
|
|
|
|
(prev_match == MTRR_TYPE_WRTHROUGH &&
|
|
|
|
curr_match == MTRR_TYPE_WRBACK)) {
|
|
|
|
prev_match = MTRR_TYPE_WRTHROUGH;
|
|
|
|
curr_match = MTRR_TYPE_WRTHROUGH;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (prev_match != curr_match) {
|
|
|
|
return MTRR_TYPE_UNCACHABLE;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-04-29 04:52:33 -06:00
|
|
|
if (mtrr_tom2) {
|
|
|
|
if (start >= (1ULL<<32) && (end < mtrr_tom2))
|
2008-03-24 17:02:01 -06:00
|
|
|
return MTRR_TYPE_WRBACK;
|
|
|
|
}
|
|
|
|
|
2008-03-18 18:00:14 -06:00
|
|
|
if (prev_match != 0xFF)
|
|
|
|
return prev_match;
|
|
|
|
|
|
|
|
return mtrr_state.def_type;
|
|
|
|
}
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Get the MSR pair relating to a var range */
|
2007-06-20 04:23:39 -06:00
|
|
|
static void
|
2005-04-16 16:20:36 -06:00
|
|
|
get_mtrr_var_range(unsigned int index, struct mtrr_var_range *vr)
|
|
|
|
{
|
|
|
|
rdmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
|
|
|
|
rdmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
|
|
|
|
}
|
|
|
|
|
2008-04-29 04:52:33 -06:00
|
|
|
/* fill the MSR pair relating to a var range */
|
|
|
|
void fill_mtrr_var_range(unsigned int index,
|
|
|
|
u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi)
|
|
|
|
{
|
|
|
|
struct mtrr_var_range *vr;
|
|
|
|
|
|
|
|
vr = mtrr_state.var_ranges;
|
|
|
|
|
|
|
|
vr[index].base_lo = base_lo;
|
|
|
|
vr[index].base_hi = base_hi;
|
|
|
|
vr[index].mask_lo = mask_lo;
|
|
|
|
vr[index].mask_hi = mask_hi;
|
|
|
|
}
|
|
|
|
|
2007-05-02 11:27:17 -06:00
|
|
|
static void
|
2005-04-16 16:20:36 -06:00
|
|
|
get_fixed_ranges(mtrr_type * frs)
|
|
|
|
{
|
|
|
|
unsigned int *p = (unsigned int *) frs;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
rdmsr(MTRRfix64K_00000_MSR, p[0], p[1]);
|
|
|
|
|
|
|
|
for (i = 0; i < 2; i++)
|
|
|
|
rdmsr(MTRRfix16K_80000_MSR + i, p[2 + i * 2], p[3 + i * 2]);
|
|
|
|
for (i = 0; i < 8; i++)
|
|
|
|
rdmsr(MTRRfix4K_C0000_MSR + i, p[6 + i * 2], p[7 + i * 2]);
|
|
|
|
}
|
|
|
|
|
2007-05-02 11:27:17 -06:00
|
|
|
void mtrr_save_fixed_ranges(void *info)
|
|
|
|
{
|
2007-07-01 13:06:48 -06:00
|
|
|
if (cpu_has_mtrr)
|
|
|
|
get_fixed_ranges(mtrr_state.fixed_ranges);
|
2007-05-02 11:27:17 -06:00
|
|
|
}
|
|
|
|
|
2007-06-20 04:23:39 -06:00
|
|
|
static void print_fixed(unsigned base, unsigned step, const mtrr_type*types)
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
|
|
|
|
for (i = 0; i < 8; ++i, ++types, base += step)
|
2007-05-02 11:27:18 -06:00
|
|
|
printk(KERN_INFO "MTRR %05X-%05X %s\n",
|
|
|
|
base, base + step - 1, mtrr_attrib_to_str(*types));
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
}
|
|
|
|
|
2008-03-18 18:00:14 -06:00
|
|
|
static void prepare_set(void);
|
|
|
|
static void post_set(void);
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
/* Grab all of the MTRR state for this CPU into *state */
|
2007-07-21 09:10:39 -06:00
|
|
|
void __init get_mtrr_state(void)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
struct mtrr_var_range *vrs;
|
|
|
|
unsigned lo, dummy;
|
2008-03-18 18:00:14 -06:00
|
|
|
unsigned long flags;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
vrs = mtrr_state.var_ranges;
|
|
|
|
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
rdmsr(MTRRcap_MSR, lo, dummy);
|
|
|
|
mtrr_state.have_fixed = (lo >> 8) & 1;
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
for (i = 0; i < num_var_ranges; i++)
|
|
|
|
get_mtrr_var_range(i, &vrs[i]);
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
if (mtrr_state.have_fixed)
|
|
|
|
get_fixed_ranges(mtrr_state.fixed_ranges);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
rdmsr(MTRRdefType_MSR, lo, dummy);
|
|
|
|
mtrr_state.def_type = (lo & 0xff);
|
|
|
|
mtrr_state.enabled = (lo & 0xc00) >> 10;
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
|
2008-03-24 17:02:01 -06:00
|
|
|
if (amd_special_default_mtrr()) {
|
2008-04-30 12:11:51 -06:00
|
|
|
unsigned low, high;
|
2008-03-24 17:02:01 -06:00
|
|
|
/* TOP_MEM2 */
|
2008-04-30 12:11:51 -06:00
|
|
|
rdmsr(MSR_K8_TOP_MEM2, low, high);
|
2008-04-29 04:52:33 -06:00
|
|
|
mtrr_tom2 = high;
|
|
|
|
mtrr_tom2 <<= 32;
|
|
|
|
mtrr_tom2 |= low;
|
2008-05-12 18:40:39 -06:00
|
|
|
mtrr_tom2 &= 0xffffff800000ULL;
|
2008-03-24 17:02:01 -06:00
|
|
|
}
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
if (mtrr_show) {
|
|
|
|
int high_width;
|
|
|
|
|
|
|
|
printk(KERN_INFO "MTRR default type: %s\n", mtrr_attrib_to_str(mtrr_state.def_type));
|
|
|
|
if (mtrr_state.have_fixed) {
|
|
|
|
printk(KERN_INFO "MTRR fixed ranges %sabled:\n",
|
|
|
|
mtrr_state.enabled & 1 ? "en" : "dis");
|
|
|
|
print_fixed(0x00000, 0x10000, mtrr_state.fixed_ranges + 0);
|
|
|
|
for (i = 0; i < 2; ++i)
|
|
|
|
print_fixed(0x80000 + i * 0x20000, 0x04000, mtrr_state.fixed_ranges + (i + 1) * 8);
|
|
|
|
for (i = 0; i < 8; ++i)
|
|
|
|
print_fixed(0xC0000 + i * 0x08000, 0x01000, mtrr_state.fixed_ranges + (i + 3) * 8);
|
|
|
|
}
|
|
|
|
printk(KERN_INFO "MTRR variable ranges %sabled:\n",
|
|
|
|
mtrr_state.enabled & 2 ? "en" : "dis");
|
|
|
|
high_width = ((size_or_mask ? ffs(size_or_mask) - 1 : 32) - (32 - PAGE_SHIFT) + 3) / 4;
|
|
|
|
for (i = 0; i < num_var_ranges; ++i) {
|
|
|
|
if (mtrr_state.var_ranges[i].mask_lo & (1 << 11))
|
|
|
|
printk(KERN_INFO "MTRR %u base %0*X%05X000 mask %0*X%05X000 %s\n",
|
|
|
|
i,
|
|
|
|
high_width,
|
|
|
|
mtrr_state.var_ranges[i].base_hi,
|
|
|
|
mtrr_state.var_ranges[i].base_lo >> 12,
|
|
|
|
high_width,
|
|
|
|
mtrr_state.var_ranges[i].mask_hi,
|
|
|
|
mtrr_state.var_ranges[i].mask_lo >> 12,
|
|
|
|
mtrr_attrib_to_str(mtrr_state.var_ranges[i].base_lo & 0xff));
|
|
|
|
else
|
|
|
|
printk(KERN_INFO "MTRR %u disabled\n", i);
|
|
|
|
}
|
2008-04-29 04:52:33 -06:00
|
|
|
if (mtrr_tom2) {
|
2008-04-08 08:25:42 -06:00
|
|
|
printk(KERN_INFO "TOM2: %016llx aka %lldM\n",
|
2008-04-29 04:52:33 -06:00
|
|
|
mtrr_tom2, mtrr_tom2>>20);
|
2008-04-08 08:25:42 -06:00
|
|
|
}
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
}
|
2008-03-18 18:00:14 -06:00
|
|
|
mtrr_state_set = 1;
|
|
|
|
|
|
|
|
/* PAT setup for BP. We need to go through sync steps here */
|
|
|
|
local_irq_save(flags);
|
|
|
|
prepare_set();
|
|
|
|
|
|
|
|
pat_init();
|
|
|
|
|
|
|
|
post_set();
|
|
|
|
local_irq_restore(flags);
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Some BIOS's are fucked and don't set all MTRRs the same! */
|
|
|
|
void __init mtrr_state_warn(void)
|
|
|
|
{
|
|
|
|
unsigned long mask = smp_changes_mask;
|
|
|
|
|
|
|
|
if (!mask)
|
|
|
|
return;
|
|
|
|
if (mask & MTRR_CHANGE_MASK_FIXED)
|
|
|
|
printk(KERN_WARNING "mtrr: your CPUs had inconsistent fixed MTRR settings\n");
|
|
|
|
if (mask & MTRR_CHANGE_MASK_VARIABLE)
|
|
|
|
printk(KERN_WARNING "mtrr: your CPUs had inconsistent variable MTRR settings\n");
|
|
|
|
if (mask & MTRR_CHANGE_MASK_DEFTYPE)
|
|
|
|
printk(KERN_WARNING "mtrr: your CPUs had inconsistent MTRRdefType settings\n");
|
|
|
|
printk(KERN_INFO "mtrr: probably your BIOS does not setup all CPUs.\n");
|
|
|
|
printk(KERN_INFO "mtrr: corrected configuration.\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Doesn't attempt to pass an error out to MTRR users
|
|
|
|
because it's quite complicated in some cases and probably not
|
|
|
|
worth it because the best error handling is to ignore it. */
|
|
|
|
void mtrr_wrmsr(unsigned msr, unsigned a, unsigned b)
|
|
|
|
{
|
|
|
|
if (wrmsr_safe(msr, a, b) < 0)
|
|
|
|
printk(KERN_ERR
|
|
|
|
"MTRR: CPU %u: Writing MSR %x to %x:%x failed\n",
|
|
|
|
smp_processor_id(), msr, a, b);
|
|
|
|
}
|
|
|
|
|
2007-05-02 11:27:17 -06:00
|
|
|
/**
|
|
|
|
* Enable and allow read/write of extended fixed-range MTRR bits on K8 CPUs
|
|
|
|
* see AMD publication no. 24593, chapter 3.2.1 for more information
|
|
|
|
*/
|
|
|
|
static inline void k8_enable_fixed_iorrs(void)
|
|
|
|
{
|
|
|
|
unsigned lo, hi;
|
|
|
|
|
|
|
|
rdmsr(MSR_K8_SYSCFG, lo, hi);
|
|
|
|
mtrr_wrmsr(MSR_K8_SYSCFG, lo
|
|
|
|
| K8_MTRRFIXRANGE_DRAM_ENABLE
|
|
|
|
| K8_MTRRFIXRANGE_DRAM_MODIFY, hi);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
2008-03-13 17:59:12 -06:00
|
|
|
* set_fixed_range - checks & updates a fixed-range MTRR if it differs from the value it should have
|
|
|
|
* @msr: MSR address of the MTTR which should be checked and updated
|
|
|
|
* @changed: pointer which indicates whether the MTRR needed to be changed
|
|
|
|
* @msrwords: pointer to the MSR values which the MSR should have
|
|
|
|
*
|
|
|
|
* If K8 extentions are wanted, update the K8 SYSCFG MSR also.
|
|
|
|
* See AMD publication no. 24593, chapter 7.8.1, page 233 for more information.
|
2007-05-02 11:27:17 -06:00
|
|
|
*/
|
2008-01-30 05:30:31 -07:00
|
|
|
static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords)
|
2007-05-02 11:27:17 -06:00
|
|
|
{
|
|
|
|
unsigned lo, hi;
|
|
|
|
|
|
|
|
rdmsr(msr, lo, hi);
|
|
|
|
|
|
|
|
if (lo != msrwords[0] || hi != msrwords[1]) {
|
|
|
|
if (boot_cpu_data.x86_vendor == X86_VENDOR_AMD &&
|
2008-05-05 16:57:38 -06:00
|
|
|
(boot_cpu_data.x86 >= 0x0f && boot_cpu_data.x86 <= 0x11) &&
|
2007-05-02 11:27:17 -06:00
|
|
|
((msrwords[0] | msrwords[1]) & K8_MTRR_RDMEM_WRMEM_MASK))
|
|
|
|
k8_enable_fixed_iorrs();
|
|
|
|
mtrr_wrmsr(msr, msrwords[0], msrwords[1]);
|
2008-01-30 05:30:31 -07:00
|
|
|
*changed = true;
|
2007-05-02 11:27:17 -06:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-13 17:59:12 -06:00
|
|
|
/**
|
|
|
|
* generic_get_free_region - Get a free MTRR.
|
|
|
|
* @base: The starting (base) address of the region.
|
|
|
|
* @size: The size (in bytes) of the region.
|
|
|
|
* @replace_reg: mtrr index to be replaced; set to invalid value if none.
|
|
|
|
*
|
|
|
|
* Returns: The index of the region on success, else negative on error.
|
|
|
|
*/
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
int generic_get_free_region(unsigned long base, unsigned long size, int replace_reg)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
int i, max;
|
|
|
|
mtrr_type ltype;
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
unsigned long lbase, lsize;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
max = num_var_ranges;
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
if (replace_reg >= 0 && replace_reg < max)
|
|
|
|
return replace_reg;
|
2005-04-16 16:20:36 -06:00
|
|
|
for (i = 0; i < max; ++i) {
|
|
|
|
mtrr_if->get(i, &lbase, &lsize, <ype);
|
|
|
|
if (lsize == 0)
|
|
|
|
return i;
|
|
|
|
}
|
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
|
2005-05-01 09:59:29 -06:00
|
|
|
static void generic_get_mtrr(unsigned int reg, unsigned long *base,
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
unsigned long *size, mtrr_type *type)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
unsigned int mask_lo, mask_hi, base_lo, base_hi;
|
|
|
|
|
|
|
|
rdmsr(MTRRphysMask_MSR(reg), mask_lo, mask_hi);
|
|
|
|
if ((mask_lo & 0x800) == 0) {
|
|
|
|
/* Invalid (i.e. free) range */
|
|
|
|
*base = 0;
|
|
|
|
*size = 0;
|
|
|
|
*type = 0;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
rdmsr(MTRRphysBase_MSR(reg), base_lo, base_hi);
|
|
|
|
|
|
|
|
/* Work out the shifted address mask. */
|
|
|
|
mask_lo = size_or_mask | mask_hi << (32 - PAGE_SHIFT)
|
|
|
|
| mask_lo >> PAGE_SHIFT;
|
|
|
|
|
|
|
|
/* This works correctly if size is a power of two, i.e. a
|
|
|
|
contiguous range. */
|
|
|
|
*size = -mask_lo;
|
|
|
|
*base = base_hi << (32 - PAGE_SHIFT) | base_lo >> PAGE_SHIFT;
|
|
|
|
*type = base_lo & 0xff;
|
|
|
|
}
|
|
|
|
|
2007-05-02 11:27:17 -06:00
|
|
|
/**
|
2008-03-13 17:59:12 -06:00
|
|
|
* set_fixed_ranges - checks & updates the fixed-range MTRRs if they differ from the saved set
|
|
|
|
* @frs: pointer to fixed-range MTRR values, saved by get_fixed_ranges()
|
2007-05-02 11:27:17 -06:00
|
|
|
*/
|
2005-04-16 16:20:36 -06:00
|
|
|
static int set_fixed_ranges(mtrr_type * frs)
|
|
|
|
{
|
2007-05-02 11:27:17 -06:00
|
|
|
unsigned long long *saved = (unsigned long long *) frs;
|
2008-01-30 05:30:31 -07:00
|
|
|
bool changed = false;
|
2007-05-02 11:27:17 -06:00
|
|
|
int block=-1, range;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2007-05-02 11:27:17 -06:00
|
|
|
while (fixed_range_blocks[++block].ranges)
|
|
|
|
for (range=0; range < fixed_range_blocks[block].ranges; range++)
|
|
|
|
set_fixed_range(fixed_range_blocks[block].base_msr + range,
|
|
|
|
&changed, (unsigned int *) saved++);
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set the MSR pair relating to a var range. Returns TRUE if
|
|
|
|
changes are made */
|
2008-01-30 05:30:31 -07:00
|
|
|
static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
unsigned int lo, hi;
|
2008-01-30 05:30:31 -07:00
|
|
|
bool changed = false;
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
rdmsr(MTRRphysBase_MSR(index), lo, hi);
|
|
|
|
if ((vr->base_lo & 0xfffff0ffUL) != (lo & 0xfffff0ffUL)
|
2005-04-16 16:25:11 -06:00
|
|
|
|| (vr->base_hi & (size_and_mask >> (32 - PAGE_SHIFT))) !=
|
|
|
|
(hi & (size_and_mask >> (32 - PAGE_SHIFT)))) {
|
2005-04-16 16:20:36 -06:00
|
|
|
mtrr_wrmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
|
2008-01-30 05:30:31 -07:00
|
|
|
changed = true;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
rdmsr(MTRRphysMask_MSR(index), lo, hi);
|
|
|
|
|
|
|
|
if ((vr->mask_lo & 0xfffff800UL) != (lo & 0xfffff800UL)
|
2005-04-16 16:25:11 -06:00
|
|
|
|| (vr->mask_hi & (size_and_mask >> (32 - PAGE_SHIFT))) !=
|
|
|
|
(hi & (size_and_mask >> (32 - PAGE_SHIFT)))) {
|
2005-04-16 16:20:36 -06:00
|
|
|
mtrr_wrmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
|
2008-01-30 05:30:31 -07:00
|
|
|
changed = true;
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
static u32 deftype_lo, deftype_hi;
|
|
|
|
|
2008-03-13 17:59:12 -06:00
|
|
|
/**
|
|
|
|
* set_mtrr_state - Set the MTRR state for this CPU.
|
|
|
|
*
|
|
|
|
* NOTE: The CPU must already be in a safe state for MTRR changes.
|
|
|
|
* RETURNS: 0 if no changes made, else a mask indicating what was changed.
|
|
|
|
*/
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
static unsigned long set_mtrr_state(void)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
unsigned long change_mask = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < num_var_ranges; i++)
|
|
|
|
if (set_mtrr_var_ranges(i, &mtrr_state.var_ranges[i]))
|
|
|
|
change_mask |= MTRR_CHANGE_MASK_VARIABLE;
|
|
|
|
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
if (mtrr_state.have_fixed && set_fixed_ranges(mtrr_state.fixed_ranges))
|
2005-04-16 16:20:36 -06:00
|
|
|
change_mask |= MTRR_CHANGE_MASK_FIXED;
|
|
|
|
|
|
|
|
/* Set_mtrr_restore restores the old value of MTRRdefType,
|
|
|
|
so to set it we fiddle with the saved value */
|
|
|
|
if ((deftype_lo & 0xff) != mtrr_state.def_type
|
|
|
|
|| ((deftype_lo & 0xc00) >> 10) != mtrr_state.enabled) {
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
deftype_lo = (deftype_lo & ~0xcff) | mtrr_state.def_type | (mtrr_state.enabled << 10);
|
2005-04-16 16:20:36 -06:00
|
|
|
change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return change_mask;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static unsigned long cr4 = 0;
|
|
|
|
static DEFINE_SPINLOCK(set_atomicity_lock);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Since we are disabling the cache don't allow any interrupts - they
|
|
|
|
* would run extremely slow and would only increase the pain. The caller must
|
|
|
|
* ensure that local interrupts are disabled and are reenabled after post_set()
|
|
|
|
* has been called.
|
|
|
|
*/
|
|
|
|
|
2006-09-26 00:32:36 -06:00
|
|
|
static void prepare_set(void) __acquires(set_atomicity_lock)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
unsigned long cr0;
|
|
|
|
|
|
|
|
/* Note that this is not ideal, since the cache is only flushed/disabled
|
|
|
|
for this CPU while the MTRRs are changed, but changing this requires
|
|
|
|
more invasive changes to the way the kernel boots */
|
|
|
|
|
|
|
|
spin_lock(&set_atomicity_lock);
|
|
|
|
|
|
|
|
/* Enter the no-fill (CD=1, NW=0) cache mode and flush caches. */
|
2008-01-30 05:30:39 -07:00
|
|
|
cr0 = read_cr0() | X86_CR0_CD;
|
2005-04-16 16:20:36 -06:00
|
|
|
write_cr0(cr0);
|
|
|
|
wbinvd();
|
|
|
|
|
|
|
|
/* Save value of CR4 and clear Page Global Enable (bit 7) */
|
|
|
|
if ( cpu_has_pge ) {
|
|
|
|
cr4 = read_cr4();
|
|
|
|
write_cr4(cr4 & ~X86_CR4_PGE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Flush all TLBs via a mov %cr3, %reg; mov %reg, %cr3 */
|
|
|
|
__flush_tlb();
|
|
|
|
|
|
|
|
/* Save MTRR state */
|
|
|
|
rdmsr(MTRRdefType_MSR, deftype_lo, deftype_hi);
|
|
|
|
|
|
|
|
/* Disable MTRRs, and set the default type to uncached */
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
mtrr_wrmsr(MTRRdefType_MSR, deftype_lo & ~0xcff, deftype_hi);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
2006-09-26 00:32:36 -06:00
|
|
|
static void post_set(void) __releases(set_atomicity_lock)
|
2005-04-16 16:20:36 -06:00
|
|
|
{
|
|
|
|
/* Flush TLBs (no need to flush caches - they are disabled) */
|
|
|
|
__flush_tlb();
|
|
|
|
|
|
|
|
/* Intel (P6) standard MTRRs */
|
|
|
|
mtrr_wrmsr(MTRRdefType_MSR, deftype_lo, deftype_hi);
|
|
|
|
|
|
|
|
/* Enable caches */
|
|
|
|
write_cr0(read_cr0() & 0xbfffffff);
|
|
|
|
|
|
|
|
/* Restore value of CR4 */
|
|
|
|
if ( cpu_has_pge )
|
|
|
|
write_cr4(cr4);
|
|
|
|
spin_unlock(&set_atomicity_lock);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void generic_set_all(void)
|
|
|
|
{
|
|
|
|
unsigned long mask, count;
|
|
|
|
unsigned long flags;
|
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
prepare_set();
|
|
|
|
|
|
|
|
/* Actually set the state */
|
[PATCH] i386: fix MTRR code
Until not so long ago, there were system log messages pointing to
inconsistent MTRR setup of the video frame buffer caused by the way vesafb
and X worked. While vesafb was fixed meanwhile, I believe fixing it there
only hides a shortcoming in the MTRR code itself, in that that code is not
symmetric with respect to the ordering of attempts to set up two (or more)
regions where one contains the other. In the current shape, it permits
only setting up sub-regions of pre-exisiting ones. The patch below makes
this symmetric.
While working on that I noticed a few more inconsistencies in that code,
namely
- use of 'unsigned int' for sizes in many, but not all places (the patch
is converting this to use 'unsigned long' everywhere, which specifically
might be necessary for x86-64 once a processor supporting more than 44
physical address bits would become available)
- the code to correct inconsistent settings during secondary processor
startup tried (if necessary) to correct, among other things, the value
in IA32_MTRR_DEF_TYPE, however the newly computed value would never get
used (i.e. stored in the respective MSR)
- the generic range validation code checked that the end of the
to-be-added range would be above 1MB; the value checked should have been
the start of the range
- when contained regions are detected, previously this was allowed only
when the old region was uncacheable; this can be symmetric (i.e. the new
region can also be uncacheable) and even further as per Intel's
documentation write-trough and write-back for either region is also
compatible with the respective opposite in the other
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Andi Kleen <ak@suse.de>
2006-12-06 18:14:09 -07:00
|
|
|
mask = set_mtrr_state();
|
2005-04-16 16:20:36 -06:00
|
|
|
|
2008-03-18 18:00:14 -06:00
|
|
|
/* also set PAT */
|
|
|
|
pat_init();
|
|
|
|
|
2005-04-16 16:20:36 -06:00
|
|
|
post_set();
|
|
|
|
local_irq_restore(flags);
|
|
|
|
|
|
|
|
/* Use the atomic bitops to update the global mask */
|
|
|
|
for (count = 0; count < sizeof mask * 8; ++count) {
|
|
|
|
if (mask & 0x01)
|
|
|
|
set_bit(count, &smp_changes_mask);
|
|
|
|
mask >>= 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
|
|
static void generic_set_mtrr(unsigned int reg, unsigned long base,
|
|
|
|
unsigned long size, mtrr_type type)
|
|
|
|
/* [SUMMARY] Set variable MTRR register on the local CPU.
|
|
|
|
<reg> The register to set.
|
|
|
|
<base> The base address of the region.
|
|
|
|
<size> The size of the region. If this is 0 the region is disabled.
|
|
|
|
<type> The type of the region.
|
|
|
|
[RETURNS] Nothing.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
2005-07-07 18:56:38 -06:00
|
|
|
struct mtrr_var_range *vr;
|
|
|
|
|
|
|
|
vr = &mtrr_state.var_ranges[reg];
|
2005-04-16 16:20:36 -06:00
|
|
|
|
|
|
|
local_irq_save(flags);
|
|
|
|
prepare_set();
|
|
|
|
|
|
|
|
if (size == 0) {
|
|
|
|
/* The invalid bit is kept in the mask, so we simply clear the
|
|
|
|
relevant mask register to disable a range. */
|
|
|
|
mtrr_wrmsr(MTRRphysMask_MSR(reg), 0, 0);
|
2005-07-07 18:56:38 -06:00
|
|
|
memset(vr, 0, sizeof(struct mtrr_var_range));
|
2005-04-16 16:20:36 -06:00
|
|
|
} else {
|
2005-07-07 18:56:38 -06:00
|
|
|
vr->base_lo = base << PAGE_SHIFT | type;
|
|
|
|
vr->base_hi = (base & size_and_mask) >> (32 - PAGE_SHIFT);
|
|
|
|
vr->mask_lo = -size << PAGE_SHIFT | 0x800;
|
|
|
|
vr->mask_hi = (-size & size_and_mask) >> (32 - PAGE_SHIFT);
|
|
|
|
|
|
|
|
mtrr_wrmsr(MTRRphysBase_MSR(reg), vr->base_lo, vr->base_hi);
|
|
|
|
mtrr_wrmsr(MTRRphysMask_MSR(reg), vr->mask_lo, vr->mask_hi);
|
2005-04-16 16:20:36 -06:00
|
|
|
}
|
|
|
|
|
|
|
|
post_set();
|
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
int generic_validate_add_page(unsigned long base, unsigned long size, unsigned int type)
|
|
|
|
{
|
|
|
|
unsigned long lbase, last;
|
|
|
|
|
|
|
|
/* For Intel PPro stepping <= 7, must be 4 MiB aligned
|
|
|
|
and not touch 0x70000000->0x7003FFFF */
|
|
|
|
if (is_cpu(INTEL) && boot_cpu_data.x86 == 6 &&
|
|
|
|
boot_cpu_data.x86_model == 1 &&
|
|
|
|
boot_cpu_data.x86_mask <= 7) {
|
|
|
|
if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
|
|
|
|
printk(KERN_WARNING "mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
2006-12-06 18:14:00 -07:00
|
|
|
if (!(base + size < 0x70000 || base > 0x7003F) &&
|
2005-04-16 16:20:36 -06:00
|
|
|
(type == MTRR_TYPE_WRCOMB
|
|
|
|
|| type == MTRR_TYPE_WRBACK)) {
|
|
|
|
printk(KERN_WARNING "mtrr: writable mtrr between 0x70000000 and 0x7003FFFF may hang the CPU.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Check upper bits of base and last are equal and lower bits are 0
|
|
|
|
for base and 1 for last */
|
|
|
|
last = base + size - 1;
|
|
|
|
for (lbase = base; !(lbase & 1) && (last & 1);
|
|
|
|
lbase = lbase >> 1, last = last >> 1) ;
|
|
|
|
if (lbase != last) {
|
|
|
|
printk(KERN_WARNING "mtrr: base(0x%lx000) is not aligned on a size(0x%lx000) boundary\n",
|
|
|
|
base, size);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
static int generic_have_wrcomb(void)
|
|
|
|
{
|
|
|
|
unsigned long config, dummy;
|
|
|
|
rdmsr(MTRRcap_MSR, config, dummy);
|
|
|
|
return (config & (1 << 10));
|
|
|
|
}
|
|
|
|
|
|
|
|
int positive_have_wrcomb(void)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* generic structure...
|
|
|
|
*/
|
|
|
|
struct mtrr_ops generic_mtrr_ops = {
|
|
|
|
.use_intel_if = 1,
|
|
|
|
.set_all = generic_set_all,
|
|
|
|
.get = generic_get_mtrr,
|
|
|
|
.get_free_region = generic_get_free_region,
|
|
|
|
.set = generic_set_mtrr,
|
|
|
|
.validate_add_page = generic_validate_add_page,
|
|
|
|
.have_wrcomb = generic_have_wrcomb,
|
|
|
|
};
|