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 Wed, Dec 19, 2012 at 11:51:55PM +0100, Borislav Petkov wrote:
> On Wed, Dec 19, 2012 at 02:25:44PM -0800, H. Peter Anvin wrote:
> > The real question is what we can do to mitigate the damage.
>
> Let's try the first thing that comes to mind: waste a variable MTRR on
> it:
>
> [ 0.000000] MTRR variable ranges enabled:
> [ 0.000000] 0 base 000000000000 mask FFFF80000000 write-back
> [ 0.000000] 1 base 000080000000 mask FFFFC0000000 write-back
> [ 0.000000] 2 base 0000C0000000 mask FFFFF0000000 write-back
> [ 0.000000] 3 base 000100000000 mask FFFF00000000 write-back
> [ 0.000000] 4 base 000200000000 mask FFFFE0000000 write-back
> [ 0.000000] 5 base 000220000000 mask FFFFF0000000 write-back
> [ 0.000000] 6 disabled
> [ 0.000000] 7 disabled
>
> one of those last two. This is a small box though so I'm guessing on 1T
> boxes those last two won't be disabled. Jacob?

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.

>
> --
> Regards/Gruss,
> Boris.
>
> Sent from a fat crate under my desk. Formatting is fine.
> --
>



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