[coreboot-gerrit] Change in coreboot[master]: [WIP] cpu/x86/mtrr: Always allow holes
Nico Huber (Code Review)
gerrit at coreboot.org
Sat Oct 7 16:49:35 CEST 2017
Nico Huber has uploaded this change for review. ( https://review.coreboot.org/21916
Change subject: [WIP] cpu/x86/mtrr: Always allow holes
......................................................................
[WIP] cpu/x86/mtrr: Always allow holes
Now that calc_var_mtrrs_with_hole() always chooses the optimal
allocation, there is no need for calc_var_mtrrs_without_hole()
any more. Drop it and all the logic to decide which one to call.
Change-Id: Iedf7dfad61d6baac91973062e2688ad866f05afd
Signed-off-by: Nico Huber <nico.h at gmx.de>
---
M src/cpu/x86/mtrr/mtrr.c
1 file changed, 12 insertions(+), 92 deletions(-)
git pull ssh://review.coreboot.org:29418/coreboot refs/changes/16/21916/1
diff --git a/src/cpu/x86/mtrr/mtrr.c b/src/cpu/x86/mtrr/mtrr.c
index 82666fc..d8df4d0 100644
--- a/src/cpu/x86/mtrr/mtrr.c
+++ b/src/cpu/x86/mtrr/mtrr.c
@@ -109,20 +109,8 @@
#define RANGE_1MB PHYS_TO_RANGE_ADDR(1 << 20)
#define RANGE_4GB (1 << (ADDR_SHIFT_TO_RANGE_SHIFT(32)))
-/*
- * The default MTRR type selection uses 3 approaches for selecting the
- * optimal number of variable MTRRs. For each range do 3 calculations:
- * 1. UC as default type with no holes at top of range.
- * 2. UC as default using holes at top of range.
- * 3. WB as default.
- * If using holes is optimal for a range when UC is the default type the
- * tag is updated to direct the commit routine to use a hole at the top
- * of a range.
- */
#define MTRR_ALGO_SHIFT (8)
#define MTRR_TAG_MASK ((1 << MTRR_ALGO_SHIFT) - 1)
-/* If the default type is UC use the hole carving algorithm for a range. */
-#define MTRR_RANGE_UC_USE_HOLE (1 << MTRR_ALGO_SHIFT)
static inline uint32_t range_entry_base_mtrr_addr(struct range_entry *r)
{
@@ -608,37 +596,6 @@
calc_var_mtrr_range(var_state, b1, b2 - b1, var_state->def_mtrr_type);
}
-static void calc_var_mtrrs_without_hole(struct var_mtrr_state *var_state,
- struct range_entry *r)
-{
- const int mtrr_type = range_entry_mtrr_type(r);
-
- uint32_t base = range_entry_base_mtrr_addr(r);
- uint32_t end = range_entry_end_mtrr_addr(r);
-
- /* The end address is within the first 1MiB. The fixed MTRRs take
- * precedence over the variable ones. Therefore this range
- * can be ignored. */
- if (end <= RANGE_1MB)
- return;
-
- /* Again, the fixed MTRRs take precedence so the beginning
- * of the range can be set to 0 if it starts at or below 1MiB. */
- if (base <= RANGE_1MB)
- base = 0;
-
- /* If the range starts above 4GiB the processing is done. */
- if (!var_state->above4gb && base >= RANGE_4GB)
- return;
-
- /* Clip the upper address to 4GiB if addresses above 4GiB
- * are not being processed. */
- if (!var_state->above4gb && end > RANGE_4GB)
- end = RANGE_4GB;
-
- calc_var_mtrr_range(var_state, base, end - base, mtrr_type);
-}
-
static void __calc_var_mtrrs(struct memranges *addr_space,
int above4gb, int address_bits,
int *num_def_wb_mtrrs, int *num_def_uc_mtrrs)
@@ -660,16 +617,14 @@
uc_deftype_count = 0;
/*
- * For each range do 3 calculations:
- * 1. UC as default type with no holes at top of range.
- * 2. UC as default using holes at top of range.
- * 3. WB as default.
+ * For each range do 2 calculations:
+ * 1. UC as default type with possible holes at top of range.
+ * 2. WB as default.
* The lowest count is then used as default after totaling all
- * MTRRs. Note that the optimal algorithm for UC default is marked in
- * the tag of each range regardless of final decision. UC takes
- * precedence in the MTRR architecture. Therefore, only holes can be
- * used when the type of the region is MTRR_TYPE_WRBACK with
- * MTRR_TYPE_UNCACHEABLE as the default type.
+ * MTRRs. UC takes precedence in the MTRR architecture. There-
+ * fore, only holes can be used when the type of the region is
+ * MTRR_TYPE_WRBACK with MTRR_TYPE_UNCACHEABLE as the default
+ * type.
*/
memranges_each_entry(r, var_state.addr_space) {
int mtrr_type;
@@ -677,43 +632,16 @@
mtrr_type = range_entry_mtrr_type(r);
if (mtrr_type != MTRR_TYPE_UNCACHEABLE) {
- int uc_hole_count;
- int uc_no_hole_count;
-
- var_state.def_mtrr_type = MTRR_TYPE_UNCACHEABLE;
var_state.mtrr_index = 0;
-
- /* No hole calculation. */
- calc_var_mtrrs_without_hole(&var_state, r);
- uc_no_hole_count = var_state.mtrr_index;
-
- /* Hole calculation only if type is WB. The 64 number
- * is a count that is unachievable, thus making it
- * a default large number in the case of not doing
- * the hole calculation. */
- uc_hole_count = 64;
- if (mtrr_type == MTRR_TYPE_WRBACK) {
- var_state.mtrr_index = 0;
- calc_var_mtrrs_with_hole(&var_state, r);
- uc_hole_count = var_state.mtrr_index;
- }
-
- /* Mark the entry with the optimal algorithm. */
- if (uc_no_hole_count < uc_hole_count) {
- uc_deftype_count += uc_no_hole_count;
- } else {
- unsigned long new_tag;
-
- new_tag = mtrr_type | MTRR_RANGE_UC_USE_HOLE;
- range_entry_update_tag(r, new_tag);
- uc_deftype_count += uc_hole_count;
- }
+ var_state.def_mtrr_type = MTRR_TYPE_UNCACHEABLE;
+ calc_var_mtrrs_with_hole(&var_state, r);
+ uc_deftype_count += var_state.mtrr_index;
}
if (mtrr_type != MTRR_TYPE_WRBACK) {
var_state.mtrr_index = 0;
var_state.def_mtrr_type = MTRR_TYPE_WRBACK;
- calc_var_mtrrs_without_hole(&var_state, r);
+ calc_var_mtrrs_with_hole(&var_state, r);
wb_deftype_count += var_state.mtrr_index;
}
}
@@ -770,12 +698,7 @@
memranges_each_entry(r, var_state.addr_space) {
if (range_entry_mtrr_type(r) == def_type)
continue;
-
- if (def_type == MTRR_TYPE_UNCACHEABLE &&
- (range_entry_tag(r) & MTRR_RANGE_UC_USE_HOLE))
- calc_var_mtrrs_with_hole(&var_state, r);
- else
- calc_var_mtrrs_without_hole(&var_state, r);
+ calc_var_mtrrs_with_hole(&var_state, r);
}
/* Update the solution. */
@@ -885,9 +808,6 @@
orig = get_physical_address_space();
memranges_each_entry(r, orig) {
unsigned long tag = range_entry_tag(r);
-
- /* Remove any special tags from original solution. */
- tag &= ~MTRR_RANGE_UC_USE_HOLE;
/* Remove any write combining MTRRs from the temporary
* solution as it just fragments the address space. */
--
To view, visit https://review.coreboot.org/21916
To unsubscribe, visit https://review.coreboot.org/settings
Gerrit-Project: coreboot
Gerrit-Branch: master
Gerrit-MessageType: newchange
Gerrit-Change-Id: Iedf7dfad61d6baac91973062e2688ad866f05afd
Gerrit-Change-Number: 21916
Gerrit-PatchSet: 1
Gerrit-Owner: Nico Huber <nico.h at gmx.de>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot-gerrit/attachments/20171007/73bb7248/attachment-0001.html>
More information about the coreboot-gerrit
mailing list