lkml.org 
[lkml]   [2012]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
From
On Tue, Dec 11, 2012 at 4:37 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 12/11/2012 04:27 PM, Yinghai Lu wrote:
>> On Tue, Dec 11, 2012 at 3:57 PM, H. Peter Anvin <hpa@zytor.com> 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.
>>
>
> For 32 bits, we don't need it, because we can just run this part in
> linear mode. It also doesn't help us on 32 bits since we are limited by
> virtual address space anyway.

please check draft version for early_memremap version for microcode...

1. make find_cpio take map/unmap function pointer, and use that to set
sliding window.
2. clean the end to size in some function to fix -1 offset
3. update_mc_saved to change back to __va for ap etc and after
initrd_relocation.

NOT EVEN COMPILING TEST.

should use this one on top of early_ioremap_head64.patch that i sent
it out this afternoon.

Thanks

Yinghai
[unhandled content-type:application/octet-stream]
\
 
 \ /
  Last update: 2012-12-12 08:21    [W:0.146 / U:0.784 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site