lkml.org 
[lkml]   [2012]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
On 12/19/2012 03:03 PM, Borislav Petkov wrote:
> On Wed, Dec 19, 2012 at 04:59:41PM -0600, Jacob Shin wrote:
>> I can check but right, they might be used up. But even if we had slots
>> available, the memory range that needs to be covered is in large
>> enough address and aligned in such a way that you cannot cover it with
>> variable range MTRRs.
>
> Actually, if I'm not mistaken, you only need to cover the HT hole with
> one MTRR - the rest remains WB. And in order the mask bits to work, we
> could make it a little bigger - we waste some memory but that's nothing
> in comparison to the MCE.
>
> You might need to talk to hw guys about the feasibility of this deal
> though.
>

Just make the hole a bit bigger, so it starts at 0xfc00000000, then you
only need one MTRR. This is the correct BIOS-level fix, and it really
needs to happen.

Do these systems actually exist in the field or are they engineering
prototypes? In the latter case, we might be done at that point.

Really, though, AMD should have added a TOM3 for memory above the 1T
mark since they should have been able to see a 1T hole coming from the
design of HyperTransport. This would be the correct hardware-level fix,
but I don't expect that to happen.

Now, calming down a little bit, we are definitely dealing with BIOS
engineers and so f*ckups are going to happen, again and again. The
question is what to do about it.

The only truly "safe" option is to limit early mappings to 4K pages.
This is highly undesirable for a bunch of reasons. Reducing mapping
granularity to 2M rather than 1G (what Yinghai is proposing) does reduce
the exposure somewhat; it would be interesting to gather trap statistics
and try to get a feel for if this actually changes the boot time
measurably or not.

The other bit is that building the real kernel page tables iteratively
(ignoring the early page tables here) is safer, since the real page
table builder is fully aware of the memory map. This means any
"spillover" from the early page tables gets minimized to regions where
there are data objects that have to be accessed early. Since Yinghai
already had iterative page table building working, I don't see any
reason to not use that capability.

Thoughts?

-hpa



\
 
 \ /
  Last update: 2012-12-20 00:41    [W:0.181 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site