* Pallipadi, Venkatesh <[EMAIL PROTECTED]> wrote:
> Also, relying on MTRR, is like giving more importance to BIOS writer
> than required :-). I think the best way to deal with MTRR is just to
> not touch it. Leave it as it is and do not try to assume that they are
> correct, as frequently they will not be.
i'd suggest the following strategy on PAT-capable CPUs:
- do not try to write MTRRs. Ever.
- _read_ the current MTRR settings (including the default MTRR) and
check them against the e820 map. I can see two basic types of
mismatches:
- RAM area marked fine in e820 but marked UC by MTRR: this
currently results in a slow system. (NOTE: UC- would be fine and
overridable by PAT, hence it's not a conflict we should detect.)
- mmio area marked cacheable in the MTRR (results in broken system)
then emit a warning and exclude all such areas from any further Linux
use. I.e. if it's RAM then clip it from our memory map. If it's mmio
area then try to exclude it from BAR sizing/positioning.
this way we'll only have two sorts of physical pages put into
pagetables by Linux:
1) RAM page, marked cacheable by MTRR
2) RAM page, marked as UC- by MTRR
2) mmio page, marked as UC- by MTRR
- then we'd use PAT for all these patches to differentiate their
caching properties. We mark RAM pages as cacheable, and we mark mmio
pages as WC or UC.
I.e. try to be as conservative and always have a deterministic exit
strategy towards a 100% working system, even if BIOS writers messed up
the MTRR defaults. _Worst-case_ we boot up with somewhat less RAM or
with a somewhat smaller mmio area. (but there will be warnings in the
dmesg about that so users can complain about the BIOS.) We should never
ever allow the wrong BIOS MTRR defaults to impact Linux's correctness.
hm?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
