2019-05-19 13:08:55 +01:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* This only handles 32bit MTRR on 32bit hosts. This is strictly wrong
|
2011-03-17 16:24:16 -03:00
|
|
|
* because MTRRs can span up to 40 bits (36bits on most modern x86)
|
2009-07-04 07:53:00 +05:30
|
|
|
*/
|
|
|
|
|
2016-07-13 20:18:56 -04:00
|
|
|
#include <linux/export.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/init.h>
|
2009-07-04 07:53:00 +05:30
|
|
|
#include <linux/io.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <linux/mm.h>
|
2023-05-02 14:09:18 +02:00
|
|
|
#include <linux/cc_platform.h>
|
2025-01-17 15:48:59 +01:00
|
|
|
#include <linux/string_choices.h>
|
2008-01-30 13:30:39 +01:00
|
|
|
#include <asm/processor-flags.h>
|
2022-11-02 08:47:01 +01:00
|
|
|
#include <asm/cacheinfo.h>
|
2009-07-04 07:53:00 +05:30
|
|
|
#include <asm/cpufeature.h>
|
2025-02-19 18:41:22 +00:00
|
|
|
#include <asm/cpu_device_id.h>
|
2023-05-02 14:09:18 +02:00
|
|
|
#include <asm/hypervisor.h>
|
|
|
|
#include <asm/mshyperv.h>
|
2005-04-16 15:20:36 -07:00
|
|
|
#include <asm/tlbflush.h>
|
2009-07-04 07:53:00 +05:30
|
|
|
#include <asm/mtrr.h>
|
|
|
|
#include <asm/msr.h>
|
2019-11-20 15:33:57 +01:00
|
|
|
#include <asm/memtype.h>
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
#include "mtrr.h"
|
|
|
|
|
2007-05-02 19:27:17 +02:00
|
|
|
struct fixed_range_block {
|
2009-07-04 07:53:00 +05:30
|
|
|
int base_msr; /* start address of an MTRR block */
|
|
|
|
int ranges; /* number of MTRRs in this block */
|
2007-05-02 19:27:17 +02:00
|
|
|
};
|
|
|
|
|
|
|
|
static struct fixed_range_block fixed_range_blocks[] = {
|
2009-07-04 07:53:00 +05:30
|
|
|
{ MSR_MTRRfix64K_00000, 1 }, /* one 64k MTRR */
|
|
|
|
{ MSR_MTRRfix16K_80000, 2 }, /* two 16k MTRRs */
|
|
|
|
{ MSR_MTRRfix4K_C0000, 8 }, /* eight 4k MTRRs */
|
2007-05-02 19:27:17 +02:00
|
|
|
{}
|
|
|
|
};
|
|
|
|
|
2023-05-02 14:09:26 +02:00
|
|
|
struct cache_map {
|
|
|
|
u64 start;
|
|
|
|
u64 end;
|
|
|
|
u64 flags;
|
|
|
|
u64 type:8;
|
|
|
|
u64 fixed:1;
|
|
|
|
};
|
|
|
|
|
2023-05-31 19:23:34 +02:00
|
|
|
bool mtrr_debug;
|
2023-05-02 14:09:27 +02:00
|
|
|
|
|
|
|
static int __init mtrr_param_setup(char *str)
|
|
|
|
{
|
|
|
|
int rc = 0;
|
|
|
|
|
|
|
|
if (!str)
|
|
|
|
return -EINVAL;
|
|
|
|
if (!strcmp(str, "debug"))
|
|
|
|
mtrr_debug = true;
|
|
|
|
else
|
|
|
|
rc = -EINVAL;
|
|
|
|
|
|
|
|
return rc;
|
|
|
|
}
|
|
|
|
early_param("mtrr", mtrr_param_setup);
|
|
|
|
|
2023-05-02 14:09:26 +02:00
|
|
|
/*
|
|
|
|
* CACHE_MAP_MAX is the maximum number of memory ranges in cache_map, where
|
|
|
|
* no 2 adjacent ranges have the same cache mode (those would be merged).
|
|
|
|
* The number is based on the worst case:
|
|
|
|
* - no two adjacent fixed MTRRs share the same cache mode
|
|
|
|
* - one variable MTRR is spanning a huge area with mode WB
|
|
|
|
* - 255 variable MTRRs with mode UC all overlap with the WB MTRR, creating 2
|
|
|
|
* additional ranges each (result like "ababababa...aba" with a = WB, b = UC),
|
|
|
|
* accounting for MTRR_MAX_VAR_RANGES * 2 - 1 range entries
|
|
|
|
* - a TOP_MEM2 area (even with overlapping an UC MTRR can't add 2 range entries
|
|
|
|
* to the possible maximum, as it always starts at 4GB, thus it can't be in
|
|
|
|
* the middle of that MTRR, unless that MTRR starts at 0, which would remove
|
|
|
|
* the initial "a" from the "abababa" pattern above)
|
|
|
|
* The map won't contain ranges with no matching MTRR (those fall back to the
|
|
|
|
* default cache mode).
|
|
|
|
*/
|
|
|
|
#define CACHE_MAP_MAX (MTRR_NUM_FIXED_RANGES + MTRR_MAX_VAR_RANGES * 2)
|
|
|
|
|
|
|
|
static struct cache_map init_cache_map[CACHE_MAP_MAX] __initdata;
|
|
|
|
static struct cache_map *cache_map __refdata = init_cache_map;
|
|
|
|
static unsigned int cache_map_size = CACHE_MAP_MAX;
|
|
|
|
static unsigned int cache_map_n;
|
|
|
|
static unsigned int cache_map_fixed;
|
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
static unsigned long smp_changes_mask;
|
2008-03-18 17:00:14 -07:00
|
|
|
static int mtrr_state_set;
|
2008-04-29 03:52:33 -07:00
|
|
|
u64 mtrr_tom2;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
struct mtrr_state_type mtrr_state;
|
2008-10-09 16:01:53 +08:00
|
|
|
EXPORT_SYMBOL_GPL(mtrr_state);
|
|
|
|
|
2023-05-02 14:09:17 +02:00
|
|
|
/* Reserved bits in the high portion of the MTRRphysBaseN MSR. */
|
|
|
|
u32 phys_hi_rsvd;
|
2023-05-02 14:09:16 +02:00
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
2009-03-12 17:39:37 +01:00
|
|
|
* BIOS is expected to clear MtrrFixDramModEn bit, see for example
|
|
|
|
* "BIOS and Kernel Developer's Guide for the AMD Athlon 64 and AMD
|
|
|
|
* Opteron Processors" (26094 Rev. 3.30 February 2006), section
|
|
|
|
* "13.2.1.2 SYSCFG Register": "The MtrrFixDramModEn bit should be set
|
2016-02-23 15:34:30 -08:00
|
|
|
* to 1 during BIOS initialization of the fixed MTRRs, then cleared to
|
2009-03-12 17:39:37 +01:00
|
|
|
* 0 for operation."
|
|
|
|
*/
|
|
|
|
static inline void k8_check_syscfg_dram_mod_en(void)
|
|
|
|
{
|
|
|
|
u32 lo, hi;
|
|
|
|
|
|
|
|
if (!((boot_cpu_data.x86_vendor == X86_VENDOR_AMD) &&
|
|
|
|
(boot_cpu_data.x86 >= 0x0f)))
|
|
|
|
return;
|
|
|
|
|
2024-03-27 16:43:17 +01:00
|
|
|
if (cc_platform_has(CC_ATTR_HOST_SEV_SNP))
|
2024-01-25 22:11:05 -06:00
|
|
|
return;
|
|
|
|
|
2021-04-27 06:16:36 -05:00
|
|
|
rdmsr(MSR_AMD64_SYSCFG, lo, hi);
|
2009-03-12 17:39:37 +01:00
|
|
|
if (lo & K8_MTRRFIXRANGE_DRAM_MODIFY) {
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_err(FW_WARN "MTRR: CPU %u: SYSCFG[MtrrFixDramModEn]"
|
2009-03-12 17:39:37 +01:00
|
|
|
" not cleared by BIOS, clearing this bit\n",
|
|
|
|
smp_processor_id());
|
|
|
|
lo &= ~K8_MTRRFIXRANGE_DRAM_MODIFY;
|
2021-04-27 06:16:36 -05:00
|
|
|
mtrr_wrmsr(MSR_AMD64_SYSCFG, lo, hi);
|
2009-03-12 17:39:37 +01:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-09-10 15:55:50 -07:00
|
|
|
/* Get the size of contiguous MTRR range */
|
|
|
|
static u64 get_mtrr_size(u64 mask)
|
|
|
|
{
|
|
|
|
u64 size;
|
|
|
|
|
2023-05-02 14:09:17 +02:00
|
|
|
mask |= (u64)phys_hi_rsvd << 32;
|
2010-09-10 15:55:50 -07:00
|
|
|
size = -mask;
|
2023-05-02 14:09:17 +02:00
|
|
|
|
2010-09-10 15:55:50 -07:00
|
|
|
return size;
|
|
|
|
}
|
|
|
|
|
2023-05-02 14:09:26 +02:00
|
|
|
static u8 get_var_mtrr_state(unsigned int reg, u64 *start, u64 *size)
|
|
|
|
{
|
|
|
|
struct mtrr_var_range *mtrr = mtrr_state.var_ranges + reg;
|
|
|
|
|
|
|
|
if (!(mtrr->mask_lo & MTRR_PHYSMASK_V))
|
|
|
|
return MTRR_TYPE_INVALID;
|
|
|
|
|
|
|
|
*start = (((u64)mtrr->base_hi) << 32) + (mtrr->base_lo & PAGE_MASK);
|
|
|
|
*size = get_mtrr_size((((u64)mtrr->mask_hi) << 32) +
|
|
|
|
(mtrr->mask_lo & PAGE_MASK));
|
|
|
|
|
|
|
|
return mtrr->base_lo & MTRR_PHYSBASE_TYPE;
|
|
|
|
}
|
|
|
|
|
2023-05-02 14:09:25 +02:00
|
|
|
static u8 get_effective_type(u8 type1, u8 type2)
|
|
|
|
{
|
|
|
|
if (type1 == MTRR_TYPE_UNCACHABLE || type2 == MTRR_TYPE_UNCACHABLE)
|
|
|
|
return MTRR_TYPE_UNCACHABLE;
|
|
|
|
|
|
|
|
if ((type1 == MTRR_TYPE_WRBACK && type2 == MTRR_TYPE_WRTHROUGH) ||
|
|
|
|
(type1 == MTRR_TYPE_WRTHROUGH && type2 == MTRR_TYPE_WRBACK))
|
|
|
|
return MTRR_TYPE_WRTHROUGH;
|
|
|
|
|
|
|
|
if (type1 != type2)
|
|
|
|
return MTRR_TYPE_UNCACHABLE;
|
|
|
|
|
|
|
|
return type1;
|
|
|
|
}
|
|
|
|
|
2023-05-02 14:09:26 +02:00
|
|
|
static void rm_map_entry_at(int idx)
|
|
|
|
{
|
|
|
|
cache_map_n--;
|
|
|
|
if (cache_map_n > idx) {
|
|
|
|
memmove(cache_map + idx, cache_map + idx + 1,
|
|
|
|
sizeof(*cache_map) * (cache_map_n - idx));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add an entry into cache_map at a specific index. Merges adjacent entries if
|
|
|
|
* appropriate. Return the number of merges for correcting the scan index
|
|
|
|
* (this is needed as merging will reduce the number of entries, which will
|
|
|
|
* result in skipping entries in future iterations if the scan index isn't
|
|
|
|
* corrected).
|
|
|
|
* Note that the corrected index can never go below -1 (resulting in being 0 in
|
|
|
|
* the next scan iteration), as "2" is returned only if the current index is
|
|
|
|
* larger than zero.
|
|
|
|
*/
|
|
|
|
static int add_map_entry_at(u64 start, u64 end, u8 type, int idx)
|
|
|
|
{
|
|
|
|
bool merge_prev = false, merge_next = false;
|
|
|
|
|
|
|
|
if (start >= end)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (idx > 0) {
|
|
|
|
struct cache_map *prev = cache_map + idx - 1;
|
|
|
|
|
|
|
|
if (!prev->fixed && start == prev->end && type == prev->type)
|
|
|
|
merge_prev = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (idx < cache_map_n) {
|
|
|
|
struct cache_map *next = cache_map + idx;
|
|
|
|
|
|
|
|
if (!next->fixed && end == next->start && type == next->type)
|
|
|
|
merge_next = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (merge_prev && merge_next) {
|
|
|
|
cache_map[idx - 1].end = cache_map[idx].end;
|
|
|
|
rm_map_entry_at(idx);
|
|
|
|
return 2;
|
|
|
|
}
|
|
|
|
if (merge_prev) {
|
|
|
|
cache_map[idx - 1].end = end;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
if (merge_next) {
|
|
|
|
cache_map[idx].start = start;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Sanity check: the array should NEVER be too small! */
|
|
|
|
if (cache_map_n == cache_map_size) {
|
|
|
|
WARN(1, "MTRR cache mode memory map exhausted!\n");
|
|
|
|
cache_map_n = cache_map_fixed;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cache_map_n > idx) {
|
|
|
|
memmove(cache_map + idx + 1, cache_map + idx,
|
|
|
|
sizeof(*cache_map) * (cache_map_n - idx));
|
|
|
|
}
|
|
|
|
|
|
|
|
cache_map[idx].start = start;
|
|
|
|
cache_map[idx].end = end;
|
|
|
|
cache_map[idx].type = type;
|
|
|
|
cache_map[idx].fixed = 0;
|
|
|
|
cache_map_n++;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clear a part of an entry. Return 1 if start of entry is still valid. */
|
|
|
|
static int clr_map_range_at(u64 start, u64 end, int idx)
|
|
|
|
{
|
|
|
|
int ret = start != cache_map[idx].start;
|
|
|
|
u64 tmp;
|
|
|
|
|
|
|
|
if (start == cache_map[idx].start && end == cache_map[idx].end) {
|
|
|
|
rm_map_entry_at(idx);
|
|
|
|
} else if (start == cache_map[idx].start) {
|
|
|
|
cache_map[idx].start = end;
|
|
|
|
} else if (end == cache_map[idx].end) {
|
|
|
|
cache_map[idx].end = start;
|
|
|
|
} else {
|
|
|
|
tmp = cache_map[idx].end;
|
|
|
|
cache_map[idx].end = start;
|
|
|
|
add_map_entry_at(end, tmp, cache_map[idx].type, idx + 1);
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add MTRR to the map. The current map is scanned and each part of the MTRR
|
|
|
|
* either overlapping with an existing entry or with a hole in the map is
|
|
|
|
* handled separately.
|
|
|
|
*/
|
|
|
|
static void add_map_entry(u64 start, u64 end, u8 type)
|
|
|
|
{
|
|
|
|
u8 new_type, old_type;
|
|
|
|
u64 tmp;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
for (i = 0; i < cache_map_n && start < end; i++) {
|
|
|
|
if (start >= cache_map[i].end)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (start < cache_map[i].start) {
|
|
|
|
/* Region start has no overlap. */
|
|
|
|
tmp = min(end, cache_map[i].start);
|
|
|
|
i -= add_map_entry_at(start, tmp, type, i);
|
|
|
|
start = tmp;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
new_type = get_effective_type(type, cache_map[i].type);
|
|
|
|
old_type = cache_map[i].type;
|
|
|
|
|
|
|
|
if (cache_map[i].fixed || new_type == old_type) {
|
|
|
|
/* Cut off start of new entry. */
|
|
|
|
start = cache_map[i].end;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Handle only overlapping part of region. */
|
|
|
|
tmp = min(end, cache_map[i].end);
|
|
|
|
i += clr_map_range_at(start, tmp, i);
|
|
|
|
i -= add_map_entry_at(start, tmp, new_type, i);
|
|
|
|
start = tmp;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Add rest of region after last map entry (rest might be empty). */
|
|
|
|
add_map_entry_at(start, end, type, i);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Add variable MTRRs to cache map. */
|
|
|
|
static void map_add_var(void)
|
|
|
|
{
|
|
|
|
u64 start, size;
|
|
|
|
unsigned int i;
|
|
|
|
u8 type;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Add AMD TOP_MEM2 area. Can't be added in mtrr_build_map(), as it
|
|
|
|
* needs to be added again when rebuilding the map due to potentially
|
|
|
|
* having moved as a result of variable MTRRs for memory below 4GB.
|
|
|
|
*/
|
|
|
|
if (mtrr_tom2) {
|
|
|
|
add_map_entry(BIT_ULL(32), mtrr_tom2, MTRR_TYPE_WRBACK);
|
|
|
|
cache_map[cache_map_n - 1].fixed = 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < num_var_ranges; i++) {
|
|
|
|
type = get_var_mtrr_state(i, &start, &size);
|
|
|
|
if (type != MTRR_TYPE_INVALID)
|
|
|
|
add_map_entry(start, start + size, type);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Rebuild map by replacing variable entries. Needs to be called when MTRR
|
|
|
|
* registers are being changed after boot, as such changes could include
|
|
|
|
* removals of registers, which are complicated to handle without rebuild of
|
|
|
|
* the map.
|
|
|
|
*/
|
|
|
|
void generic_rebuild_map(void)
|
|
|
|
{
|
|
|
|
if (mtrr_if != &generic_mtrr_ops)
|
|
|
|
return;
|
|
|
|
|
|
|
|
cache_map_n = cache_map_fixed;
|
|
|
|
|
|
|
|
map_add_var();
|
|
|
|
}
|
|
|
|
|
|
|
|
static unsigned int __init get_cache_map_size(void)
|
|
|
|
{
|
|
|
|
return cache_map_fixed + 2 * num_var_ranges + (mtrr_tom2 != 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Build the cache_map containing the cache modes per memory range. */
|
|
|
|
void __init mtrr_build_map(void)
|
|
|
|
{
|
|
|
|
u64 start, end, size;
|
|
|
|
unsigned int i;
|
|
|
|
u8 type;
|
|
|
|
|
|
|
|
/* Add fixed MTRRs, optimize for adjacent entries with same type. */
|
|
|
|
if (mtrr_state.enabled & MTRR_STATE_MTRR_FIXED_ENABLED) {
|
|
|
|
/*
|
|
|
|
* Start with 64k size fixed entries, preset 1st one (hence the
|
|
|
|
* loop below is starting with index 1).
|
|
|
|
*/
|
|
|
|
start = 0;
|
|
|
|
end = size = 0x10000;
|
|
|
|
type = mtrr_state.fixed_ranges[0];
|
|
|
|
|
|
|
|
for (i = 1; i < MTRR_NUM_FIXED_RANGES; i++) {
|
|
|
|
/* 8 64k entries, then 16 16k ones, rest 4k. */
|
|
|
|
if (i == 8 || i == 24)
|
|
|
|
size >>= 2;
|
|
|
|
|
|
|
|
if (mtrr_state.fixed_ranges[i] != type) {
|
|
|
|
add_map_entry(start, end, type);
|
|
|
|
start = end;
|
|
|
|
type = mtrr_state.fixed_ranges[i];
|
|
|
|
}
|
|
|
|
end += size;
|
|
|
|
}
|
|
|
|
add_map_entry(start, end, type);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Mark fixed, they take precedence. */
|
|
|
|
for (i = 0; i < cache_map_n; i++)
|
|
|
|
cache_map[i].fixed = 1;
|
|
|
|
cache_map_fixed = cache_map_n;
|
|
|
|
|
|
|
|
map_add_var();
|
|
|
|
|
|
|
|
pr_info("MTRR map: %u entries (%u fixed + %u variable; max %u), built from %u variable MTRRs\n",
|
|
|
|
cache_map_n, cache_map_fixed, cache_map_n - cache_map_fixed,
|
|
|
|
get_cache_map_size(), num_var_ranges + (mtrr_tom2 != 0));
|
2023-05-02 14:09:27 +02:00
|
|
|
|
|
|
|
if (mtrr_debug) {
|
|
|
|
for (i = 0; i < cache_map_n; i++) {
|
|
|
|
pr_info("%3u: %016llx-%016llx %s\n", i,
|
|
|
|
cache_map[i].start, cache_map[i].end - 1,
|
|
|
|
mtrr_attrib_to_str(cache_map[i].type));
|
|
|
|
}
|
|
|
|
}
|
2023-05-02 14:09:26 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Copy the cache_map from __initdata memory to dynamically allocated one. */
|
|
|
|
void __init mtrr_copy_map(void)
|
|
|
|
{
|
|
|
|
unsigned int new_size = get_cache_map_size();
|
|
|
|
|
|
|
|
if (!mtrr_state.enabled || !new_size) {
|
|
|
|
cache_map = NULL;
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_lock(&mtrr_mutex);
|
|
|
|
|
|
|
|
cache_map = kcalloc(new_size, sizeof(*cache_map), GFP_KERNEL);
|
|
|
|
if (cache_map) {
|
|
|
|
memmove(cache_map, init_cache_map,
|
|
|
|
cache_map_n * sizeof(*cache_map));
|
|
|
|
cache_map_size = new_size;
|
|
|
|
} else {
|
|
|
|
mtrr_state.enabled = 0;
|
|
|
|
pr_err("MTRRs disabled due to allocation failure for lookup map.\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&mtrr_mutex);
|
2008-03-18 17:00:14 -07:00
|
|
|
}
|
|
|
|
|
2023-05-02 14:09:18 +02:00
|
|
|
/**
|
2024-12-02 09:31:39 +02:00
|
|
|
* guest_force_mtrr_state - set static MTRR state for a guest
|
2023-05-02 14:09:18 +02:00
|
|
|
*
|
|
|
|
* Used to set MTRR state via different means (e.g. with data obtained from
|
|
|
|
* a hypervisor).
|
|
|
|
* Is allowed only for special cases when running virtualized. Must be called
|
|
|
|
* from the x86_init.hyper.init_platform() hook. It can be called only once.
|
|
|
|
* The MTRR state can't be changed afterwards. To ensure that, X86_FEATURE_MTRR
|
|
|
|
* is cleared.
|
2023-11-13 14:52:52 +01:00
|
|
|
*
|
|
|
|
* @var: MTRR variable range array to use
|
|
|
|
* @num_var: length of the @var array
|
|
|
|
* @def_type: default caching type
|
2023-05-02 14:09:18 +02:00
|
|
|
*/
|
2024-12-02 09:31:39 +02:00
|
|
|
void guest_force_mtrr_state(struct mtrr_var_range *var, unsigned int num_var,
|
|
|
|
mtrr_type def_type)
|
2023-05-02 14:09:18 +02:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
/* Only allowed to be called once before mtrr_bp_init(). */
|
|
|
|
if (WARN_ON_ONCE(mtrr_state_set))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Only allowed when running virtualized. */
|
|
|
|
if (!cpu_feature_enabled(X86_FEATURE_HYPERVISOR))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only allowed for special virtualization cases:
|
|
|
|
* - when running as Hyper-V, SEV-SNP guest using vTOM
|
|
|
|
* - when running as Xen PV guest
|
|
|
|
* - when running as SEV-SNP or TDX guest to avoid unnecessary
|
|
|
|
* VMM communication/Virtualization exceptions (#VC, #VE)
|
|
|
|
*/
|
|
|
|
if (!cc_platform_has(CC_ATTR_GUEST_SEV_SNP) &&
|
|
|
|
!hv_is_isolation_supported() &&
|
|
|
|
!cpu_feature_enabled(X86_FEATURE_XENPV) &&
|
|
|
|
!cpu_feature_enabled(X86_FEATURE_TDX_GUEST))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Disable MTRR in order to disable MTRR modifications. */
|
|
|
|
setup_clear_cpu_cap(X86_FEATURE_MTRR);
|
|
|
|
|
|
|
|
if (var) {
|
|
|
|
if (num_var > MTRR_MAX_VAR_RANGES) {
|
|
|
|
pr_warn("Trying to overwrite MTRR state with %u variable entries\n",
|
|
|
|
num_var);
|
|
|
|
num_var = MTRR_MAX_VAR_RANGES;
|
|
|
|
}
|
|
|
|
for (i = 0; i < num_var; i++)
|
|
|
|
mtrr_state.var_ranges[i] = var[i];
|
|
|
|
num_var_ranges = num_var;
|
|
|
|
}
|
|
|
|
|
|
|
|
mtrr_state.def_type = def_type;
|
|
|
|
mtrr_state.enabled |= MTRR_STATE_MTRR_ENABLED;
|
|
|
|
|
|
|
|
mtrr_state_set = 1;
|
|
|
|
}
|
|
|
|
|
2023-05-02 14:09:28 +02:00
|
|
|
static u8 type_merge(u8 type, u8 new_type, u8 *uniform)
|
|
|
|
{
|
|
|
|
u8 effective_type;
|
|
|
|
|
|
|
|
if (type == MTRR_TYPE_INVALID)
|
|
|
|
return new_type;
|
|
|
|
|
|
|
|
effective_type = get_effective_type(type, new_type);
|
|
|
|
if (type != effective_type)
|
|
|
|
*uniform = 0;
|
|
|
|
|
|
|
|
return effective_type;
|
|
|
|
}
|
|
|
|
|
2015-05-26 10:28:08 +02:00
|
|
|
/**
|
|
|
|
* mtrr_type_lookup - look up memory type in MTRR
|
|
|
|
*
|
2023-11-13 14:52:52 +01:00
|
|
|
* @start: Begin of the physical address range
|
|
|
|
* @end: End of the physical address range
|
|
|
|
* @uniform: output argument:
|
|
|
|
* - 1: the returned MTRR type is valid for the whole region
|
|
|
|
* - 0: otherwise
|
|
|
|
*
|
2015-05-26 10:28:08 +02:00
|
|
|
* Return Values:
|
|
|
|
* MTRR_TYPE_(type) - The effective MTRR type for the region
|
|
|
|
* MTRR_TYPE_INVALID - MTRR is disabled
|
2010-09-10 15:55:50 -07:00
|
|
|
*/
|
2015-05-26 10:28:10 +02:00
|
|
|
u8 mtrr_type_lookup(u64 start, u64 end, u8 *uniform)
|
2010-09-10 15:55:50 -07:00
|
|
|
{
|
2023-05-02 14:09:28 +02:00
|
|
|
u8 type = MTRR_TYPE_INVALID;
|
|
|
|
unsigned int i;
|
x86/mtrr: Correct the range check before performing MTRR type lookups
In mtrr_type_lookup(), if the input memory address region is not in the
MTRR, over 4GB, and not over the top of memory, a write-back attribute
is returned. These condition checks are for ensuring the input memory
address region is actually mapped to the physical memory.
However, if the end address is just aligned with the top of memory,
the condition check treats the address is over the top of memory, and
write-back attribute is not returned.
And this hits in a real use case with NVDIMM: the nd_pmem module tries
to map NVDIMMs as cacheable memories when NVDIMMs are connected. If a
NVDIMM is the last of the DIMMs, the performance of this NVDIMM becomes
very low since it is aligned with the top of memory and its memory type
is uncached-minus.
Move the input end address change to inclusive up into
mtrr_type_lookup(), before checking for the top of memory in either
mtrr_type_lookup_{variable,fixed}() helpers.
[ bp: Massage commit message. ]
Fixes: 0cc705f56e40 ("x86/mm/mtrr: Clean up mtrr_type_lookup()")
Signed-off-by: Ying-Tsun Huang <ying-tsun.huang@amd.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Link: https://lkml.kernel.org/r/20201215070721.4349-1-ying-tsun.huang@amd.com
2020-12-15 15:07:20 +08:00
|
|
|
|
2023-05-02 14:09:28 +02:00
|
|
|
if (!mtrr_state_set) {
|
|
|
|
/* Uniformity is unknown. */
|
|
|
|
*uniform = 0;
|
2023-05-02 14:09:29 +02:00
|
|
|
return MTRR_TYPE_UNCACHABLE;
|
2023-05-02 14:09:28 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
*uniform = 1;
|
2015-05-26 10:28:08 +02:00
|
|
|
|
|
|
|
if (!(mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED))
|
2023-05-02 14:09:29 +02:00
|
|
|
return MTRR_TYPE_UNCACHABLE;
|
2015-05-26 10:28:08 +02:00
|
|
|
|
2023-05-02 14:09:28 +02:00
|
|
|
for (i = 0; i < cache_map_n && start < end; i++) {
|
|
|
|
/* Region after current map entry? -> continue with next one. */
|
|
|
|
if (start >= cache_map[i].end)
|
|
|
|
continue;
|
2015-05-26 10:28:08 +02:00
|
|
|
|
2023-05-02 14:09:28 +02:00
|
|
|
/* Start of region not covered by current map entry? */
|
|
|
|
if (start < cache_map[i].start) {
|
|
|
|
/* At least some part of region has default type. */
|
|
|
|
type = type_merge(type, mtrr_state.def_type, uniform);
|
|
|
|
/* End of region not covered, too? -> lookup done. */
|
|
|
|
if (end <= cache_map[i].start)
|
|
|
|
return type;
|
|
|
|
}
|
2010-09-10 15:55:50 -07:00
|
|
|
|
2023-05-02 14:09:28 +02:00
|
|
|
/* At least part of region covered by map entry. */
|
|
|
|
type = type_merge(type, cache_map[i].type, uniform);
|
|
|
|
|
|
|
|
start = cache_map[i].end;
|
2010-09-10 15:55:50 -07:00
|
|
|
}
|
|
|
|
|
2023-05-02 14:09:28 +02:00
|
|
|
/* End of region past last entry in map? -> use default type. */
|
|
|
|
if (start < end)
|
|
|
|
type = type_merge(type, mtrr_state.def_type, uniform);
|
2015-05-26 10:28:08 +02:00
|
|
|
|
2010-09-10 15:55:50 -07:00
|
|
|
return type;
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/* Get the MSR pair relating to a var range */
|
2007-06-20 12:23:39 +02:00
|
|
|
static void
|
2005-04-16 15:20:36 -07: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);
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/* Fill the MSR pair relating to a var range */
|
2008-04-29 03:52:33 -07:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
static void get_fixed_ranges(mtrr_type *frs)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2009-07-04 07:53:00 +05:30
|
|
|
unsigned int *p = (unsigned int *)frs;
|
2005-04-16 15:20:36 -07:00
|
|
|
int i;
|
|
|
|
|
2009-03-12 17:39:37 +01:00
|
|
|
k8_check_syscfg_dram_mod_en();
|
|
|
|
|
2009-05-14 12:10:43 +05:30
|
|
|
rdmsr(MSR_MTRRfix64K_00000, p[0], p[1]);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
for (i = 0; i < 2; i++)
|
2009-05-14 12:15:32 +05:30
|
|
|
rdmsr(MSR_MTRRfix16K_80000 + i, p[2 + i * 2], p[3 + i * 2]);
|
2005-04-16 15:20:36 -07:00
|
|
|
for (i = 0; i < 8; i++)
|
2009-05-14 12:29:25 +05:30
|
|
|
rdmsr(MSR_MTRRfix4K_C0000 + i, p[6 + i * 2], p[7 + i * 2]);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2007-05-02 19:27:17 +02:00
|
|
|
void mtrr_save_fixed_ranges(void *info)
|
|
|
|
{
|
2025-05-09 17:06:33 +00:00
|
|
|
if (mtrr_state.have_fixed)
|
2007-07-01 12:06:48 -07:00
|
|
|
get_fixed_ranges(mtrr_state.fixed_ranges);
|
2007-05-02 19:27:17 +02:00
|
|
|
}
|
|
|
|
|
2009-03-13 14:08:49 -07:00
|
|
|
static unsigned __initdata last_fixed_start;
|
|
|
|
static unsigned __initdata last_fixed_end;
|
|
|
|
static mtrr_type __initdata last_fixed_type;
|
|
|
|
|
|
|
|
static void __init print_fixed_last(void)
|
|
|
|
{
|
|
|
|
if (!last_fixed_end)
|
|
|
|
return;
|
|
|
|
|
2023-05-02 14:09:27 +02:00
|
|
|
pr_info(" %05X-%05X %s\n", last_fixed_start,
|
|
|
|
last_fixed_end - 1, mtrr_attrib_to_str(last_fixed_type));
|
2009-03-13 14:08:49 -07:00
|
|
|
|
|
|
|
last_fixed_end = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __init update_fixed_last(unsigned base, unsigned end,
|
2009-07-04 07:53:00 +05:30
|
|
|
mtrr_type type)
|
2009-03-13 14:08:49 -07:00
|
|
|
{
|
|
|
|
last_fixed_start = base;
|
|
|
|
last_fixed_end = end;
|
|
|
|
last_fixed_type = type;
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
static void __init
|
|
|
|
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-07 02:14:09 +01:00
|
|
|
{
|
|
|
|
unsigned i;
|
|
|
|
|
2009-03-13 14:08:49 -07:00
|
|
|
for (i = 0; i < 8; ++i, ++types, base += step) {
|
|
|
|
if (last_fixed_end == 0) {
|
|
|
|
update_fixed_last(base, base + step, *types);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
if (last_fixed_end == base && last_fixed_type == *types) {
|
|
|
|
last_fixed_end = base + step;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* new segments: gap or different type */
|
|
|
|
print_fixed_last();
|
|
|
|
update_fixed_last(base, base + step, *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-07 02:14:09 +01:00
|
|
|
}
|
|
|
|
|
2009-03-12 18:43:54 -07:00
|
|
|
static void __init print_mtrr_state(void)
|
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
int high_width;
|
|
|
|
|
2023-05-02 14:09:27 +02:00
|
|
|
pr_info("MTRR default type: %s\n",
|
|
|
|
mtrr_attrib_to_str(mtrr_state.def_type));
|
2009-03-12 18:43:54 -07:00
|
|
|
if (mtrr_state.have_fixed) {
|
2025-01-17 15:48:59 +01:00
|
|
|
pr_info("MTRR fixed ranges %s:\n",
|
|
|
|
str_enabled_disabled(
|
|
|
|
(mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED) &&
|
|
|
|
(mtrr_state.enabled & MTRR_STATE_MTRR_FIXED_ENABLED)));
|
2009-03-12 18:43:54 -07:00
|
|
|
print_fixed(0x00000, 0x10000, mtrr_state.fixed_ranges + 0);
|
|
|
|
for (i = 0; i < 2; ++i)
|
2009-07-04 07:53:00 +05:30
|
|
|
print_fixed(0x80000 + i * 0x20000, 0x04000,
|
|
|
|
mtrr_state.fixed_ranges + (i + 1) * 8);
|
2009-03-12 18:43:54 -07:00
|
|
|
for (i = 0; i < 8; ++i)
|
2009-07-04 07:53:00 +05:30
|
|
|
print_fixed(0xC0000 + i * 0x08000, 0x01000,
|
|
|
|
mtrr_state.fixed_ranges + (i + 3) * 8);
|
2009-03-13 14:08:49 -07:00
|
|
|
|
|
|
|
/* tail */
|
|
|
|
print_fixed_last();
|
2009-03-12 18:43:54 -07:00
|
|
|
}
|
2025-01-17 15:48:59 +01:00
|
|
|
pr_info("MTRR variable ranges %s:\n",
|
|
|
|
str_enabled_disabled(mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED));
|
2023-05-02 14:09:16 +02:00
|
|
|
high_width = (boot_cpu_data.x86_phys_bits - (32 - PAGE_SHIFT) + 3) / 4;
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2009-03-12 18:43:54 -07:00
|
|
|
for (i = 0; i < num_var_ranges; ++i) {
|
2023-05-02 14:09:17 +02:00
|
|
|
if (mtrr_state.var_ranges[i].mask_lo & MTRR_PHYSMASK_V)
|
2023-05-02 14:09:27 +02:00
|
|
|
pr_info(" %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 &
|
2023-05-02 14:09:17 +02:00
|
|
|
MTRR_PHYSBASE_TYPE));
|
2009-03-12 18:43:54 -07:00
|
|
|
else
|
2023-05-02 14:09:27 +02:00
|
|
|
pr_info(" %u disabled\n", i);
|
2009-03-12 18:43:54 -07:00
|
|
|
}
|
2009-07-04 07:53:00 +05:30
|
|
|
if (mtrr_tom2)
|
2023-05-02 14:09:27 +02:00
|
|
|
pr_info("TOM2: %016llx aka %lldM\n", mtrr_tom2, mtrr_tom2>>20);
|
2009-03-12 18:43:54 -07:00
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/* Grab all of the MTRR state for this CPU into *state */
|
x86/mm/mtrr: Generalize runtime disabling of MTRRs
It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT and end
up with a system with MTRR functionality disabled but PAT
functionality enabled. This can happen, for instance, when the
Xen hypervisor is used where MTRRs are not supported but PAT is.
This can happen on Linux as of commit
47591df50512 ("xen: Support Xen pv-domains using PAT")
by Juergen, introduced in v3.19.
Technically, we should assume the proper CPU bits would be set
to disable MTRRs but we can't always rely on this. At least on
the Xen Hypervisor, for instance, only X86_FEATURE_MTRR was
disabled as of Xen 4.4 through Xen commit 586ab6a [0], but not
X86_FEATURE_K6_MTRR, X86_FEATURE_CENTAUR_MCR, or
X86_FEATURE_CYRIX_ARR for instance.
Roger Pau Monné has clarified though that although this is
technically true we will never support PVH on these CPU types so
Xen has no need to disable these bits on those systems. As per
Roger, AMD K6, Centaur and VIA chips don't have the necessary
hardware extensions to allow running PVH guests [1].
As per Toshi it is also possible for the BIOS to disable MTRR
support, in such cases get_mtrr_state() would update the MTRR
state as per the BIOS, we need to propagate this information as
well.
x86 MTRR code relies on quite a bit of checks for mtrr_if being
set to check to see if MTRRs did get set up. Instead, lets
provide a generic getter for that. This also adds a few checks
where they were not before which could potentially safeguard
ourselves against incorrect usage of MTRR where this was not
desirable.
Where possible match error codes as if MTRRs were disabled on
arch/x86/include/asm/mtrr.h.
Lastly, since disabling MTRRs can happen at run time and we
could end up with PAT enabled, best record now in our logs when
MTRRs are disabled.
[0] ~/devel/xen (git::stable-4.5)$ git describe --contains 586ab6a 4.4.0-rc1~18
[1] http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg03460.html
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: Stefan Bader <stefan.bader@canonical.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: bhelgaas@google.com
Cc: david.vrabel@citrix.com
Cc: jbeulich@suse.com
Cc: konrad.wilk@oracle.com
Cc: venkatesh.pallipadi@intel.com
Cc: ville.syrjala@linux.intel.com
Cc: xen-devel@lists.xensource.com
Link: http://lkml.kernel.org/r/1426893517-2511-3-git-send-email-mcgrof@do-not-panic.com
Link: http://lkml.kernel.org/r/1432628901-18044-12-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-26 10:28:14 +02:00
|
|
|
bool __init get_mtrr_state(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
struct mtrr_var_range *vrs;
|
2009-07-04 07:53:00 +05:30
|
|
|
unsigned lo, dummy;
|
|
|
|
unsigned int i;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
vrs = mtrr_state.var_ranges;
|
|
|
|
|
2009-05-14 12:06:12 +05:30
|
|
|
rdmsr(MSR_MTRRcap, lo, dummy);
|
2023-05-02 14:09:17 +02:00
|
|
|
mtrr_state.have_fixed = lo & MTRR_CAP_FIX;
|
[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-07 02:14:09 +01:00
|
|
|
|
2005-04-16 15:20:36 -07: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-07 02:14:09 +01:00
|
|
|
if (mtrr_state.have_fixed)
|
|
|
|
get_fixed_ranges(mtrr_state.fixed_ranges);
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-05-14 12:35:46 +05:30
|
|
|
rdmsr(MSR_MTRRdefType, lo, dummy);
|
2023-05-02 14:09:17 +02:00
|
|
|
mtrr_state.def_type = lo & MTRR_DEF_TYPE_TYPE;
|
|
|
|
mtrr_state.enabled = (lo & MTRR_DEF_TYPE_ENABLE) >> MTRR_STATE_SHIFT;
|
[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-07 02:14:09 +01:00
|
|
|
|
2008-03-24 16:02:01 -07:00
|
|
|
if (amd_special_default_mtrr()) {
|
2008-04-30 20:11:51 +02:00
|
|
|
unsigned low, high;
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2008-03-24 16:02:01 -07:00
|
|
|
/* TOP_MEM2 */
|
2008-04-30 20:11:51 +02:00
|
|
|
rdmsr(MSR_K8_TOP_MEM2, low, high);
|
2008-04-29 03:52:33 -07:00
|
|
|
mtrr_tom2 = high;
|
|
|
|
mtrr_tom2 <<= 32;
|
|
|
|
mtrr_tom2 |= low;
|
2008-05-12 17:40:39 -07:00
|
|
|
mtrr_tom2 &= 0xffffff800000ULL;
|
2008-03-24 16:02:01 -07:00
|
|
|
}
|
2009-03-12 18:43:54 -07:00
|
|
|
|
2023-05-02 14:09:27 +02:00
|
|
|
if (mtrr_debug)
|
|
|
|
print_mtrr_state();
|
2009-03-12 18:43:54 -07:00
|
|
|
|
2008-03-18 17:00:14 -07:00
|
|
|
mtrr_state_set = 1;
|
|
|
|
|
x86/mm/mtrr: Generalize runtime disabling of MTRRs
It is possible to enable CONFIG_MTRR and CONFIG_X86_PAT and end
up with a system with MTRR functionality disabled but PAT
functionality enabled. This can happen, for instance, when the
Xen hypervisor is used where MTRRs are not supported but PAT is.
This can happen on Linux as of commit
47591df50512 ("xen: Support Xen pv-domains using PAT")
by Juergen, introduced in v3.19.
Technically, we should assume the proper CPU bits would be set
to disable MTRRs but we can't always rely on this. At least on
the Xen Hypervisor, for instance, only X86_FEATURE_MTRR was
disabled as of Xen 4.4 through Xen commit 586ab6a [0], but not
X86_FEATURE_K6_MTRR, X86_FEATURE_CENTAUR_MCR, or
X86_FEATURE_CYRIX_ARR for instance.
Roger Pau Monné has clarified though that although this is
technically true we will never support PVH on these CPU types so
Xen has no need to disable these bits on those systems. As per
Roger, AMD K6, Centaur and VIA chips don't have the necessary
hardware extensions to allow running PVH guests [1].
As per Toshi it is also possible for the BIOS to disable MTRR
support, in such cases get_mtrr_state() would update the MTRR
state as per the BIOS, we need to propagate this information as
well.
x86 MTRR code relies on quite a bit of checks for mtrr_if being
set to check to see if MTRRs did get set up. Instead, lets
provide a generic getter for that. This also adds a few checks
where they were not before which could potentially safeguard
ourselves against incorrect usage of MTRR where this was not
desirable.
Where possible match error codes as if MTRRs were disabled on
arch/x86/include/asm/mtrr.h.
Lastly, since disabling MTRRs can happen at run time and we
could end up with PAT enabled, best record now in our logs when
MTRRs are disabled.
[0] ~/devel/xen (git::stable-4.5)$ git describe --contains 586ab6a 4.4.0-rc1~18
[1] http://lists.xenproject.org/archives/html/xen-devel/2015-03/msg03460.html
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Antonino Daplas <adaplas@gmail.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Dave Airlie <airlied@redhat.com>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Davidlohr Bueso <dbueso@suse.de>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jean-Christophe Plagniol-Villard <plagnioj@jcrosoft.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Roger Pau Monné <roger.pau@citrix.com>
Cc: Stefan Bader <stefan.bader@canonical.com>
Cc: Suresh Siddha <sbsiddha@gmail.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Ville Syrjälä <syrjala@sci.fi>
Cc: Vlastimil Babka <vbabka@suse.cz>
Cc: bhelgaas@google.com
Cc: david.vrabel@citrix.com
Cc: jbeulich@suse.com
Cc: konrad.wilk@oracle.com
Cc: venkatesh.pallipadi@intel.com
Cc: ville.syrjala@linux.intel.com
Cc: xen-devel@lists.xensource.com
Link: http://lkml.kernel.org/r/1426893517-2511-3-git-send-email-mcgrof@do-not-panic.com
Link: http://lkml.kernel.org/r/1432628901-18044-12-git-send-email-bp@alien8.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2015-05-26 10:28:14 +02:00
|
|
|
return !!(mtrr_state.enabled & MTRR_STATE_MTRR_ENABLED);
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/* Some BIOS's are messed up and don't set all MTRRs the same! */
|
2005-04-16 15:20:36 -07:00
|
|
|
void __init mtrr_state_warn(void)
|
|
|
|
{
|
|
|
|
unsigned long mask = smp_changes_mask;
|
|
|
|
|
|
|
|
if (!mask)
|
|
|
|
return;
|
|
|
|
if (mask & MTRR_CHANGE_MASK_FIXED)
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_warn("mtrr: your CPUs had inconsistent fixed MTRR settings\n");
|
2005-04-16 15:20:36 -07:00
|
|
|
if (mask & MTRR_CHANGE_MASK_VARIABLE)
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_warn("mtrr: your CPUs had inconsistent variable MTRR settings\n");
|
2005-04-16 15:20:36 -07:00
|
|
|
if (mask & MTRR_CHANGE_MASK_DEFTYPE)
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_warn("mtrr: your CPUs had inconsistent MTRRdefType settings\n");
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_info("mtrr: probably your BIOS does not setup all CPUs.\n");
|
|
|
|
pr_info("mtrr: corrected configuration.\n");
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* 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.
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
void mtrr_wrmsr(unsigned msr, unsigned a, unsigned b)
|
|
|
|
{
|
2009-07-04 07:53:00 +05:30
|
|
|
if (wrmsr_safe(msr, a, b) < 0) {
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_err("MTRR: CPU %u: Writing MSR %x to %x:%x failed\n",
|
2005-04-16 15:20:36 -07:00
|
|
|
smp_processor_id(), msr, a, b);
|
2009-07-04 07:53:00 +05:30
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2007-05-02 19:27:17 +02:00
|
|
|
/**
|
2009-07-04 07:53:00 +05:30
|
|
|
* set_fixed_range - checks & updates a fixed-range MTRR if it
|
|
|
|
* differs from the value it should have
|
2008-03-13 16:59:12 -07:00
|
|
|
* @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
|
2007-05-02 19:27:17 +02:00
|
|
|
*/
|
2008-01-30 13:30:31 +01:00
|
|
|
static void set_fixed_range(int msr, bool *changed, unsigned int *msrwords)
|
2007-05-02 19:27:17 +02:00
|
|
|
{
|
|
|
|
unsigned lo, hi;
|
|
|
|
|
|
|
|
rdmsr(msr, lo, hi);
|
|
|
|
|
|
|
|
if (lo != msrwords[0] || hi != msrwords[1]) {
|
|
|
|
mtrr_wrmsr(msr, msrwords[0], msrwords[1]);
|
2008-01-30 13:30:31 +01:00
|
|
|
*changed = true;
|
2007-05-02 19:27:17 +02:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-03-13 16:59:12 -07: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.
|
|
|
|
*/
|
2009-07-04 07:53:00 +05:30
|
|
|
int
|
|
|
|
generic_get_free_region(unsigned long base, unsigned long size, int replace_reg)
|
2005-04-16 15:20:36 -07: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-07 02:14:09 +01:00
|
|
|
unsigned long lbase, lsize;
|
2009-07-04 07:53:00 +05:30
|
|
|
mtrr_type ltype;
|
|
|
|
int i, max;
|
2005-04-16 15:20:36 -07: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-07 02:14:09 +01:00
|
|
|
if (replace_reg >= 0 && replace_reg < max)
|
|
|
|
return replace_reg;
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
for (i = 0; i < max; ++i) {
|
|
|
|
mtrr_if->get(i, &lbase, &lsize, <ype);
|
|
|
|
if (lsize == 0)
|
|
|
|
return i;
|
|
|
|
}
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
return -ENOSPC;
|
|
|
|
}
|
|
|
|
|
2005-05-01 08:59:29 -07: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-07 02:14:09 +01:00
|
|
|
unsigned long *size, mtrr_type *type)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
x86: Fix /proc/mtrr with base/size more than 44bits
On one sytem that mtrr range is more then 44bits, in dmesg we have
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-through
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
[ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
[ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
[ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
[ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
but /proc/mtrr report wrong:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through
reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
so bit 44 and bit 45 get cut off.
We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.
2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.
Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
So When are we going to have size more than 44bits? that is 16TiB.
after patch we have right ouput:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through
reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
-v2: simply checking in mtrr_add_page according to hpa.
[ hpa: This probably wants to go into -stable only after having sat in
mainline for a bit. It is not a regression. ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-06-13 15:33:35 -07:00
|
|
|
u32 mask_lo, mask_hi, base_lo, base_hi;
|
|
|
|
unsigned int hi;
|
|
|
|
u64 tmp, mask;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-12 18:43:54 -07:00
|
|
|
/*
|
|
|
|
* get_mtrr doesn't need to update mtrr_state, also it could be called
|
|
|
|
* from any cpu, so try to print it out directly.
|
|
|
|
*/
|
2010-07-20 15:19:49 -07:00
|
|
|
get_cpu();
|
2009-03-13 12:46:07 -07:00
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
rdmsr(MTRRphysMask_MSR(reg), mask_lo, mask_hi);
|
2009-03-12 18:43:54 -07:00
|
|
|
|
2023-05-02 14:09:17 +02:00
|
|
|
if (!(mask_lo & MTRR_PHYSMASK_V)) {
|
2009-07-04 07:53:00 +05:30
|
|
|
/* Invalid (i.e. free) range */
|
2005-04-16 15:20:36 -07:00
|
|
|
*base = 0;
|
|
|
|
*size = 0;
|
|
|
|
*type = 0;
|
2009-03-13 12:46:07 -07:00
|
|
|
goto out_put_cpu;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
rdmsr(MTRRphysBase_MSR(reg), base_lo, base_hi);
|
|
|
|
|
2009-03-13 12:46:07 -07:00
|
|
|
/* Work out the shifted address mask: */
|
2023-05-02 14:09:17 +02:00
|
|
|
tmp = (u64)mask_hi << 32 | (mask_lo & PAGE_MASK);
|
|
|
|
mask = (u64)phys_hi_rsvd << 32 | tmp;
|
2009-03-13 12:46:07 -07:00
|
|
|
|
|
|
|
/* Expand tmp with high bits to all 1s: */
|
x86: Fix /proc/mtrr with base/size more than 44bits
On one sytem that mtrr range is more then 44bits, in dmesg we have
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-through
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
[ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
[ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
[ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
[ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
but /proc/mtrr report wrong:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through
reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
so bit 44 and bit 45 get cut off.
We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.
2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.
Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
So When are we going to have size more than 44bits? that is 16TiB.
after patch we have right ouput:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through
reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
-v2: simply checking in mtrr_add_page according to hpa.
[ hpa: This probably wants to go into -stable only after having sat in
mainline for a bit. It is not a regression. ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-06-13 15:33:35 -07:00
|
|
|
hi = fls64(tmp);
|
2008-08-21 20:24:24 -07:00
|
|
|
if (hi > 0) {
|
x86: Fix /proc/mtrr with base/size more than 44bits
On one sytem that mtrr range is more then 44bits, in dmesg we have
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-through
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
[ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
[ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
[ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
[ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
but /proc/mtrr report wrong:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through
reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
so bit 44 and bit 45 get cut off.
We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.
2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.
Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
So When are we going to have size more than 44bits? that is 16TiB.
after patch we have right ouput:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through
reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
-v2: simply checking in mtrr_add_page according to hpa.
[ hpa: This probably wants to go into -stable only after having sat in
mainline for a bit. It is not a regression. ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-06-13 15:33:35 -07:00
|
|
|
tmp |= ~((1ULL<<(hi - 1)) - 1);
|
2008-08-21 20:24:24 -07:00
|
|
|
|
x86: Fix /proc/mtrr with base/size more than 44bits
On one sytem that mtrr range is more then 44bits, in dmesg we have
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-through
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
[ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
[ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
[ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
[ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
but /proc/mtrr report wrong:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through
reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
so bit 44 and bit 45 get cut off.
We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.
2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.
Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
So When are we going to have size more than 44bits? that is 16TiB.
after patch we have right ouput:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through
reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
-v2: simply checking in mtrr_add_page according to hpa.
[ hpa: This probably wants to go into -stable only after having sat in
mainline for a bit. It is not a regression. ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-06-13 15:33:35 -07:00
|
|
|
if (tmp != mask) {
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_warn("mtrr: your BIOS has configured an incorrect mask, fixing it.\n");
|
2013-01-21 17:17:39 +10:30
|
|
|
add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
|
x86: Fix /proc/mtrr with base/size more than 44bits
On one sytem that mtrr range is more then 44bits, in dmesg we have
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-through
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
[ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
[ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
[ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
[ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
but /proc/mtrr report wrong:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through
reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
so bit 44 and bit 45 get cut off.
We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.
2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.
Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
So When are we going to have size more than 44bits? that is 16TiB.
after patch we have right ouput:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through
reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
-v2: simply checking in mtrr_add_page according to hpa.
[ hpa: This probably wants to go into -stable only after having sat in
mainline for a bit. It is not a regression. ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-06-13 15:33:35 -07:00
|
|
|
mask = tmp;
|
2008-08-21 20:24:24 -07:00
|
|
|
}
|
|
|
|
}
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-13 12:46:07 -07:00
|
|
|
/*
|
|
|
|
* This works correctly if size is a power of two, i.e. a
|
|
|
|
* contiguous range:
|
|
|
|
*/
|
2023-05-02 14:09:17 +02:00
|
|
|
*size = -mask >> PAGE_SHIFT;
|
x86: Fix /proc/mtrr with base/size more than 44bits
On one sytem that mtrr range is more then 44bits, in dmesg we have
[ 0.000000] MTRR default type: write-back
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-DFFFF write-through
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 [000080000000-0000FFFFFFFF] mask 3FFF80000000 uncachable
[ 0.000000] 1 [380000000000-38FFFFFFFFFF] mask 3F0000000000 uncachable
[ 0.000000] 2 [000099000000-000099FFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 3 [00009A000000-00009AFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 4 [381FFA000000-381FFBFFFFFF] mask 3FFFFE000000 write-through
[ 0.000000] 5 [381FFC000000-381FFC0FFFFF] mask 3FFFFFF00000 write-through
[ 0.000000] 6 [0000AD000000-0000ADFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 7 [0000BD000000-0000BDFFFFFF] mask 3FFFFF000000 write-through
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
but /proc/mtrr report wrong:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x80000000000 (8388608MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x81ffa000000 (8519584MB), size= 32MB, count=1: write-through
reg05: base=0x81ffc000000 (8519616MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
so bit 44 and bit 45 get cut off.
We have problems in arch/x86/kernel/cpu/mtrr/generic.c::generic_get_mtrr().
1. for base, we miss cast base_lo to 64bit before shifting.
Fix that by adding u64 casting.
2. for size, it only can handle 44 bits aka 32bits + page_shift
Fix that with 64bit mask instead of 32bit mask_lo, then range could be
more than 44bits.
At the same time, we need to update size_or_mask for old cpus that does
support cpuid 0x80000008 to get phys_addr. Need to set high 32bits
to all 1s, otherwise will not get correct size for them.
Also fix mtrr_add_page: it should check base and (base + size - 1)
instead of base and size, as base and size could be small but
base + size could bigger enough to be out of boundary. We can
use boot_cpu_data.x86_phys_bits directly to avoid size_or_mask.
So When are we going to have size more than 44bits? that is 16TiB.
after patch we have right ouput:
reg00: base=0x080000000 ( 2048MB), size= 2048MB, count=1: uncachable
reg01: base=0x380000000000 (58720256MB), size=1048576MB, count=1: uncachable
reg02: base=0x099000000 ( 2448MB), size= 16MB, count=1: write-through
reg03: base=0x09a000000 ( 2464MB), size= 16MB, count=1: write-through
reg04: base=0x381ffa000000 (58851232MB), size= 32MB, count=1: write-through
reg05: base=0x381ffc000000 (58851264MB), size= 1MB, count=1: write-through
reg06: base=0x0ad000000 ( 2768MB), size= 16MB, count=1: write-through
reg07: base=0x0bd000000 ( 3024MB), size= 16MB, count=1: write-through
reg08: base=0x09b000000 ( 2480MB), size= 16MB, count=1: write-combining
-v2: simply checking in mtrr_add_page according to hpa.
[ hpa: This probably wants to go into -stable only after having sat in
mainline for a bit. It is not a regression. ]
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Link: http://lkml.kernel.org/r/1371162815-29931-1-git-send-email-yinghai@kernel.org
Cc: <stable@vger.kernel.org>
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
2013-06-13 15:33:35 -07:00
|
|
|
*base = (u64)base_hi << (32 - PAGE_SHIFT) | base_lo >> PAGE_SHIFT;
|
2023-05-02 14:09:17 +02:00
|
|
|
*type = base_lo & MTRR_PHYSBASE_TYPE;
|
2009-03-12 18:43:54 -07:00
|
|
|
|
2009-03-13 12:46:07 -07:00
|
|
|
out_put_cpu:
|
|
|
|
put_cpu();
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2007-05-02 19:27:17 +02:00
|
|
|
/**
|
2009-07-04 07:53:00 +05:30
|
|
|
* set_fixed_ranges - checks & updates the fixed-range MTRRs if they
|
|
|
|
* differ from the saved set
|
2008-03-13 16:59:12 -07:00
|
|
|
* @frs: pointer to fixed-range MTRR values, saved by get_fixed_ranges()
|
2007-05-02 19:27:17 +02:00
|
|
|
*/
|
2009-07-04 07:53:00 +05:30
|
|
|
static int set_fixed_ranges(mtrr_type *frs)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
2009-07-04 07:53:00 +05:30
|
|
|
unsigned long long *saved = (unsigned long long *)frs;
|
2008-01-30 13:30:31 +01:00
|
|
|
bool changed = false;
|
2009-07-04 07:53:00 +05:30
|
|
|
int block = -1, range;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-03-12 17:39:37 +01:00
|
|
|
k8_check_syscfg_dram_mod_en();
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
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 15:20:36 -07:00
|
|
|
|
|
|
|
return changed;
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* Set the MSR pair relating to a var range.
|
|
|
|
* Returns true if changes are made.
|
|
|
|
*/
|
2008-01-30 13:30:31 +01:00
|
|
|
static bool set_mtrr_var_ranges(unsigned int index, struct mtrr_var_range *vr)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
unsigned int lo, hi;
|
2008-01-30 13:30:31 +01:00
|
|
|
bool changed = false;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
rdmsr(MTRRphysBase_MSR(index), lo, hi);
|
2023-05-02 14:09:17 +02:00
|
|
|
if ((vr->base_lo & ~MTRR_PHYSBASE_RSVD) != (lo & ~MTRR_PHYSBASE_RSVD)
|
|
|
|
|| (vr->base_hi & ~phys_hi_rsvd) != (hi & ~phys_hi_rsvd)) {
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2005-04-16 15:20:36 -07:00
|
|
|
mtrr_wrmsr(MTRRphysBase_MSR(index), vr->base_lo, vr->base_hi);
|
2008-01-30 13:30:31 +01:00
|
|
|
changed = true;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
rdmsr(MTRRphysMask_MSR(index), lo, hi);
|
|
|
|
|
2023-05-02 14:09:17 +02:00
|
|
|
if ((vr->mask_lo & ~MTRR_PHYSMASK_RSVD) != (lo & ~MTRR_PHYSMASK_RSVD)
|
|
|
|
|| (vr->mask_hi & ~phys_hi_rsvd) != (hi & ~phys_hi_rsvd)) {
|
2005-04-16 15:20:36 -07:00
|
|
|
mtrr_wrmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi);
|
2008-01-30 13:30:31 +01:00
|
|
|
changed = true;
|
2005-04-16 15:20:36 -07: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-07 02:14:09 +01:00
|
|
|
static u32 deftype_lo, deftype_hi;
|
|
|
|
|
2008-03-13 16:59:12 -07:00
|
|
|
/**
|
|
|
|
* set_mtrr_state - Set the MTRR state for this CPU.
|
|
|
|
*
|
2022-10-04 10:10:08 +02:00
|
|
|
* NOTE: The CPU must already be in a safe state for MTRR changes, including
|
|
|
|
* measures that only a single CPU can be active in set_mtrr_state() in
|
|
|
|
* order to not be subject to races for usage of deftype_lo. This is
|
2022-11-02 08:47:01 +01:00
|
|
|
* accomplished by taking cache_disable_lock.
|
2008-03-13 16:59:12 -07:00
|
|
|
* 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-07 02:14:09 +01:00
|
|
|
static unsigned long set_mtrr_state(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
unsigned long change_mask = 0;
|
2009-07-04 07:53:00 +05:30
|
|
|
unsigned int i;
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
for (i = 0; i < num_var_ranges; i++) {
|
2005-04-16 15:20:36 -07:00
|
|
|
if (set_mtrr_var_ranges(i, &mtrr_state.var_ranges[i]))
|
|
|
|
change_mask |= MTRR_CHANGE_MASK_VARIABLE;
|
2009-07-04 07:53:00 +05:30
|
|
|
}
|
2005-04-16 15:20:36 -07: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-07 02:14:09 +01:00
|
|
|
if (mtrr_state.have_fixed && set_fixed_ranges(mtrr_state.fixed_ranges))
|
2005-04-16 15:20:36 -07:00
|
|
|
change_mask |= MTRR_CHANGE_MASK_FIXED;
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* Set_mtrr_restore restores the old value of MTRRdefType,
|
|
|
|
* so to set it we fiddle with the saved value:
|
|
|
|
*/
|
2023-05-02 14:09:17 +02:00
|
|
|
if ((deftype_lo & MTRR_DEF_TYPE_TYPE) != mtrr_state.def_type ||
|
|
|
|
((deftype_lo & MTRR_DEF_TYPE_ENABLE) >> MTRR_STATE_SHIFT) != mtrr_state.enabled) {
|
2009-07-04 07:53:00 +05:30
|
|
|
|
2023-05-02 14:09:17 +02:00
|
|
|
deftype_lo = (deftype_lo & MTRR_DEF_TYPE_DISABLE) |
|
|
|
|
mtrr_state.def_type |
|
|
|
|
(mtrr_state.enabled << MTRR_STATE_SHIFT);
|
2005-04-16 15:20:36 -07:00
|
|
|
change_mask |= MTRR_CHANGE_MASK_DEFTYPE;
|
|
|
|
}
|
|
|
|
|
|
|
|
return change_mask;
|
|
|
|
}
|
|
|
|
|
2022-11-02 08:47:02 +01:00
|
|
|
void mtrr_disable(void)
|
|
|
|
{
|
|
|
|
/* Save MTRR state */
|
|
|
|
rdmsr(MSR_MTRRdefType, deftype_lo, deftype_hi);
|
|
|
|
|
|
|
|
/* Disable MTRRs, and set the default type to uncached */
|
2023-05-02 14:09:17 +02:00
|
|
|
mtrr_wrmsr(MSR_MTRRdefType, deftype_lo & MTRR_DEF_TYPE_DISABLE, deftype_hi);
|
2022-11-02 08:47:02 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
void mtrr_enable(void)
|
|
|
|
{
|
|
|
|
/* Intel (P6) standard MTRRs */
|
|
|
|
mtrr_wrmsr(MSR_MTRRdefType, deftype_lo, deftype_hi);
|
|
|
|
}
|
|
|
|
|
2022-11-02 08:47:04 +01:00
|
|
|
void mtrr_generic_set_state(void)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
unsigned long mask, count;
|
|
|
|
|
|
|
|
/* 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-07 02:14:09 +01:00
|
|
|
mask = set_mtrr_state();
|
2005-04-16 15:20:36 -07:00
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/* Use the atomic bitops to update the global mask */
|
2018-10-28 12:58:28 +00:00
|
|
|
for (count = 0; count < sizeof(mask) * 8; ++count) {
|
2005-04-16 15:20:36 -07:00
|
|
|
if (mask & 0x01)
|
|
|
|
set_bit(count, &smp_changes_mask);
|
|
|
|
mask >>= 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/**
|
|
|
|
* generic_set_mtrr - 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.
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
static void generic_set_mtrr(unsigned int reg, unsigned long base,
|
|
|
|
unsigned long size, mtrr_type type)
|
|
|
|
{
|
|
|
|
unsigned long flags;
|
2005-07-07 17:56:38 -07:00
|
|
|
struct mtrr_var_range *vr;
|
|
|
|
|
|
|
|
vr = &mtrr_state.var_ranges[reg];
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
local_irq_save(flags);
|
2022-11-02 08:47:01 +01:00
|
|
|
cache_disable();
|
2005-04-16 15:20:36 -07:00
|
|
|
|
|
|
|
if (size == 0) {
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* The invalid bit is kept in the mask, so we simply
|
|
|
|
* clear the relevant mask register to disable a range.
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
mtrr_wrmsr(MTRRphysMask_MSR(reg), 0, 0);
|
2005-07-07 17:56:38 -07:00
|
|
|
memset(vr, 0, sizeof(struct mtrr_var_range));
|
2005-04-16 15:20:36 -07:00
|
|
|
} else {
|
2005-07-07 17:56:38 -07:00
|
|
|
vr->base_lo = base << PAGE_SHIFT | type;
|
2023-05-02 14:09:17 +02:00
|
|
|
vr->base_hi = (base >> (32 - PAGE_SHIFT)) & ~phys_hi_rsvd;
|
|
|
|
vr->mask_lo = -size << PAGE_SHIFT | MTRR_PHYSMASK_V;
|
|
|
|
vr->mask_hi = (-size >> (32 - PAGE_SHIFT)) & ~phys_hi_rsvd;
|
2005-07-07 17:56:38 -07:00
|
|
|
|
|
|
|
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 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
2022-11-02 08:47:01 +01:00
|
|
|
cache_enable();
|
2005-04-16 15:20:36 -07:00
|
|
|
local_irq_restore(flags);
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
int generic_validate_add_page(unsigned long base, unsigned long size,
|
|
|
|
unsigned int type)
|
2005-04-16 15:20:36 -07:00
|
|
|
{
|
|
|
|
unsigned long lbase, last;
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* For Intel PPro stepping <= 7
|
|
|
|
* must be 4 MiB aligned and not touch 0x70000000 -> 0x7003FFFF
|
|
|
|
*/
|
2025-02-19 18:41:22 +00:00
|
|
|
if (mtrr_if == &generic_mtrr_ops && boot_cpu_data.x86_vfm == INTEL_PENTIUM_PRO &&
|
2018-01-01 09:52:10 +08:00
|
|
|
boot_cpu_data.x86_stepping <= 7) {
|
2005-04-16 15:20:36 -07:00
|
|
|
if (base & ((1 << (22 - PAGE_SHIFT)) - 1)) {
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_warn("mtrr: base(0x%lx000) is not 4 MiB aligned\n", base);
|
2005-04-16 15:20:36 -07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
2006-12-07 02:14:00 +01:00
|
|
|
if (!(base + size < 0x70000 || base > 0x7003F) &&
|
2005-04-16 15:20:36 -07:00
|
|
|
(type == MTRR_TYPE_WRCOMB
|
|
|
|
|| type == MTRR_TYPE_WRBACK)) {
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_warn("mtrr: writable mtrr between 0x70000000 and 0x7003FFFF may hang the CPU.\n");
|
2005-04-16 15:20:36 -07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* Check upper bits of base and last are equal and lower bits are 0
|
|
|
|
* for base and 1 for last
|
|
|
|
*/
|
2005-04-16 15:20:36 -07:00
|
|
|
last = base + size - 1;
|
|
|
|
for (lbase = base; !(lbase & 1) && (last & 1);
|
2009-07-04 07:53:00 +05:30
|
|
|
lbase = lbase >> 1, last = last >> 1)
|
|
|
|
;
|
2005-04-16 15:20:36 -07:00
|
|
|
if (lbase != last) {
|
2016-02-02 11:45:02 +08:00
|
|
|
pr_warn("mtrr: base(0x%lx000) is not aligned on a size(0x%lx000) boundary\n", base, size);
|
2005-04-16 15:20:36 -07:00
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int generic_have_wrcomb(void)
|
|
|
|
{
|
|
|
|
unsigned long config, dummy;
|
2009-05-14 12:06:12 +05:30
|
|
|
rdmsr(MSR_MTRRcap, config, dummy);
|
2023-05-02 14:09:17 +02:00
|
|
|
return config & MTRR_CAP_WC;
|
2005-04-16 15:20:36 -07:00
|
|
|
}
|
|
|
|
|
|
|
|
int positive_have_wrcomb(void)
|
|
|
|
{
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2009-07-04 07:53:00 +05:30
|
|
|
/*
|
|
|
|
* Generic structure...
|
2005-04-16 15:20:36 -07:00
|
|
|
*/
|
2010-01-31 20:16:34 +01:00
|
|
|
const struct mtrr_ops generic_mtrr_ops = {
|
2009-07-04 07:53:00 +05:30
|
|
|
.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,
|
2005-04-16 15:20:36 -07:00
|
|
|
};
|