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

From: Borislav Petkov
Date: Wed Dec 19 2012 - 15:37:51 EST

On Sat, Dec 15, 2012 at 03:17:05PM -0800, H. Peter Anvin wrote:
> On 12/15/2012 03:15 PM, Yinghai Lu wrote:
> >>
> >>That is for the kernel region itself (that code is actually unchanged from
> >>the current code), and yes, we could cap that one to _end if there are
> >>systems which have bugs in that area. The dynamic page tables map 1G
> >>aligned at a time.
> >
> >dynamic should be 2M too.
> >
> >AMD system:
> >
> >;a=commitdiff;h=66520ebc2df3fe52eb4792f8101fac573b766baf
> >
> > BIOS-e820: [mem 0x0000000100000000-0x000000e037ffffff] usable
> > BIOS-e820: [mem 0x000000e038000000-0x000000fcffffffff] reserved
> > BIOS-e820: [mem 0x0000010000000000-0x0000011ffeffffff] usable
> >
> >the hole is not 1G aligned.
> >
> >or HT region is from e040000000 ?
> >
> The HT region starts at 0xfd00000000 -- after that reserved region,
> so I have no idea what that particular system is trying to do or
> what is requirements are (nor what its MTRR setup is, since you
> didn't post it.)

This is something that Jacob should be able to answer since he's been
dealing with the 1T support.

Jacob, how is the HT hole marked on AMD? I know hazily that we do say
"all memory regions cacheable by default if not explicitly marked" but
we need to exclude the HT hole from that, right?

So how are we doing that, MTRRs?



Sent from a fat crate under my desk. Formatting is fine.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at