Here is my current understanding of the MTRR problems. Please correct
any mistakes.
There are two broad reasons (use cases) for Linux to change MTRRs
(1) to clean up after bad BIOSes.
(1a) Some BIOSes don't make all the MTRRs the same on all processors.
This is just wrong and the kernel fixes this.
(1b) Some BIOSes, for some memory configurations, fail to specify that
certain bits of RAM should be cached. The current fix is to not use
that RAM, so the MTRRs are not actually changed, but they could be.
(2) to allow userland programs to adjust the caching regime for chunks
of memory.
The only use of this that I know of is by some (most) X device drivers
to change the video device buffer from Uncachable to Write-Combining.
(OK, I simplified: a very few other device drivers do the same thing,
eg. the ib_path Infiniband driver.)
Are there any other significant uses?
Currently, the kernel is not capable of using the MTRR mechanism to
change the caching behaviour of a range of memory that is a proper
subset of the range of an existing MTRR. That is a carefully worded
statement -- I will unpack it:
- the desired effect might be achieved using PAT, but we are only
dealing with MTRR here.
- by "proper subset" I mean smaller than and contained within
- generally, the BIOS sets up a distinct MTRR for a video buffer
so this condition will manifest itself as nested MTRR ranges.
But this isn't the only way it could arise.
There is a proposal to fix the problem: patch "x86: mtrr cleanup for converting continuous to discrete
layout, v8"
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=95ffa2438d...
and it apparently continues to be refined.
[I have a userland program to attack the same problem. See
ftp://ftp.cs.utoronto.ca/pub/hugh/mtrr-uncover-2008sept27.tgz
When I make changes, the date portion of the name changes -- it is a
work in progress.]
I have some doubts about the kernel patch.
(1) ...
