Re: [patch 02/11] PAT x86: Map only usable memory in x86_64 identity map and kernel text

[Ingo Molnar <mingo@elte.hu>]

* Pallipadi, Venkatesh <venkatesh.pallipadi@intel.com> 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