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: Tue, 11 Dec 2012 16:27:13 -0800
- Cc: Borislav Petkov <bp@xxxxxxxxx>, "Yu, Fenghua" <fenghua.yu@xxxxxxxxx>, "mingo@xxxxxxxxxx" <mingo@xxxxxxxxxx>, "linux-kernel@xxxxxxxxxxxxxxx" <linux-kernel@xxxxxxxxxxxxxxx>, "tglx@xxxxxxxxxxxxx" <tglx@xxxxxxxxxxxxx>, "hpa@xxxxxxxxxxxxxxx" <hpa@xxxxxxxxxxxxxxx>, "linux-tip-commits@xxxxxxxxxxxxxxx" <linux-tip-commits@xxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>, Stefano Stabellini <Stefano.Stabellini@xxxxxxxxxxxxx>
- In-reply-to: <50C7C859.60405@zytor.com>
On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote:
> Well, we could invoke it on the bootloader page tables, but as you say
> it may not be a good idea... depending on how much memory we may be
> talking about. One solution -- which I have to admit is starting to
> sound really good -- is to set up a #PF handler which cycles through a
> set of page tables and creates a "virtual identity map"... it does have
> the advantage of making the entire physical address space available
> without any additional funnies.
so that #PF handler will work before
arch/x86/kernel/setup.c::setup_arch/early_trap_init
early_strap_intit will install another handler there for #PF
for 64bit, moving early_ioremap_init ahead is very simple, like attach patch
but for 32 bit looks like it is not that easy.
Attachment:
early_ioremap_head64.patch
Description: Binary data
[Index of Archives]
[Linux Stable Commits]
[Linux Stable Kernel]
[Linux Kernel]
[Linux USB Devel]
[Linux Video &Media]
[Linux Audio Users]
[Yosemite News]
[Linux SCSI]