Documentation/arch/x86/mtrr.rst

Source file repositories/reference/linux-study-clean/Documentation/arch/x86/mtrr.rst

File Facts

System
Linux kernel
Corpus path
Documentation/arch/x86/mtrr.rst
Extension
.rst
Size
11916 bytes
Lines
355
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

=========================================
MTRR (Memory Type Range Register) control
=========================================

:Authors: - Richard Gooch <rgooch@atnf.csiro.au> - 3 Jun 1999
          - Luis R. Rodriguez <mcgrof@do-not-panic.com> - April 9, 2015


Phasing out MTRR use
====================

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/arch/x86/pat.rst.

.. tip::
  On Intel P6 family processors (Pentium Pro, Pentium II and later)
  the Memory Type Range Registers (MTRRs) may be used to control
  processor access to memory ranges. This is most useful when you have
  a video (VGA) card on a PCI or AGP bus. Enabling write-combining
  allows bus write transfers to be combined into a larger transfer
  before bursting over the PCI/AGP bus. This can increase performance
  of image write operations 2.5 times or more.

  The Cyrix 6x86, 6x86MX and M II processors have Address Range
  Registers (ARRs) which provide a similar functionality to MTRRs. For
  these, the ARRs are used to emulate the MTRRs.

  The AMD K6-2 (stepping 8 and above) and K6-3 processors have two
  MTRRs. These are supported.  The AMD Athlon family provide 8 Intel
  style MTRRs.

  The Centaur C6 (WinChip) has 8 MCRs, allowing write-combining. These
  are supported.

  The VIA Cyrix III and VIA C3 CPUs offer 8 Intel style MTRRs.

  The CONFIG_MTRR option creates a /proc/mtrr file which may be used
  to manipulate your MTRRs. Typically the X server should use
  this. This should have a reasonably generic interface so that
  similar control registers on other processors can be easily
  supported.

There are two interfaces to /proc/mtrr: one is an ASCII interface
which allows you to read and write. The other is an ioctl()
interface. The ASCII interface is meant for administration. The
ioctl() interface is meant for C programs (i.e. the X server). The
interfaces are described below, with sample commands and C code.


Reading MTRRs from the shell
============================
::

Annotation

Implementation Notes