Commit 2f9e8973 authored by Luis R. Rodriguez's avatar Luis R. Rodriguez Committed by Ingo Molnar

x86/mm/mtrr, pat: Document Write Combining MTRR type effects on PAT / non-PAT pages

As part of the effort to phase out MTRR use document
write-combining MTRR effects on pages with different non-PAT
page attributes flags and different PAT entry values. Extend
arch_phys_wc_add() documentation to clarify power of two sizes /
boundary requirements as we phase out mtrr_add() use.

Lastly hint towards ioremap_uc() for corner cases on device
drivers working with devices with mixed regions where MTRR size
requirements would otherwise not enable write-combining
effective memory types.
Signed-off-by: default avatarLuis R. Rodriguez <>
Signed-off-by: default avatarBorislav Petkov <>
Cc: Andy Lutomirski <>
Cc: Antonino Daplas <>
Cc: Borislav Petkov <>
Cc: Brian Gerst <>
Cc: Daniel Vetter <>
Cc: Dave Airlie <>
Cc: Dave Hansen <>
Cc: Davidlohr Bueso <>
Cc: Denys Vlasenko <>
Cc: H. Peter Anvin <>
Cc: Jean-Christophe Plagniol-Villard <>
Cc: Jonathan Corbet <>
Cc: Juergen Gross <>
Cc: Linus Torvalds <>
Cc: Mel Gorman <>
Cc: Peter Zijlstra <>
Cc: Suresh Siddha <>
Cc: Thomas Gleixner <>
Cc: Tomi Valkeinen <>
Cc: Ville Syrjälä <>
Cc: Vlastimil Babka <>
Link: default avatarIngo Molnar <>
parent 9e76561f
MTRR (Memory Type Range Register) control
3 Jun 1999
Richard Gooch
Richard Gooch <> - 3 Jun 1999
Luis R. Rodriguez <> - April 9, 2015
Phasing out MTRR use
MTRR use is replaced on modern x86 hardware with PAT. Over time the only type
of effective MTRR that is expected to be supported will be for write-combining.
As MTRR use is phased out device drivers should use arch_phys_wc_add() to make
MTRR effective on non-PAT systems while a no-op on PAT enabled systems.
For details refer to Documentation/x86/pat.txt.
On Intel P6 family processors (Pentium Pro, Pentium II and later)
the Memory Type Range Registers (MTRRs) may be used to control
......@@ -34,6 +34,8 @@ ioremap | -- | UC- | UC- |
| | | |
ioremap_cache | -- | WB | WB |
| | | |
ioremap_uc | -- | UC | UC |
| | | |
ioremap_nocache | -- | UC- | UC- |
| | | |
ioremap_wc | -- | -- | WC |
......@@ -102,7 +104,38 @@ wants to export a RAM region, it has to do set_memory_uc() or set_memory_wc()
as step 0 above and also track the usage of those pages and use set_memory_wb()
before the page is freed to free pool.
MTRR effects on PAT / non-PAT systems
The following table provides the effects of using write-combining MTRRs when
using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
is made, should already have been ioremapped with WC attributes or PAT entries,
this can be done by using ioremap_wc() / set_memory_wc(). Devices which
combine areas of IO memory desired to remain uncacheable with areas where
write-combining is desirable should consider use of ioremap_uc() followed by
set_memory_wc() to white-list effective write-combined areas. Such use is
nevertheless discouraged as the effective memory type is considered
implementation defined, yet this strategy can be used as last resort on devices
with size-constrained regions where otherwise MTRR write-combining would
otherwise not be effective.
MTRR Non-PAT PAT Linux ioremap value Effective memory type
(*) denotes implementation defined and is discouraged
......@@ -538,6 +538,9 @@ EXPORT_SYMBOL(mtrr_del);
* attempts to add a WC MTRR covering size bytes starting at base and
* logs an error if this fails.
* The called should provide a power of two size on an equivalent
* power of two boundary.
* Drivers must store the return value to pass to mtrr_del_wc_if_needed,
* but drivers should not try to interpret that return value.
Markdown is supported
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment