* Andy Lutomirski [off-list ref] wrote:
On Jun 12, 2015 12:59 AM, "Jan Beulich" [off-list ref] wrote:
quoted
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).
This may crash and burn badly when we call a UEFI function or an SMI happens. I
think we should just leave the MTRRs alone.
Not to mention suspend/resume, reboot and other goodies where the firmware might
pop up expecting intact MTRRs.
Btw., doesn't a lack of MTRRs imply UC? So is 'crash and burn' possible in most
cases? Isn't it just 'executes slower than before'?
Thanks,
Ingo