lkml.org 
[lkml]   [2012]   [Dec]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [tip:x86/microcode] x86/microcode_intel_early.c: Early update ucode on Intel's CPU
    On 12/11/2012 03:53 PM, Yinghai Lu wrote:
    > On Tue, Dec 11, 2012 at 9:38 AM, H. Peter Anvin <hpa@zytor.com> wrote:
    >> On 12/11/2012 09:15 AM, Yinghai Lu wrote:
    >>>
    >>>
    >>> No, that is not right place. initrd could be loaded anywhere like way
    >>> high by bootloader.
    >>>
    >>
    >> Only *after* your changes... the current protocol doesn't allow that.
    >
    > before for-x86-boot change,
    >
    > bootloader put ramdisk just under 2g...
    >
    > [ 0.000000] memblock_reserve: [0x7d9dc000-0x7fffefff] RAMDISK
    >
    > and arch/x86/kernel/head_64.S only set ident mapping for [0,1g)
    >
    > so before init_memory_mapping, we need to use early_ioremap to access
    > ramdisk area.
    >
    > also even after init_memory_mapping, we still need use early_ioremap to access
    > it because user could use memmap to skip it.
    >
    > PS: this problem have nothing to do with mapping that is set by bootloader.
    > arch/x86/kernel/head_64.c will have it own mapping, and only cover [0,1g).
    >

    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.

    -hpa



    \
     
     \ /
      Last update: 2012-12-12 01:21    [W:3.450 / U:0.040 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site