1. 09 5月, 2017 1 次提交
    • A
      x86/boot/32: Fix UP boot on Quark and possibly other platforms · d2b6dc61
      Andy Lutomirski 提交于
      This partially reverts commit:
      
        23b2a4dd ("x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up")
      
      That commit had one definite bug and one potential bug.  The
      definite bug is that setup_per_cpu_areas() uses a differnet generic
      implementation on UP kernels, so initial_page_table never got
      resynced.  This was fine for access to percpu data (it's in the
      identity map on UP), but it breaks other users of
      initial_page_table.  The potential bug is that helpers like
      efi_init() would be called before the tables were synced.
      
      Avoid both problems by just syncing the page tables in setup_arch()
      *and* setup_per_cpu_areas().
      Reported-by: NJan Kiszka <jan.kiszka@siemens.com>
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      d2b6dc61
  2. 23 3月, 2017 1 次提交
    • A
      x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up · 23b2a4dd
      Andy Lutomirski 提交于
      The x86 smpboot trampoline expects initial_page_table to have the
      GDT mapped.  If the GDT ends up in a virtually mapped per-cpu page,
      then it won't be in the page tables at all until perc-pu areas are
      set up.  The result will be a triple fault the first time that the
      CPU attempts to access the GDT after LGDT loads the perc-pu GDT.
      
      This appears to be an old bug, but somehow the GDT fixmap rework
      is triggering it.  This seems to have something to do with the
      memory layout.
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Garnier <thgarnie@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/a553264a5972c6a86f9b5caac237470a0c74a720.1490218061.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      23b2a4dd
  3. 21 3月, 2017 2 次提交
  4. 11 3月, 2017 1 次提交
    • M
      x86/cpu: Drop wp_works_ok member of struct cpuinfo_x86 · 6415813b
      Mathias Krause 提交于
      Remove the wp_works_ok member of struct cpuinfo_x86. It's an
      optimization back from Linux v0.99 times where we had no fixup support
      yet and did the CR0.WP test via special code in the page fault handler.
      The < 0 test was an optimization to not do the special casing for each
      NULL ptr access violation but just for the first one doing the WP test.
      Today it serves no real purpose as the test no longer needs special code
      in the page fault handler and the only call side -- mem_init() -- calls
      it just once, anyway. However, Xen pre-initializes it to 1, to skip the
      test.
      
      Doing the test again for Xen should be no issue at all, as even the
      commit introducing skipping the test (commit d560bc61 ("x86, xen:
      Suppress WP test on Xen")) mentioned it being ban aid only. And, in
      fact, testing the patch on Xen showed nothing breaks.
      
      The pre-fixup times are long gone and with the removal of the fallback
      handling code in commit a5c2a893 ("x86, 386 removal: Remove
      CONFIG_X86_WP_WORKS_OK") the kernel requires a working CR0.WP anyway.
      So just get rid of the "optimization" and do the test unconditionally.
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Acked-by: NBorislav Petkov <bp@alien8.de>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Link: http://lkml.kernel.org/r/1486933932-585-3-git-send-email-minipli@googlemail.comSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      6415813b
  5. 07 2月, 2017 1 次提交
  6. 29 1月, 2017 6 次提交
    • I
      x86/boot/e820: Rename the remaining E820 APIs to the e820__*() prefix · 0c6fc11a
      Ingo Molnar 提交于
      Three more renames left:
      
         e820_end_of_ram_pfn()      =>  e820__end_of_ram_pfn()
         e820_end_of_low_ram_pfn()  =>  e820__end_of_low_ram_pfn()
         e820_reallocate_tables()   =>  e820__reallocate_tables()
      
      After this all E820 API calls are prefixed with "e820__", making
      it much easier to grep for E820 functionality in the kernel.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      0c6fc11a
    • I
      x86/boot/e820: Rename e820_mark_nosave_regions() to e820__register_nosave_regions() · 090d7171
      Ingo Molnar 提交于
      This function is a minor misnomer: it is talking about 'marking' regions
      as nosave - while the hibernation API is called register_nosave_region()
      and the e820_mark_nosave_regions() is a wrapper around that functionality.
      
      So name it to be in line with the API it is derived from.
      
      ( Rename e820_mark_nvs_memory() to e820__register_nvs_regions(), for similar
        reasons. )
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      090d7171
    • I
      x86/boot/e820: Rename e820_reserve_resources*() to e820__reserve_resources*() · 1506c8dc
      Ingo Molnar 提交于
      Also do some minor cleanups.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1506c8dc
    • I
      x86/boot/e820: Document e820__reserve_setup_data() · 1a127034
      Ingo Molnar 提交于
      Also clean it up a bit.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      1a127034
    • I
      x86/boot/e820: Simplify the e820__update_table() interface · f9748fa0
      Ingo Molnar 提交于
      The e820__update_table() parameters are pretty complex:
      
        arch/x86/include/asm/e820/api.h:extern int  e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map);
      
      But 90% of the usage is trivial:
      
        arch/x86/kernel/e820.c:	if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries))
        arch/x86/kernel/e820.c:	e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
        arch/x86/kernel/e820.c:	e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
        arch/x86/kernel/e820.c:		if (e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries) < 0)
        arch/x86/kernel/e820.c:	e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
        arch/x86/kernel/early-quirks.c:	e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
        arch/x86/kernel/setup.c:	e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
        arch/x86/kernel/setup.c:		e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
        arch/x86/platform/efi/efi.c:	e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
        arch/x86/xen/setup.c:	e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
        arch/x86/xen/setup.c:	e820__update_table(e820_table->entries, ARRAY_SIZE(e820_table->entries), &e820_table->nr_entries);
        arch/x86/xen/setup.c:	e820__update_table(xen_e820_table.entries, ARRAY_SIZE(xen_e820_table.entries),
      
      as it only uses an exiting struct e820_table's entries array, its size and
      its current number of entries as input and output arguments.
      
      Only one use is non-trivial:
      
        arch/x86/kernel/e820.c:	e820__update_table(boot_params.e820_table, ARRAY_SIZE(boot_params.e820_table), &new_nr);
      
      ... which call updates the E820 table in the zeropage in-situ, and the layout there does not
      match that of 'struct e820_table' (in particular nr_entries is at a different offset,
      hardcoded by the boot protocol).
      
      Simplify all this by introducing a low level __e820__update_table() API that
      the zeropage update call can use, and simplifying the main e820__update_table()
      call signature down to:
      
      	int e820__update_table(struct e820_table *table);
      
      This visibly simplifies all the call sites:
      
        arch/x86/include/asm/e820/api.h:extern int  e820__update_table(struct e820_table *table);
        arch/x86/include/asm/e820/types.h: * call to e820__update_table() to remove duplicates.  The allowance
        arch/x86/kernel/e820.c: * The return value from e820__update_table() is zero if it
        arch/x86/kernel/e820.c:int __init e820__update_table(struct e820_table *table)
        arch/x86/kernel/e820.c:	if (e820__update_table(e820_table))
        arch/x86/kernel/e820.c:	e820__update_table(e820_table_firmware);
        arch/x86/kernel/e820.c:	e820__update_table(e820_table);
        arch/x86/kernel/e820.c:	e820__update_table(e820_table);
        arch/x86/kernel/e820.c:		if (e820__update_table(e820_table) < 0)
        arch/x86/kernel/early-quirks.c:	e820__update_table(e820_table);
        arch/x86/kernel/setup.c:	e820__update_table(e820_table);
        arch/x86/kernel/setup.c:		e820__update_table(e820_table);
        arch/x86/platform/efi/efi.c:	e820__update_table(e820_table);
        arch/x86/xen/setup.c:	e820__update_table(&xen_e820_table);
        arch/x86/xen/setup.c:	e820__update_table(e820_table);
        arch/x86/xen/setup.c:	e820__update_table(&xen_e820_table);
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f9748fa0
    • I
      x86/boot/e820: Prefix the E820_* type names with "E820_TYPE_" · 09821ff1
      Ingo Molnar 提交于
      So there's a number of constants that start with "E820" but which
      are not types - these create a confusing mixture when seen together
      with 'enum e820_type' values:
      
      	E820MAP
      	E820NR
      	E820_X_MAX
      	E820MAX
      
      To better differentiate the 'enum e820_type' values prefix them
      with E820_TYPE_.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      09821ff1
  7. 28 1月, 2017 17 次提交
    • I
      x86/boot/e820: Rename e820_print_map() to e820__print_table() · be0c3f0f
      Ingo Molnar 提交于
      All other table-level methods are already named 'table' in some way,
      to change this one over to the (now consistent) nomenclature.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      be0c3f0f
    • I
      x86/boot/e820: Create coherent API function names for E820 range operations · ab6bc04c
      Ingo Molnar 提交于
      We have these three related functions:
      
       extern void e820_add_region(u64 start, u64 size, int type);
       extern u64  e820_update_range(u64 start, u64 size, unsigned old_type, unsigned new_type);
       extern u64  e820_remove_range(u64 start, u64 size, unsigned old_type, int checktype);
      
      But it's not clear from the naming that they are 3 operations based around the
      same 'memory range' concept. Rename them to better signal this, and move
      the prototypes next to each other:
      
       extern void e820__range_add   (u64 start, u64 size, int type);
       extern u64  e820__range_update(u64 start, u64 size, unsigned old_type, unsigned new_type);
       extern u64  e820__range_remove(u64 start, u64 size, unsigned old_type, int checktype);
      
      Note that this improved organization of the functions shows another problem that was easy
      to miss before: sometimes the E820 entry type is 'int', sometimes 'unsigned int' - but this
      will be fixed in a separate patch.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ab6bc04c
    • I
      x86/boot/e820: Rename e820_setup_gap() to e820__setup_pci_gap() · 2df908ba
      Ingo Molnar 提交于
      The e820_setup_gap() function name is unnecessarily silent about what
      kind of gap it sets up. Make it clear that it's about the PCI gap.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      2df908ba
    • I
      x86/boot/e820: Rename e820_any_mapped()/e820_all_mapped() to e820__mapped_any()/e820__mapped_all() · 3bce64f0
      Ingo Molnar 提交于
      The 'any' and 'all' are modified to the 'mapped' concept, so move them last in the name.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      3bce64f0
    • I
      x86/boot/e820: Rename sanitize_e820_table() to e820__update_table() · f52355a9
      Ingo Molnar 提交于
      sanitize_e820_table() is a minor misnomer in that it suggests that
      the E820 table requires sanitizing - which implies that it will only
      do anything if the E820 table is irregular (not sane).
      
      That is wrong, because sanitize_e820_table() also does a very regular
      sorting of the E820 table, which is a necessity in the basic
      append-only flow of E820 updates the kernel is allowed to perform to
      it.
      
      So rename it to e820__update_table() to include that purpose as well.
      
      This also lines up all the table-update functions into a coherent
      naming family:
      
        int  e820__update_table(struct e820_entry *biosmap, int max_nr_map, u32 *pnr_map);
      
        void e820__update_table_print(void);
        void e820__update_table_firmware(void);
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      f52355a9
    • I
      x86/boot/e820: Rename early_reserve_e820() to e820__memblock_alloc() and document it · 5da217ca
      Ingo Molnar 提交于
      early_reserve_e820() is an early hack for kexec that does a limited fixup of the
      mptable and passes it to the kexec kernel as if it was the real thing.
      
      For this it needs to allocate memory - but no memory allocator is available yet
      beyond the memblock allocator, so early_reserve_e820() is really a wrapper
      around memblock_alloc() plus a hack to update the e820_table_firmware entries.
      
      The name 'reserve' is really a bit of a misnomer, as 'reserved' memory typically
      means memory completely inaccessible to the kernel - while here what we want to do
      is a special RAM allocation for our own purposes and insert that as RAM_RESERVED.
      
      Rename the function to e820__memblock_alloc_reserved() to better signal this dual
      purpose, plus document it better, which was omitted when it was merged. The barely
      comprehensible and cryptic comment:
      
        /*
         * pre allocated 4k and reserved it in memblock and e820_table_firmware
         */
        u64 __init e820__memblock_alloc_reserved(u64 size, u64 align)
      
      ... does not count as documentation, replace it with:
      
        /*
         * Allocate the requested number of bytes with the requsted alignment
         * and return (the physical address) to the caller. Also register this
         * range in the 'firmware' E820 table.
         *
         * This allows kexec to fake a new mptable, as if it came from the real
         * system.
         */
        u64 __init e820__memblock_alloc_reserved(u64 size, u64 align)
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      5da217ca
    • I
      x86/boot/e820: Clarify the role of finish_e820_parsing() and rename it to... · 9641bdaf
      Ingo Molnar 提交于
      x86/boot/e820: Clarify the role of finish_e820_parsing() and rename it to e820__finish_early_params()
      
      finish_e820_parsing() is closely related to parse_early_params(), but the
      name does not tell us this clearly, so rename it to e820__finish_early_params().
      
      Also add a few comments to explain what the function does.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      9641bdaf
    • I
      x86/boot/e820: Move e820_reserve_setup_data() to e820.c · da92139b
      Ingo Molnar 提交于
      The e820_reserve_setup_data() is local to arch/x86/kernel/setup.c,
      but it is E820 functionality - so move it to e820.c to better
      isolate E820 functionality.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      da92139b
    • I
      x86/boot/e820: Rename parse_e820_ext() to e820__memory_setup_extended() · 914053c0
      Ingo Molnar 提交于
      parse_e820_ext() is very similar to e820__memory_setup_default(), both are
      taking bootloader provided data, add it to the E820 table and then
      pass it sanitize_e820_table().
      
      Rename it to e820__memory_setup_extended() to better signal their similar role.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      914053c0
    • I
      x86/boot/e820: Rename memblock_x86_fill() to e820__memblock_setup() and improve the explanations · 4918e228
      Ingo Molnar 提交于
      So memblock_x86_fill() is another E820 code misnomer:
      
       - nothing in its name tells us that it's part of the E820 subsystem ...
      
       - The 'fill' wording is ambiguous and doesn't tell us whether it's a single
         entry or some process - while the _real_ purpose of the function is hidden,
         which is to do a complete setup of the (platform independent) memblock regions.
      
      So rename it accordingly, to e820__memblock_setup().
      
      Also translate this incomprehensible and misleading comment:
      
              /*
      	 * EFI may have more than 128 entries
      	 * We are safe to enable resizing, beause memblock_x86_fill()
      	 * is rather later for x86
      	 */
              memblock_allow_resize();
      
      The worst aspect of this comment isn't even the sloppy typos, but that it
      casually mentions a '128' number with no explanation, which makes one lead
      to the assumption that this is related to the well-known limit of a maximum
      of 128 E820 entries passed via legacy bootloaders.
      
      But no, the _real_ meaning of 128 here is that of the memblock subsystem,
      which too happens to have a 128 entries limit for very early memblock
      regions (which is unrelated to E820), via INIT_MEMBLOCK_REGIONS ...
      
      So change the comment to a more comprehensible version:
      
              /*
               * The bootstrap memblock region count maximum is 128 entries
               * (INIT_MEMBLOCK_REGIONS), but EFI might pass us more E820 entries
               * than that - so allow memblock resizing.
               *
               * This is safe, because this call happens pretty late during x86 setup,
               * so we know about reserved memory regions already. (This is important
               * so that memblock resizing does no stomp over reserved areas.)
               */
              memblock_allow_resize();
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      4918e228
    • I
      x86/boot/e820: Rename e820_table_saved to e820_table_firmware and improve the description · 544a0f47
      Ingo Molnar 提交于
      So the 'e820_table_saved' is a bit of a misnomer that hides its real purpose.
      
      At first sight the name suggests that it's some sort save/restore mechanism,
      as this is how we typically name such facilities in the kernel.
      
      But that is not so, e820_table_saved is the original firmware version of the
      e820 table, not modified by the kernel. This table is displayed in the
      /sys/firmware/memmap file, and it's also used by the hibernation code to
      calculate a physical memory layout MD5 fingerprint checksum which is
      invariant of the kernel.
      
      So rename it to 'e820_table_firmware' and update all the comments to better
      describe the main e820 data strutures.
      
      Also rename:
      
        'initial_e820_table_saved'  =>  'e820_table_firmware_init'
        'e820_update_range_saved'   =>  'e820_update_range_firmware'
      
      ... to better match the new nomenclature.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      544a0f47
    • I
      x86/boot/e820: Rename default_machine_specific_memory_setup() to e820__memory_setup_default() · 103e2063
      Ingo Molnar 提交于
      The default_machine_specific_memory_setup() is a mouthful and despite the
      many words it doesn't actually tell us clearly what it does.
      
      The function is the x86 legacy memory layout setup code, based on
      E820-formatted memory layout information passed by the bootloader
      via the boot_params.
      
      Rename it to e820__memory_setup_default() to better signal its purpose.
      
      Also rename the related higher level function to be consistent with
      this new naming:
      
          setup_memory_map() => e820__memory_setup()
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      103e2063
    • I
      x86/boot/e820: Harmonize the 'struct e820_table' fields · bf495573
      Ingo Molnar 提交于
      So the e820_table->map and e820_table->nr_map names are a bit
      confusing, because it's not clear what a 'map' really means
      (it could be a bitmap, or some other data structure), nor is
      it clear what nr_map means (is it a current index, or some
      other count).
      
      Rename the fields from:
      
       e820_table->map        =>     e820_table->entries
       e820_table->nr_map     =>     e820_table->nr_entries
      
      which makes it abundantly clear that these are entries
      of the table, and that the size of the table is ->nr_entries.
      
      Propagate the changes to all affected files. Where necessary,
      adjust local variable names to better reflect the new field names.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      bf495573
    • I
      x86/boot/e820: Rename everything to e820_table · 61a50101
      Ingo Molnar 提交于
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      61a50101
    • I
      x86/boot/e820: Rename 'e820_map' variables to 'e820_array' · acd4c048
      Ingo Molnar 提交于
      In line with the rename to 'struct e820_array', harmonize the naming of common e820
      table variable names as well:
      
       e820          =>  e820_array
       e820_saved    =>  e820_array_saved
       e820_map      =>  e820_array
       initial_e820  =>  e820_array_init
      
      This makes the variable names more consistent  and easier to grep for.
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      acd4c048
    • I
      x86/boot/e820: Rename the basic e820 data types to 'struct e820_entry' and 'struct e820_array' · 8ec67d97
      Ingo Molnar 提交于
      The 'e820entry' and 'e820map' names have various annoyances:
      
       - the missing underscore departs from the usual kernel style
         and makes the code look weird,
      
       - in the past I kept confusing the 'map' with the 'entry', because
         a 'map' is ambiguous in that regard,
      
       - it's not really clear from the 'e820map' that this is a regular
         C array.
      
      Rename them to 'struct e820_entry' and 'struct e820_array' accordingly.
      
      ( Leave the legacy UAPI header alone but do the rename in the bootparam.h
        and e820/types.h file - outside tools relying on these defines should
        either adjust their code, or should use the legacy header, or should
        create their private copies for the definitions. )
      
      No change in functionality.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      8ec67d97
    • I
      x86/boot/e820: Move asm/e820.h to asm/e820/api.h · 66441bd3
      Ingo Molnar 提交于
      In line with asm/e820/types.h, move the e820 API declarations to
      asm/e820/api.h and update all usage sites.
      
      This is just a mechanical, obviously correct move & replace patch,
      there will be subsequent changes to clean up the code and to make
      better use of the new header organization.
      
      Cc: Alex Thorlton <athorlton@sgi.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Huang, Ying <ying.huang@intel.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Juergen Gross <jgross@suse.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Paul Jackson <pj@sgi.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Wei Yang <richard.weiyang@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      66441bd3
  8. 23 1月, 2017 1 次提交
  9. 13 12月, 2016 1 次提交
    • R
      mm: remove x86-only restriction of movable_node · 39fa104d
      Reza Arbab 提交于
      In commit c5320926 ("mem-hotplug: introduce movable_node boot
      option"), the memblock allocation direction is changed to bottom-up and
      then back to top-down like this:
      
      1. memblock_set_bottom_up(true), called by cmdline_parse_movable_node().
      2. memblock_set_bottom_up(false), called by x86's numa_init().
      
      Even though (1) occurs in generic mm code, it is wrapped by #ifdef
      CONFIG_MOVABLE_NODE, which depends on X86_64.
      
      This means that when we extend CONFIG_MOVABLE_NODE to non-x86 arches,
      things will be unbalanced.  (1) will happen for them, but (2) will not.
      
      This toggle was added in the first place because x86 has a delay between
      adding memblocks and marking them as hotpluggable.  Since other arches
      do this marking either immediately or not at all, they do not require
      the bottom-up toggle.
      
      So, resolve things by moving (1) from cmdline_parse_movable_node() to
      x86's setup_arch(), immediately after the movable_node parameter has
      been parsed.
      
      Link: http://lkml.kernel.org/r/1479160961-25840-3-git-send-email-arbab@linux.vnet.ibm.comSigned-off-by: NReza Arbab <arbab@linux.vnet.ibm.com>
      Acked-by: NBalbir Singh <bsingharora@gmail.com>
      Cc: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Alistair Popple <apopple@au1.ibm.com>
      Cc: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bharata B Rao <bharata@linux.vnet.ibm.com>
      Cc: Frank Rowand <frowand.list@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Nathan Fontenot <nfont@linux.vnet.ibm.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Rob Herring <robh+dt@kernel.org>
      Cc: Stewart Smith <stewart@linux.vnet.ibm.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      39fa104d
  10. 29 10月, 2016 1 次提交
    • T
      x86/smpboot: Init apic mapping before usage · 1e90a13d
      Thomas Gleixner 提交于
      The recent changes, which forced the registration of the boot cpu on UP
      systems, which do not have ACPI tables, have been fixed for systems w/o
      local APIC, but left a wreckage for systems which have neither ACPI nor
      mptables, but the CPU has an APIC, e.g. virtualbox.
      
      The boot process crashes in prefill_possible_map() as it wants to register
      the boot cpu, which needs to access the local apic, but the local APIC is
      not yet mapped.
      
      There is no reason why init_apic_mapping() can't be invoked before
      prefill_possible_map(). So instead of playing another silly early mapping
      game, as the ACPI/mptables code does, we just move init_apic_mapping()
      before the call to prefill_possible_map().
      
      In hindsight, I should have noticed that combination earlier.
      
      Sorry for the churn (also in stable)!
      
      Fixes: ff856051 ("x86/boot/smp: Don't try to poke disabled/non-existent APIC")
      Reported-and-debugged-by: NMichal Necasek <michal.necasek@oracle.com>
      Reported-and-tested-by: NWolfgang Bauer <wbauer@tmo.at>
      Cc: prarit@redhat.com
      Cc: ville.syrjala@linux.intel.com
      Cc: michael.thayer@oracle.com
      Cc: knut.osmundsen@oracle.com
      Cc: frank.mehnert@oracle.com
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610282114380.5053@nanosSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      1e90a13d
  11. 30 9月, 2016 2 次提交
  12. 21 9月, 2016 1 次提交
  13. 09 9月, 2016 2 次提交
    • R
      x86/efi: Defer efi_esrt_init until after memblock_x86_fill · 3dad6f7f
      Ricardo Neri 提交于
      Commit 7b02d53e7852 ("efi: Allow drivers to reserve boot services forever")
      introduced a new efi_mem_reserve to reserve the boot services memory
      regions forever. This reservation involves allocating a new EFI memory
      range descriptor. However, allocation can only succeed if there is memory
      available for the allocation. Otherwise, error such as the following may
      occur:
      
      esrt: Reserving ESRT space from 0x000000003dd6a000 to 0x000000003dd6a010.
      Kernel panic - not syncing: ERROR: Failed to allocate 0x9f0 bytes below \
       0x0.
      CPU: 0 PID: 0 Comm: swapper Not tainted 4.7.0-rc5+ #503
       0000000000000000 ffffffff81e03ce0 ffffffff8131dae8 ffffffff81bb6c50
       ffffffff81e03d70 ffffffff81e03d60 ffffffff8111f4df 0000000000000018
       ffffffff81e03d70 ffffffff81e03d08 00000000000009f0 00000000000009f0
      Call Trace:
       [<ffffffff8131dae8>] dump_stack+0x4d/0x65
       [<ffffffff8111f4df>] panic+0xc5/0x206
       [<ffffffff81f7c6d3>] memblock_alloc_base+0x29/0x2e
       [<ffffffff81f7c6e3>] memblock_alloc+0xb/0xd
       [<ffffffff81f6c86d>] efi_arch_mem_reserve+0xbc/0x134
       [<ffffffff81fa3280>] efi_mem_reserve+0x2c/0x31
       [<ffffffff81fa3280>] ? efi_mem_reserve+0x2c/0x31
       [<ffffffff81fa40d3>] efi_esrt_init+0x19e/0x1b4
       [<ffffffff81f6d2dd>] efi_init+0x398/0x44a
       [<ffffffff81f5c782>] setup_arch+0x415/0xc30
       [<ffffffff81f55af1>] start_kernel+0x5b/0x3ef
       [<ffffffff81f55434>] x86_64_start_reservations+0x2f/0x31
       [<ffffffff81f55520>] x86_64_start_kernel+0xea/0xed
      ---[ end Kernel panic - not syncing: ERROR: Failed to allocate 0x9f0
           bytes below 0x0.
      
      An inspection of the memblock configuration reveals that there is no memory
      available for the allocation:
      
      MEMBLOCK configuration:
       memory size = 0x0 reserved size = 0x4f339c0
       memory.cnt  = 0x1
       memory[0x0]    [0x00000000000000-0xffffffffffffffff], 0x0 bytes on node 0\
                       flags: 0x0
       reserved.cnt  = 0x4
       reserved[0x0]  [0x0000000008c000-0x0000000008c9bf], 0x9c0 bytes flags: 0x0
       reserved[0x1]  [0x0000000009f000-0x000000000fffff], 0x61000 bytes\
                       flags: 0x0
       reserved[0x2]  [0x00000002800000-0x0000000394bfff], 0x114c000 bytes\
                       flags: 0x0
       reserved[0x3]  [0x000000304e4000-0x00000034269fff], 0x3d86000 bytes\
                       flags: 0x0
      
      This situation can be avoided if we call efi_esrt_init after memblock has
      memory regions for the allocation.
      
      Also, the EFI ESRT driver makes use of early_memremap'pings. Therfore, we
      do not want to defer efi_esrt_init for too long. We must call such function
      while calls to early_memremap are still valid.
      
      A good place to meet the two aforementioned conditions is right after
      memblock_x86_fill, grouped with other EFI-related functions.
      Reported-by: NScott Lawson <scott.lawson@intel.com>
      Signed-off-by: NRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Peter Jones <pjones@redhat.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      3dad6f7f
    • M
      x86/efi: Test for EFI_MEMMAP functionality when iterating EFI memmap · 4971531a
      Matt Fleming 提交于
      Both efi_find_mirror() and efi_fake_memmap() really want to know
      whether the EFI memory map is available, not just whether the machine
      was booted using EFI. efi_fake_memmap() even has a check for
      EFI_MEMMAP at the start of the function.
      
      Since we've already got other code that has this dependency, merge
      everything under one if() conditional, and remove the now superfluous
      check from efi_fake_memmap().
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: NArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Xishi Qiu <qiuxishi@huawei.com>
      Cc: Kamezawa Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Signed-off-by: NMatt Fleming <matt@codeblueprint.co.uk>
      4971531a
  14. 15 8月, 2016 1 次提交
    • B
      x86/mm/numa: Open code function early_get_boot_cpu_id() · a91bf718
      Baoquan He 提交于
      Previously early_acpi_boot_init() was called in early_get_boot_cpu_id()
      to get the value for boot_cpu_physical_apicid. Now early_acpi_boot_init()
      has been taken out and moved to setup_arch(), the name of
      early_get_boot_cpu_id() doesn't match its implementation anymore, and
      only the getting boot-time SMP configuration code was left.
      
      So in this patch we open code it.
      
      Also move the smp_found_config check into default_get_smp_config to
      simplify code, because both early_get_smp_config() and get_smp_config()
      call x86_init.mpparse.get_smp_config().
      
      Also remove the redundent CONFIG_X86_MPPARSE #ifdef check when we call
      early_get_smp_config().
      Signed-off-by: NBaoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-acpi@vger.kernel.org
      Cc: rjw@rjwysocki.net
      Link: http://lkml.kernel.org/r/1470985033-22493-1-git-send-email-bhe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      a91bf718
  15. 11 8月, 2016 2 次提交
    • A
      x86/boot: Defer setup_real_mode() to early_initcall time · d0de0f68
      Andy Lutomirski 提交于
      There's no need to run setup_real_mode() as early as we run it.
      Defer it to the same early_initcall that sets up the page
      permissions for the real mode code.
      
      This should be a code size reduction.  More importantly, it give us
      a longer window in which we can allocate the real mode trampoline.
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/fd62f0da4f79357695e9bf3e365623736b05f119.1470821230.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d0de0f68
    • A
      x86/boot: Synchronize trampoline_cr4_features and mmu_cr4_features directly · 18bc7bd5
      Andy Lutomirski 提交于
      The initialization process for trampoline_cr4_features and
      mmu_cr4_features was confusing.  The intent is for mmu_cr4_features
      and *trampoline_cr4_features to stay in sync, but
      trampoline_cr4_features is NULL until setup_real_mode() runs.  The
      old code synchronized *trampoline_cr4_features *twice*, once in
      setup_real_mode() and once in setup_arch().  It also initialized
      mmu_cr4_features in setup_real_mode(), which causes the actual value
      of mmu_cr4_features to potentially depend on when setup_real_mode()
      is called.
      
      With this patch, mmu_cr4_features is initialized directly in
      setup_arch(), and *trampoline_cr4_features is synchronized to
      mmu_cr4_features when the trampoline is set up.
      
      After this patch, it should be safe to defer setup_real_mode().
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mario Limonciello <mario_limonciello@dell.com>
      Cc: Matt Fleming <mfleming@suse.de>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Link: http://lkml.kernel.org/r/d48a263f9912389b957dd495a7127b009259ffe0.1470821230.git.luto@kernel.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      18bc7bd5