Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU

["H. Peter Anvin" <hpa@zytor.com>]

On 12/19/2012 02:05 PM, Jacob Shin wrote:
> On Wed, Dec 19, 2012 at 01:48:33PM -0800, H. Peter Anvin wrote:
>> There are a few very serious problems we need to figure out related to generalizing very early boot.  If this range gets mapped, will the CPU treat it as WB?  If so, with what consequences for either the HT region or the hole below it?
>
> Hm .. I guess I need to read the whole email thread .. but if you can
> explain it in short, what are the problems?
>
> Yes the CPU treats it as WB because the region is under TOM2, so by
> default it is WB, and also when you create direct mapping page tables,
> the PATs mark them as WB.
>
> What we have seen is that even though the kernel never generate memory
> accesses in the hole (since E820 says that it is not RAM) when kernel
> read/writes memory near the hole, the CPU was prefetching into the
> hole because PATs say that it is WB. This resulted in MCE because
> there is no physical RAM there.
>

IOW, epic f*ckup.

The problem is that before we have awareness of the memory map, we need 
to map things in order to access them.  This is a big problem and right 
now there are ridiculous heuristics.  I have been working on mapping on 
demand, but there are concerns about the boundaries (i.e. what happens 
if the mapping spill over into a pit like this.)

This kind of stuff is really not acceptable.  A region which will cause 
malfunction if prefetched should not be WB in the MTRR system (I include 
TOM* in that.)  The real question is what we can do to mitigate the damage.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.