On Fri, 2015-06-12 at 08:59 +0100, Jan Beulich wrote:
quoted
quoted
quoted
On 12.06.15 at 01:23, [off-list ref] wrote:
There are two usages on MTRRs:
1) MTRR entries set by firmware
2) MTRR entries set by OS drivers
We can obsolete 2), but we have no control over 1). As UEFI firmwares
also set this up, this usage will continue to stay. So, we should not
get rid of the MTRR code that looks up the MTRR entries, while we have
no need to modify them.
Such MTRR entries provide safe guard to /dev/mem, which allows
privileged user to access a range that may require UC mapping while
the /dev/mem driver blindly maps it with WB. MTRRs converts WB to UC in
such a case.
But it wouldn't be impossible to simply read the MTRRs upon boot,
store the information, disable MTRRs, and correctly use PAT to
achieve the same effect (i.e. the "blindly maps" part of course
would need fixing).
It could be done, but I do not see much benefit of doing it. One of the
reasons platform vendors set MTRRs is so that a system won't hit a
machine check when an OS bug leads an access with a wrong cache type. A
machine check is hard to analyze and can be seen as a hardware issue by
customers. Emulating MTRRs with PAT won't protect from such a bug.
quoted
UEFI memory table has memory attribute, which describes cache types
supported in physical memory ranges. However, this information gets
lost when it it is converted to e820 table.
I'm afraid you rather don't want to trust that information, as
firmware vendors frequently screw it up.
Could be, but we need to use firmware info when necessary...
Thanks,
-Toshi