Cc: Yinghai Lu <yhlu.kernel@...>, Andrew Morton <akpm@...>, Ingo Molnar <mingo@...>, H. Peter Anvin <hpa@...>, Gabriel C <nix.or.die@...>, linux-kernel@vger.kernel.org <linux-kernel@...>, Mika Fischer <mika.fischer@...>
There is truth in that but it is over dramatic. P4s don't deep fry
they almost always turn off before they overheat (you make take
physical damage to your motherboard though).
The best definition I have heard of SMM mode is: smack the stupid OS
that isn't doing what it should be doing at runtime mode.
It is the way board designers and BIOS writers can work around what
they perceive as broken OS code, that keeps them from doing what
they need to do. Getting them to give up SMM mode even though
technically possible is requesting they give up a degree of control
and thus a major social engineering challenge for anyone who wishes
to achieve it.
So any time we tread on territory that could mess up SMM mode
we need to be careful, especially as we can not turn it off to
diagnose problems. The interactions can be hard to root cause.
Replacing overlapping MTRRs with a non overlapping set to allow
X to set a WB region as YH is doing appears safe and reasonable, and
worth doing.
Going one step farther and reducing some of the WB memory to UC
so we can free up an MTRR for video and to accelerate X is a
bit chancy and something I don't feel comfortable with enabling
by default. Especially as we have a better long term fix on
the way.
This problem is hitting enough people and the odds of something
really bad happening when you take a 100x or 1000x slowdown in
SMM are pretty low so I do think it is useful to have a kernel
option that rounds down the amount of memory you have converts WB
memory to UC to accelerate X.
Hopefully by this point we are all now reminded how this can
interact with SMM mode (although no one has ever seen a bad
interaction) and how interacting with SMM mode can be a problem.
Eric
--
