Re: [PATCH] x86_32: trim memory by updating e820 v3

[Eric W. Biederman]

Ingo Molnar <mingo@xxxxxxx> writes:

> * Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote:
>
>> So lets concentrate on PAT to solve contiguous MTRR region problems.
>> 
>> We can upgrade UC to WC with pat.  As well as demote WB to UC or WC. 
>> So for those regions we know about we should be in good shape.
>
> sure, but whatever we do now in the sysfs API space, it will hit distros 
> only in a year, relistically, because Xorg also has to adopt to it. The 
> workaround from Yinghai looks reasonably configurable - if we mess up 
> (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a 
> lockup right then, during bootup, so it wont be hard to realize what 
> went wrong. In that sense it's in fact safer to do it during early init 
> than let the user do it via some script, because the window is smaller, 
> etc.
>
> we still default to the safe mode of course and dont touch MTRRs, but 
> for note the various configuration options that are available to distros 
> and users.

The potential problem isn't while we reprogram the MTRRs, the potential
problem is mapping the SMM area uncachable.  In which case we will
make each SMM interrupt drastically slower.  Which can have all kinds of
unpleasant side effects.

If we really can mess up SMM mode that way we have a really nasty
interaction that is horrible to debug, or recognize.

Further the opportunity for this kind of fixup is small.
Newer AMD systems don't need it as they have an extra
way of specifying memory about 4G as WB.  Systems with just
the MTRRs can only use this when they have right around 4GB
because with more memory there are not enough MTRRs to leave them
non-overlapping and still mark all of memory WB.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/