[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <50D29249.1090109@linux.intel.com>
Date: Wed, 19 Dec 2012 20:21:29 -0800
From: "H. Peter Anvin" <hpa@...ux.intel.com>
To: Jacob Shin <jacob.shin@....com>
CC: "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
Yinghai Lu <yinghai@...nel.org>,
"Yu, Fenghua" <fenghua.yu@...el.com>,
"mingo@...nel.org" <mingo@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Stefano Stabellini <Stefano.Stabellini@...citrix.com>
Subject: Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update
ucode on Intel's CPU
On 12/19/2012 08:16 PM, Jacob Shin wrote:
>
> Not exactly sure why the wierd boundaries, I'll have to ask the BIOS
> side folks to be sure. But if I were to guess ..
>
> Here is the NUMA spew out, physically there is 128 GB connected to
> each memory controller node. The PCI MMIO region starts at 0xc8000000.
> 4 GB - 0xc8000000 = 0x3800000 (896 MB). So we loose 896 MB due to PCI
> MMIO hole, so the first node ends at 128 GB + 896 MB to talk to all of
> 128 GB off of the first memory controller, and hence the weird 896 MB
> offset.
>
It would obviously be better if the slack were at the end of the total
memory, instead of end of the < 1T range. If the PCI MMIO hole were a
power of 2 (e.g. 1G) that would also reduce the likelihood of problems
and reduce MTRR pressure.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists