Messages in this thread | | | Date | Tue, 11 Dec 2012 23:14:52 -0800 | Subject | Re: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU | From | Yinghai Lu <> |
| |
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] | |