On Tue, Dec 11, 2012 at 4:37 PM, H. Peter Anvin <hpa@xxxxxxxxx> wrote: > On 12/11/2012 04:27 PM, Yinghai Lu wrote: >> 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. >> > > 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
Attachment:
fix_microcode.patch
Description: Binary data