1. 20 7月, 2018 2 次提交
    • P
      x86/jump_label: Initialize static branching early · 8990cac6
      Pavel Tatashin 提交于
      Static branching is useful to runtime patch branches that are used in hot
      path, but are infrequently changed.
      
      The x86 clock framework is one example that uses static branches to setup
      the best clock during boot and never changes it again.
      
      It is desired to enable the TSC based sched clock early to allow fine
      grained boot time analysis early on. That requires the static branching
      functionality to be functional early as well.
      
      Static branching requires patching nop instructions, thus,
      arch_init_ideal_nops() must be called prior to jump_label_init().
      
      Do all the necessary steps to call arch_init_ideal_nops() right after
      early_cpu_init(), which also allows to insert a call to jump_label_init()
      right after that. jump_label_init() will be called again from the generic
      init code, but the code is protected against reinitialization already.
      
      [ tglx: Massaged changelog ]
      Suggested-by: NPeter Zijlstra <peterz@infradead.org>
      Signed-off-by: NPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NBorislav Petkov <bp@suse.de>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Cc: pbonzini@redhat.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-10-pasha.tatashin@oracle.com
      8990cac6
    • P
      x86/kvmclock: Remove memblock dependency · 368a540e
      Pavel Tatashin 提交于
      KVM clock is initialized later compared to other hypervisor clocks because
      it has a dependency on the memblock allocator.
      
      Bring it in line with other hypervisors by using memory from the BSS
      instead of allocating it.
      
      The benefits:
      
        - Remove ifdef from common code
        - Earlier availability of the clock
        - Remove dependency on memblock, and reduce code
      
      The downside:
      
        - Static allocation of the per cpu data structures sized NR_CPUS * 64byte
          Will be addressed in follow up patches.
      
      [ tglx: Split out from larger series ]
      Signed-off-by: NPavel Tatashin <pasha.tatashin@oracle.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NPaolo Bonzini <pbonzini@redhat.com>
      Cc: steven.sistare@oracle.com
      Cc: daniel.m.jordan@oracle.com
      Cc: linux@armlinux.org.uk
      Cc: schwidefsky@de.ibm.com
      Cc: heiko.carstens@de.ibm.com
      Cc: john.stultz@linaro.org
      Cc: sboyd@codeaurora.org
      Cc: hpa@zytor.com
      Cc: douly.fnst@cn.fujitsu.com
      Cc: peterz@infradead.org
      Cc: prarit@redhat.com
      Cc: feng.tang@intel.com
      Cc: pmladek@suse.com
      Cc: gnomes@lxorguk.ukuu.org.uk
      Cc: linux-s390@vger.kernel.org
      Cc: boris.ostrovsky@oracle.com
      Cc: jgross@suse.com
      Link: https://lkml.kernel.org/r/20180719205545.16512-2-pasha.tatashin@oracle.com
      368a540e
  2. 09 5月, 2018 1 次提交
  3. 27 4月, 2018 1 次提交
    • P
      x86/setup: Do not reserve a crash kernel region if booted on Xen PV · 3db3eb28
      Petr Tesarik 提交于
      Xen PV domains cannot shut down and start a crash kernel. Instead,
      the crashing kernel makes a SCHEDOP_shutdown hypercall with the
      reason code SHUTDOWN_crash, cf. xen_crash_shutdown() machine op in
      arch/x86/xen/enlighten_pv.c.
      
      A crash kernel reservation is merely a waste of RAM in this case. It
      may also confuse users of kexec_load(2) and/or kexec_file_load(2).
      When flags include KEXEC_ON_CRASH or KEXEC_FILE_ON_CRASH,
      respectively, these syscalls return success, which is technically
      correct, but the crash kexec image will never be actually used.
      Signed-off-by: NPetr Tesarik <ptesarik@suse.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Reviewed-by: NJuergen Gross <jgross@suse.com>
      Cc: Tom Lendacky <thomas.lendacky@amd.com>
      Cc: Dou Liyang <douly.fnst@cn.fujitsu.com>
      Cc: Mikulas Patocka <mpatocka@redhat.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: xen-devel@lists.xenproject.org
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Jean Delvare <jdelvare@suse.de>
      Link: https://lkml.kernel.org/r/20180425120835.23cef60c@ezekiel.suse.cz
      3db3eb28
  4. 01 3月, 2018 1 次提交
    • T
      x86/cpu_entry_area: Sync cpu_entry_area to initial_page_table · 945fd17a
      Thomas Gleixner 提交于
      The separation of the cpu_entry_area from the fixmap missed the fact that
      on 32bit non-PAE kernels the cpu_entry_area mapping might not be covered in
      initial_page_table by the previous synchronizations.
      
      This results in suspend/resume failures because 32bit utilizes initial page
      table for resume. The absence of the cpu_entry_area mapping results in a
      triple fault, aka. insta reboot.
      
      With PAE enabled this works by chance because the PGD entry which covers
      the fixmap and other parts incindentally provides the cpu_entry_area
      mapping as well.
      
      Synchronize the initial page table after setting up the cpu entry
      area. Instead of adding yet another copy of the same code, move it to a
      function and invoke it from the various places.
      
      It needs to be investigated if the existing calls in setup_arch() and
      setup_per_cpu_areas() can be replaced by the later invocation from
      setup_cpu_entry_areas(), but that's beyond the scope of this fix.
      
      Fixes: 92a0f81d ("x86/cpu_entry_area: Move it out of the fixmap")
      Reported-by: NWoody Suwalski <terraluna977@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NWoody Suwalski <terraluna977@gmail.com>
      Cc: William Grant <william.grant@canonical.com>
      Cc: stable@vger.kernel.org
      Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1802282137290.1392@nanos.tec.linutronix.de
      945fd17a
  5. 14 2月, 2018 1 次提交
    • K
      x86/mm: Make MAX_PHYSADDR_BITS and MAX_PHYSMEM_BITS dynamic · 162434e7
      Kirill A. Shutemov 提交于
      For boot-time switching between paging modes, we need to be able to
      adjust size of physical address space at runtime.
      
      As part of making physical address space size variable, we have to make
      X86_5LEVEL dependent on SPARSEMEM_VMEMMAP. !SPARSEMEM_VMEMMAP
      configuration doesn't build with variable MAX_PHYSMEM_BITS.
      
      For !SPARSEMEM_VMEMMAP SECTIONS_WIDTH depends on MAX_PHYSMEM_BITS:
      
      SECTIONS_WIDTH
        SECTIONS_SHIFT
          MAX_PHYSMEM_BITS
      
      And SECTIONS_WIDTH is used on pre-processor stage, it doesn't work if it's
      dyncamic. See include/linux/page-flags-layout.h.
      
      Effect on kernel image size:
      
         text	   data	    bss	    dec	    hex	filename
      8628393	4734340	1368064	14730797	 e0c62d	vmlinux.before
      8628892	4734340	1368064	14731296	 e0c820	vmlinux.after
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20180214111656.88514-8-kirill.shutemov@linux.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      162434e7
  6. 16 1月, 2018 1 次提交
  7. 03 1月, 2018 1 次提交
  8. 12 12月, 2017 1 次提交
  9. 10 11月, 2017 1 次提交
  10. 07 11月, 2017 1 次提交
  11. 04 10月, 2017 1 次提交
    • J
      x86/boot: Spell out "boot CPU" for BP · a1652bb8
      Jean Delvare 提交于
      It's not obvious to everybody that BP stands for boot processor. At
      least it was not for me. And BP is also a CPU register on x86, so it
      is ambiguous. Spell out "boot CPU" everywhere instead.
      Signed-off-by: NJean Delvare <jdelvare@suse.de>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      a1652bb8
  12. 26 9月, 2017 1 次提交
    • T
      x86/apic: Sanitize 32/64bit APIC callbacks · 64063505
      Thomas Gleixner 提交于
      The 32bit and the 64bit implementation of default_cpu_present_to_apicid()
      and default_check_phys_apicid_present() are exactly the same, but
      implemented and located differently.
      
      Move them to common apic code and get rid of the pointless difference.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Tested-by: NJuergen Gross <jgross@suse.com>
      Tested-by: NYu Chen <yu.c.chen@intel.com>
      Acked-by: NJuergen Gross <jgross@suse.com>
      Cc: Boris Ostrovsky <boris.ostrovsky@oracle.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Alok Kataria <akataria@vmware.com>
      Cc: Joerg Roedel <joro@8bytes.org>
      Cc: "Rafael J. Wysocki" <rjw@rjwysocki.net>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Rui Zhang <rui.zhang@intel.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Dan Williams <dan.j.williams@intel.com>
      Cc: Len Brown <lenb@kernel.org>
      Link: https://lkml.kernel.org/r/20170913213153.757329991@linutronix.de
      64063505
  13. 25 9月, 2017 2 次提交
  14. 13 9月, 2017 1 次提交
    • A
      x86/mm/64: Initialize CR4.PCIDE early · c7ad5ad2
      Andy Lutomirski 提交于
      cpu_init() is weird: it's called rather late (after early
      identification and after most MMU state is initialized) on the boot
      CPU but is called extremely early (before identification) on secondary
      CPUs.  It's called just late enough on the boot CPU that its CR4 value
      isn't propagated to mmu_cr4_features.
      
      Even if we put CR4.PCIDE into mmu_cr4_features, we'd hit two
      problems.  First, we'd crash in the trampoline code.  That's
      fixable, and I tried that.  It turns out that mmu_cr4_features is
      totally ignored by secondary_start_64(), though, so even with the
      trampoline code fixed, it wouldn't help.
      
      This means that we don't currently have CR4.PCIDE reliably initialized
      before we start playing with cpu_tlbstate.  This is very fragile and
      tends to cause boot failures if I make even small changes to the TLB
      handling code.
      
      Make it more robust: initialize CR4.PCIDE earlier on the boot CPU
      and propagate it to secondary CPUs in start_secondary().
      
      ( Yes, this is ugly.  I think we should have improved mmu_cr4_features
        to actually control CR4 during secondary bootup, but that would be
        fairly intrusive at this stage. )
      Signed-off-by: NAndy Lutomirski <luto@kernel.org>
      Reported-by: NSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Tested-by: NSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Cc: Borislav Petkov <bpetkov@suse.de>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Fixes: 660da7c9 ("x86/mm: Enable CR4.PCIDE on supported systems")
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      c7ad5ad2
  15. 29 8月, 2017 1 次提交
  16. 04 8月, 2017 1 次提交
    • L
      treewide: Consolidate Apple DMI checks · 630b3aff
      Lukas Wunner 提交于
      We're about to amend ACPI bus scan with DMI checks whether we're running
      on a Mac to support Apple device properties in AML.  The DMI checks are
      performed for every single device, adding overhead for everything x86
      that isn't Apple, which is the majority.  Rafael and Andy therefore
      request to perform the DMI match only once and cache the result.
      
      Outside of ACPI various other Apple DMI checks exist and it seems
      reasonable to use the cached value there as well.  Rafael, Andy and
      Darren suggest performing the DMI check in arch code and making it
      available with a header in include/linux/platform_data/x86/.
      
      To this end, add early_platform_quirks() to arch/x86/kernel/quirks.c
      to perform the DMI check and invoke it from setup_arch().  Switch over
      all existing Apple DMI checks, thereby fixing two deficiencies:
      
      * They are now #defined to false on non-x86 arches and can thus be
        optimized away if they're located in cross-arch code.
      
      * Some of them only match "Apple Inc." but not "Apple Computer, Inc.",
        which is used by BIOSes released between January 2006 (when the first
        x86 Macs started shipping) and January 2007 (when the company name
        changed upon introduction of the iPhone).
      Suggested-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Suggested-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Suggested-by: NDarren Hart <dvhart@infradead.org>
      Signed-off-by: NLukas Wunner <lukas@wunner.de>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      630b3aff
  17. 26 7月, 2017 1 次提交
    • J
      x86/unwind: Add the ORC unwinder · ee9f8fce
      Josh Poimboeuf 提交于
      Add the new ORC unwinder which is enabled by CONFIG_ORC_UNWINDER=y.
      It plugs into the existing x86 unwinder framework.
      
      It relies on objtool to generate the needed .orc_unwind and
      .orc_unwind_ip sections.
      
      For more details on why ORC is used instead of DWARF, see
      Documentation/x86/orc-unwinder.txt - but the short version is
      that it's a simplified, fundamentally more robust debugninfo
      data structure, which also allows up to two orders of magnitude
      faster lookups than the DWARF unwinder - which matters to
      profiling workloads like perf.
      
      Thanks to Andy Lutomirski for the performance improvement ideas:
      splitting the ORC unwind table into two parallel arrays and creating a
      fast lookup table to search a subset of the unwind table.
      Signed-off-by: NJosh Poimboeuf <jpoimboe@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: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/0a6cbfb40f8da99b7a45a1a8302dc6aef16ec812.1500938583.git.jpoimboe@redhat.com
      [ Extended the changelog. ]
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      ee9f8fce
  18. 18 7月, 2017 1 次提交
    • T
      x86/mm: Insure that boot memory areas are mapped properly · b9d05200
      Tom Lendacky 提交于
      The boot data and command line data are present in memory in a decrypted
      state and are copied early in the boot process.  The early page fault
      support will map these areas as encrypted, so before attempting to copy
      them, add decrypted mappings so the data is accessed properly when copied.
      
      For the initrd, encrypt this data in place. Since the future mapping of
      the initrd area will be mapped as encrypted the data will be accessed
      properly.
      Signed-off-by: NTom Lendacky <thomas.lendacky@amd.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Alexander Potapenko <glider@google.com>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brijesh Singh <brijesh.singh@amd.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Larry Woodman <lwoodman@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Michael S. Tsirkin <mst@redhat.com>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Toshimitsu Kani <toshi.kani@hpe.com>
      Cc: kasan-dev@googlegroups.com
      Cc: kvm@vger.kernel.org
      Cc: linux-arch@vger.kernel.org
      Cc: linux-doc@vger.kernel.org
      Cc: linux-efi@vger.kernel.org
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/bb0d430b41efefd45ee515aaf0979dcfda8b6a44.1500319216.git.thomas.lendacky@amd.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      b9d05200
  19. 05 7月, 2017 1 次提交
    • M
      x86/mm/pat: Don't report PAT on CPUs that don't support it · 99c13b8c
      Mikulas Patocka 提交于
      The pat_enabled() logic is broken on CPUs which do not support PAT and
      where the initialization code fails to call pat_init(). Due to that the
      enabled flag stays true and pat_enabled() returns true wrongfully.
      
      As a consequence the mappings, e.g. for Xorg, are set up with the wrong
      caching mode and the required MTRR setups are omitted.
      
      To cure this the following changes are required:
      
        1) Make pat_enabled() return true only if PAT initialization was
           invoked and successful.
      
        2) Invoke init_cache_modes() unconditionally in setup_arch() and
           remove the extra callsites in pat_disable() and the pat disabled
           code path in pat_init().
      
      Also rename __pat_enabled to pat_disabled to reflect the real purpose of
      this variable.
      
      Fixes: 9cd25aac ("x86/mm/pat: Emulate PAT when it is disabled")
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Bernhard Held <berny156@gmx.de>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: "Luis R. Rodriguez" <mcgrof@suse.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/alpine.LRH.2.02.1707041749300.3456@file01.intranet.prod.int.rdu2.redhat.com
      99c13b8c
  20. 22 6月, 2017 1 次提交
    • J
      x86/debug: Extend the lower bound of crash kernel low reservations · fe2d48b8
      Jiri Bohac 提交于
      The following change in 2013:
      
        0212f915 ("x86: Add Crash kernel low reservation")
      
      ... introduced reserve_crashkernel_low(). This function is used to
      reserve crash kernel memory either if crashkernel=size,low is given
      on the command line or if the region reserved by reserve_crashkernel
      is entirely above 4G.
      
      reserve_crashkernel_low() tries to find a block of 'low_size' bytes.
      But there seems to be no good reason to restrict the lower bound
      of the range to 'low_size'.
      
      Make memblock_find_in_range() search from the start of memory.
      Signed-off-by: NJiri Bohac <jbohac@suse.cz>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Link: http://lkml.kernel.org/r/20170616161602.2r7birrf2y3ylv6v@dwarf.suse.czSigned-off-by: NIngo Molnar <mingo@kernel.org>
      fe2d48b8
  21. 26 5月, 2017 1 次提交
  22. 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
  23. 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
  24. 21 3月, 2017 2 次提交
  25. 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
  26. 07 2月, 2017 1 次提交
  27. 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
  28. 28 1月, 2017 5 次提交
    • 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