Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
- From: Yinghai Lu <yinghai@xxxxxxxxxx>
- Date: Wed, 19 Dec 2012 14:47:17 -0800
- Cc: Jacob Shin <jacob.shin@xxxxxxx>, Borislav Petkov <bp@xxxxxxxxx>, "H. Peter Anvin" <hpa@xxxxxxxxxxxxxxx>, "Yu, Fenghua" <fenghua.yu@xxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, "linux-tip-commits@xxxxxxxxxxxxxxx" <linux-tip-commits@xxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
- In-reply-to: <50D23EE8.7030904@zytor.com>
On Wed, Dec 19, 2012 at 2:25 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
>
> The problem is that before we have awareness of the memory map, we need to
> map things in order to access them. This is a big problem and right now
> there are ridiculous heuristics. I have been working on mapping on demand,
> but there are concerns about the boundaries (i.e. what happens if the
> mapping spill over into a pit like this.)
>
> This kind of stuff is really not acceptable. A region which will cause
> malfunction if prefetched should not be WB in the MTRR system (I include
> TOM* in that.) The real question is what we can do to mitigate the damage.
on demand to only map 2M will help ?
or have to return to v6 version for-x86-boot ?
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]