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

x86/mm/mtrr: Remove kernel internal MTRR interfaces: unexport mtrr_add() and mtrr_del()

The effort to replace mtrr_add() with architecture agnostic
arch_phys_wc_add() is complete, this will ensure write-combining
implementations (PAT on x86) is taken advantage instead of using
MTRR. With the effort done now, hide direct MTRR access for

The legacy user-space /proc/mtrr ABI is not affected.

Update x86 documentation on MTRR to reflect the completion of
the phasing out of direct access to MTRR, also add a note on
platform firmware code use of MTRRs based on the obituary
discussion of MTRRs on Linux [0].

  [0] default avatarLuis R. Rodriguez <>
Cc: <>
Cc: Andy Lutomirski <>
Cc: Andy Walls <>
Cc: Antonino Daplas <>
Cc: Borislav Petkov <>
Cc: Daniel Vetter <>
Cc: Dave Airlie <>
Cc: Dave Hansen <>
Cc: Davidlohr Bueso <>
Cc: Doug Ledford <>
Cc: H. Peter Anvin <>
Cc: Jean-Christophe Plagniol-Villard <>
Cc: Juergen Gross <>
Cc: Linus Torvalds <>
Cc: Mel Gorman <>
Cc: Peter Zijlstra <>
Cc: Suresh Siddha <>
Cc: Thomas Gleixner <>
Cc: Tomi Valkeinen <>
Cc: Toshi Kani <>
Cc: Ville Syrjälä <>
Cc: Vlastimil Babka <>
Link: default avatarIngo Molnar <>
parent ee03c586
......@@ -6,10 +6,22 @@ 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.
MTRR use is replaced on modern x86 hardware with PAT. Direct MTRR use by
drivers on Linux is now completely phased out, device drivers should use
arch_phys_wc_add() in combination with ioremap_wc() to make MTRR effective on
non-PAT systems while a no-op but equally effective on PAT enabled systems.
Even if Linux does not use MTRRs directly, some x86 platform firmware may still
set up MTRRs early before booting the OS. They do this as some platform
firmware may still have implemented access to MTRRs which would be controlled
and handled by the platform firmware directly. An example of platform use of
MTRRs is through the use of SMI handlers, one case could be for fan control,
the platform code would need uncachable access to some of its fan control
registers. Such platform access does not need any Operating System MTRR code in
place other than mtrr_type_lookup() to ensure any OS specific mapping requests
are aligned with platform MTRR setup. If MTRRs are only set up by the platform
firmware code though and the OS does not make any specific MTRR mapping
requests mtrr_type_lookup() should always return MTRR_TYPE_INVALID.
For details refer to Documentation/x86/pat.txt.
......@@ -448,7 +448,6 @@ int mtrr_add(unsigned long base, unsigned long size, unsigned int type,
return mtrr_add_page(base >> PAGE_SHIFT, size >> PAGE_SHIFT, type,
* mtrr_del_page - delete a memory type region
......@@ -537,7 +536,6 @@ int mtrr_del(int reg, unsigned long base, unsigned long size)
return -EINVAL;
return mtrr_del_page(reg, base >> PAGE_SHIFT, size >> PAGE_SHIFT);
* arch_phys_wc_add - add a WC MTRR and handle errors if PAT is unavailable
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment