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:21 PM, Jacob Shin wrote:
> On Thu, Dec 20, 2012 at 12:03:29AM +0100, 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.
>
> Actually all memory hole above 4GB and under TOM2 needs to be marked
> as UC, if the kernel just blanket calls init_memory_mapping from 4GB
> to top of memory.
>
> Right we would be loosing memory, and I think depending on the
> alignment of the boundary and how many MTRRs you have avaiable to use,
> significant chunks of memory could be lost. I need to go refresh on
> how variable range MTRRs are programmed, it has been a while.
>

In this particular case an MTRR at 0xe000000000 would lose 896 MB of
RAM, or just under 0.1% of the total.

If it is only the HT region that causes trouble and not the rest of the
hole you could just plant an MTRR at 0xfc00000000 and not lose any
memory at all.

-hpa

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



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