1. 04 Dec, 2019 1 commit
    • Dave Young's avatar
      x86/efi: Update e820 with reserved EFI boot services data to fix kexec breakage · af164898
      Dave Young authored
      
      
      Michael Weiser reported that he got this error during a kexec rebooting:
      
        esrt: Unsupported ESRT version 2904149718861218184.
      
      The ESRT memory stays in EFI boot services data, and it was reserved
      in kernel via efi_mem_reserve().  The initial purpose of the reservation
      is to reuse the EFI boot services data across kexec reboot. For example
      the BGRT image data and some ESRT memory like Michael reported.
      
      But although the memory is reserved it is not updated in the X86 E820 table,
      and kexec_file_load() iterates system RAM in the IO resource list to find places
      for kernel, initramfs and other stuff. In Michael's case the kexec loaded
      initramfs overwrote the ESRT memory and then the failure happened.
      
      Since kexec_file_load() depends on the E820 table being updated, just fix this
      by updating the reserved EFI boot services memory as reserved type in E820.
      
      Originally any memory descriptors with EFI_MEMORY_RUNTIME attribute are
      bypassed in the reservation code path because they are assumed as reserved.
      
      But the reservation is still needed for multiple kexec reboots,
      and it is the only possible case we come here thus just drop the code
      chunk, then everything works without side effects.
      
      On my machine the ESRT memory sits in an EFI runtime data range, it does
      not trigger the problem, but I successfully tested with BGRT instead.
      both kexec_load() and kexec_file_load() work and kdump works as well.
      
      [ mingo: Edited the changelog. ]
      
      Reported-by: default avatarMichael Weiser <michael@weiser.dinsnail.net>
      Tested-by: default avatarMichael Weiser <michael@weiser.dinsnail.net>
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: kexec@lists.infradead.org
      Cc: linux-efi@vger.kernel.org
      Link: https://lkml.kernel.org/r/20191204075233.GA10520@dhcp-128-65.nay.redhat.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      af164898
  2. 07 Nov, 2019 1 commit
  3. 21 Jun, 2019 1 commit
  4. 25 May, 2019 1 commit
  5. 21 May, 2019 1 commit
  6. 29 Mar, 2019 1 commit
  7. 16 Feb, 2019 1 commit
  8. 04 Feb, 2019 1 commit
  9. 22 Dec, 2018 1 commit
    • Sai Praneeth Prakhya's avatar
      x86/efi: Don't unmap EFI boot services code/data regions for EFI_OLD_MEMMAP and EFI_MIXED_MODE · 1debf095
      Sai Praneeth Prakhya authored
      
      
      The following commit:
      
        d5052a7130a6 ("x86/efi: Unmap EFI boot services code/data regions from efi_pgd")
      
      forgets to take two EFI modes into consideration, namely EFI_OLD_MEMMAP and
      EFI_MIXED_MODE:
      
      - EFI_OLD_MEMMAP is a legacy way of mapping EFI regions into swapper_pg_dir
        using ioremap() and init_memory_mapping(). This feature can be enabled by
        passing "efi=old_map" as kernel command line argument. But,
        efi_unmap_pages() unmaps EFI boot services code/data regions *only* from
        efi_pgd and hence cannot be used for unmapping EFI boot services code/data
        regions from swapper_pg_dir.
      
      Introduce a temporary fix to not unmap EFI boot services code/data regions
      when EFI_OLD_MEMMAP is enabled while working on a real fix.
      
      - EFI_MIXED_MODE is another feature where a 64-bit kernel runs on a
        64-bit platform crippled by a 32-bit firmware. To support EFI_MIXED_MODE,
        all RAM (i.e. namely EFI regions like EFI_CONVENTIONAL_MEMORY,
        EFI_LOADER_<CODE/DATA>, EFI_BOOT_SERVICES_<CODE/DATA> and
        EFI_RUNTIME_CODE/DATA regions) is mapped into efi_pgd all the time to
        facilitate EFI runtime calls access it's arguments in 1:1 mode.
      
      Hence, don't unmap EFI boot services code/data regions when booted in mixed mode.
      
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@surriel.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20181222022234.7573-1-sai.praneeth.prakhya@intel.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      1debf095
  10. 30 Nov, 2018 1 commit
    • Sai Praneeth Prakhya's avatar
      x86/efi: Unmap EFI boot services code/data regions from efi_pgd · 08cfb38f
      Sai Praneeth Prakhya authored
      
      
      efi_free_boot_services(), as the name suggests, frees EFI boot services
      code/data regions but forgets to unmap these regions from efi_pgd. This
      means that any code that's running in efi_pgd address space (e.g:
      any EFI runtime service) would still be able to access these regions but
      the contents of these regions would have long been over written by
      someone else. So, it's important to unmap these regions. Hence,
      introduce efi_unmap_pages() to unmap these regions from efi_pgd.
      
      After unmapping EFI boot services code/data regions, any illegal access
      by buggy firmware to these regions would result in page fault which will
      be handled by EFI specific fault handler.
      
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Acked-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arend van Spriel <arend.vanspriel@broadcom.com>
      Cc: Bhupesh Sharma <bhsharma@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Dave Hansen <dave.hansen@intel.com>
      Cc: Eric Snowberg <eric.snowberg@oracle.com>
      Cc: Hans de Goede <hdegoede@redhat.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jon Hunter <jonathanh@nvidia.com>
      Cc: Julien Thierry <julien.thierry@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Nathan Chancellor <natechancellor@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sedat Dilek <sedat.dilek@gmail.com>
      Cc: YiFei Zhu <zhuyifei1999@gmail.com>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20181129171230.18699-6-ard.biesheuvel@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      08cfb38f
  11. 31 Oct, 2018 2 commits
    • Mike Rapoport's avatar
      mm: remove include/linux/bootmem.h · 57c8a661
      Mike Rapoport authored
      Move remaining definitions and declarations from include/linux/bootmem.h
      into include/linux/memblock.h and remove the redundant header.
      
      The includes were replaced with the semantic patch below and then
      semi-automated removal of duplicated '#include <linux/memblock.h>
      
      @@
      @@
      - #include <linux/bootmem.h>
      + #include <linux/memblock.h>
      
      [sfr@canb.auug.org.au: dma-direct: fix up for the removal of linux/bootmem.h]
        Link: http://lkml.kernel.org/r/20181002185342.133d1680@canb.auug.org.au
      [sfr@canb.auug.org.au: powerpc: fix up for removal of linux/bootmem.h]
        Link: http://lkml.kernel.org/r/20181005161406.73ef8727@canb.auug.org.au
      [sfr@canb.auug.org.au: x86/kaslr, ACPI/NUMA: fix for linux/bootmem.h removal]
        Link: http://lkml.kernel.org/r/20181008190341.5e396491@canb.auug.org.au
      Link: http://lkml.kernel.org/r/1536927045-23536-30-git-send-email-rppt@linux.vnet.ibm.com
      
      
      Signed-off-by: default avatarMike Rapoport <rppt@linux.vnet.ibm.com>
      Signed-off-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Serge Semin <fancer.lancer@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      57c8a661
    • Mike Rapoport's avatar
      memblock: replace free_bootmem_late with memblock_free_late · 53ab85eb
      Mike Rapoport authored
      The free_bootmem_late and memblock_free_late do exactly the same thing:
      they iterate over a range and give pages to the page allocator.
      
      Replace calls to free_bootmem_late with calls to memblock_free_late and
      remove the bootmem variant.
      
      Link: http://lkml.kernel.org/r/1536927045-23536-25-git-send-email-rppt@linux.vnet.ibm.com
      
      
      Signed-off-by: default avatarMike Rapoport <rppt@linux.vnet.ibm.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Serge Semin <fancer.lancer@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      53ab85eb
  12. 26 Sep, 2018 1 commit
    • Sai Praneeth's avatar
      efi/x86: Handle page faults occurring while running EFI runtime services · 3425d934
      Sai Praneeth authored
      
      
      Memory accesses performed by UEFI runtime services should be limited to:
      - reading/executing from EFI_RUNTIME_SERVICES_CODE memory regions
      - reading/writing from/to EFI_RUNTIME_SERVICES_DATA memory regions
      - reading/writing by-ref arguments
      - reading/writing from/to the stack.
      
      Accesses outside these regions may cause the kernel to hang because the
      memory region requested by the firmware isn't mapped in efi_pgd, which
      causes a page fault in ring 0 and the kernel fails to handle it, leading
      to die(). To save kernel from hanging, add an EFI specific page fault
      handler which recovers from such faults by
      1. If the efi runtime service is efi_reset_system(), reboot the machine
         through BIOS.
      2. If the efi runtime service is _not_ efi_reset_system(), then freeze
         efi_rts_wq and schedule a new process.
      
      The EFI page fault handler offers us two advantages:
      1. Avoid potential hangs caused by buggy firmware.
      2. Shout loud that the firmware is buggy and hence is not a kernel bug.
      
      Tested-by: default avatarBhupesh Sharma <bhsharma@redhat.com>
      Suggested-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Based-on-code-from: Ricardo Neri <ricardo.neri@intel.com>
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      [ardb: clarify commit log]
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      3425d934
  13. 15 Jul, 2018 2 commits
    • Ard Biesheuvel's avatar
      efi: Drop type and attribute checks in efi_mem_desc_lookup() · 7e1550b8
      Ard Biesheuvel authored
      
      
      The current implementation of efi_mem_desc_lookup() includes the
      following check on the memory descriptor it returns:
      
          if (!(md->attribute & EFI_MEMORY_RUNTIME) &&
              md->type != EFI_BOOT_SERVICES_DATA &&
              md->type != EFI_RUNTIME_SERVICES_DATA) {
                  continue;
          }
      
      This means that only EfiBootServicesData or EfiRuntimeServicesData
      regions are considered, or any other region type provided that it
      has the EFI_MEMORY_RUNTIME attribute set.
      
      Given what the name of the function implies, and the fact that any
      physical address can be described in the UEFI memory map only a single
      time, it does not make sense to impose this condition in the body of the
      loop, but instead, should be imposed by the caller depending on the value
      that is returned to it.
      
      Two such callers exist at the moment:
      
      - The BGRT code when running on x86, via efi_mem_reserve() and
        efi_arch_mem_reserve(). In this case, the region is already known to
        be EfiBootServicesData, and so the check is redundant.
      
      - The ESRT handling code which introduced this function, which calls it
        both directly from efi_esrt_init() and again via efi_mem_reserve() and
        efi_arch_mem_reserve() [on x86].
      
      So let's move this check into the callers instead. This preserves the
      current behavior both for BGRT and ESRT handling, and allows the lookup
      routine to be reused by other [upcoming] users that don't have this
      limitation.
      
      In the ESRT case, keep the entire condition, so that platforms that
      deviate from the UEFI spec and use something other than
      EfiBootServicesData for the ESRT table will keep working as before.
      
      For x86's efi_arch_mem_reserve() implementation, limit the type to
      EfiBootServicesData, since it is the only type the reservation code
      expects to operate on in the first place.
      
      While we're at it, drop the __init annotation so that drivers can use it
      as well.
      
      Tested-by: default avatarLaszlo Ersek <lersek@redhat.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180711094040.12506-8-ard.biesheuvel@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      7e1550b8
    • Sai Praneeth's avatar
      efi/x86: Use non-blocking SetVariable() for efi_delete_dummy_variable() · 5a58bc1b
      Sai Praneeth authored
      
      
      Presently, efi_delete_dummy_variable() uses set_variable() which might
      block, which the scheduler is rightfully upset about when used from
      the idle thread, producing this splat:
      
        "bad: scheduling from the idle thread!"
      
      So, make efi_delete_dummy_variable() use set_variable_nonblocking(),
      which, as the name suggests, doesn't block.
      
      Signed-off-by: default avatarSai Praneeth Prakhya <sai.praneeth.prakhya@intel.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180711094040.12506-3-ard.biesheuvel@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5a58bc1b
  14. 12 Mar, 2018 1 commit
  15. 09 Mar, 2018 1 commit
  16. 03 Jan, 2018 1 commit
    • Ard Biesheuvel's avatar
      efi/capsule-loader: Reinstate virtual capsule mapping · f24c4d47
      Ard Biesheuvel authored
      Commit:
      
        82c3768b ("efi/capsule-loader: Use a cached copy of the capsule header")
      
      ... refactored the capsule loading code that maps the capsule header,
      to avoid having to map it several times.
      
      However, as it turns out, the vmap() call we ended up removing did not
      just map the header, but the entire capsule image, and dropping this
      virtual mapping breaks capsules that are processed by the firmware
      immediately (i.e., without a reboot).
      
      Unfortunately, that change was part of a larger refactor that allowed
      a quirk to be implemented for Quark, which has a non-standard memory
      layout for capsules, and we have slightly painted ourselves into a
      corner by allowing quirk code to mangle the capsule header and memory
      layout.
      
      So we need to fix this without breaking Quark. Fortunately, Quark does
      not appear to care about the virtual mapping, and so we can simply
      do a partial revert of commit:
      
        2a457fb3
      
       ("efi/capsule-loader: Use page addresses rather than struct page pointers")
      
      ... and create a vmap() mapping of the entire capsule (including header)
      based on the reinstated struct page array, unless running on Quark, in
      which case we pass the capsule header copy as before.
      
      Reported-by: default avatarGe Song <ge.song@hxt-semitech.com>
      Tested-by: default avatarBryan O'Donoghue <pure.logic@nexus-software.ie>
      Tested-by: default avatarGe Song <ge.song@hxt-semitech.com>
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: <stable@vger.kernel.org>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 82c3768b ("efi/capsule-loader: Use a cached copy of the capsule header")
      Link: http://lkml.kernel.org/r/20180102172110.17018-3-ard.biesheuvel@linaro.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      f24c4d47
  17. 05 Jun, 2017 1 commit
  18. 28 May, 2017 1 commit
  19. 13 Apr, 2017 1 commit
    • Omar Sandoval's avatar
      x86/efi: Don't try to reserve runtime regions · 6f6266a5
      Omar Sandoval authored
      
      
      Reserving a runtime region results in splitting the EFI memory
      descriptors for the runtime region. This results in runtime region
      descriptors with bogus memory mappings, leading to interesting crashes
      like the following during a kexec:
      
        general protection fault: 0000 [#1] SMP
        Modules linked in:
        CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.11.0-rc1 #53
        Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM05   09/30/2016
        RIP: 0010:virt_efi_set_variable()
        ...
        Call Trace:
         efi_delete_dummy_variable()
         efi_enter_virtual_mode()
         start_kernel()
         ? set_init_arg()
         x86_64_start_reservations()
         x86_64_start_kernel()
         start_cpu()
        ...
        Kernel panic - not syncing: Fatal exception
      
      Runtime regions will not be freed and do not need to be reserved, so
      skip the memmap modification in this case.
      
      Signed-off-by: default avatarOmar Sandoval <osandov@fb.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: <stable@vger.kernel.org> # v4.9+
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 8e80632f ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
      Link: http://lkml.kernel.org/r/20170412152719.9779-2-matt@codeblueprint.co.uk
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      6f6266a5
  20. 28 Jan, 2017 3 commits
    • Ingo Molnar's avatar
      x86/boot/e820: Prefix the E820_* type names with "E820_TYPE_" · 09821ff1
      Ingo Molnar authored
      
      
      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: default avatarIngo Molnar <mingo@kernel.org>
      09821ff1
    • Ingo Molnar's avatar
      x86/boot/e820: Rename e820_any_mapped()/e820_all_mapped() to e820__mapped_any()/e820__mapped_all() · 3bce64f0
      Ingo Molnar authored
      
      
      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: default avatarIngo Molnar <mingo@kernel.org>
      3bce64f0
    • Ingo Molnar's avatar
      x86/boot/e820: Remove spurious asm/e820/api.h inclusions · 5520b7e7
      Ingo Molnar authored
      
      
      A commonly used lowlevel x86 header, asm/pgtable.h, includes asm/e820/api.h
      spuriously, without making direct use of it.
      
      Removing it is not simple: over the years various .c code learned to rely
      on this indirect inclusion.
      
      Remove the unnecessary include - this should speed up the kernel build a bit,
      as a large header is not included anymore in totally unrelated code.
      
      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: default avatarIngo Molnar <mingo@kernel.org>
      5520b7e7
  21. 07 Jan, 2017 1 commit
    • Nicolai Stange's avatar
      x86/efi: Don't allocate memmap through memblock after mm_init() · 20b1e22d
      Nicolai Stange authored
      With the following commit:
      
        4bc9f92e
      
       ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")
      
      ...  efi_bgrt_init() calls into the memblock allocator through
      efi_mem_reserve() => efi_arch_mem_reserve() *after* mm_init() has been called.
      
      Indeed, KASAN reports a bad read access later on in efi_free_boot_services():
      
        BUG: KASAN: use-after-free in efi_free_boot_services+0xae/0x24c
                  at addr ffff88022de12740
        Read of size 4 by task swapper/0/0
        page:ffffea0008b78480 count:0 mapcount:-127
        mapping:          (null) index:0x1 flags: 0x5fff8000000000()
        [...]
        Call Trace:
         dump_stack+0x68/0x9f
         kasan_report_error+0x4c8/0x500
         kasan_report+0x58/0x60
         __asan_load4+0x61/0x80
         efi_free_boot_services+0xae/0x24c
         start_kernel+0x527/0x562
         x86_64_start_reservations+0x24/0x26
         x86_64_start_kernel+0x157/0x17a
         start_cpu+0x5/0x14
      
      The instruction at the given address is the first read from the memmap's
      memory, i.e. the read of md->type in efi_free_boot_services().
      
      Note that the writes earlier in efi_arch_mem_reserve() don't splat because
      they're done through early_memremap()ed addresses.
      
      So, after memblock is gone, allocations should be done through the "normal"
      page allocator. Introduce a helper, efi_memmap_alloc() for this. Use
      it from efi_arch_mem_reserve(), efi_free_boot_services() and, for the sake
      of consistency, from efi_fake_memmap() as well.
      
      Note that for the latter, the memmap allocations cease to be page aligned.
      This isn't needed though.
      
      Tested-by: default avatarDan Williams <dan.j.williams@intel.com>
      Signed-off-by: default avatarNicolai Stange <nicstange@gmail.com>
      Reviewed-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: <stable@vger.kernel.org> # v4.9
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Matt Fleming <matt@codeblueprint.co.uk>
      Cc: Mika Penttilä <mika.penttila@nextfour.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Fixes: 4bc9f92e ("x86/efi-bgrt: Use efi_mem_reserve() to avoid copying image data")
      Link: http://lkml.kernel.org/r/20170105125130.2815-1-nicstange@gmail.com
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      20b1e22d
  22. 20 Sep, 2016 1 commit
    • Matt Fleming's avatar
      x86/efi: Round EFI memmap reservations to EFI_PAGE_SIZE · 92dc3350
      Matt Fleming authored
      Mike Galbraith reported that his machine started rebooting during boot
      after,
      
        commit 8e80632f
      
       ("efi/esrt: Use efi_mem_reserve() and avoid a kmalloc()")
      
      The ESRT table on his machine is 56 bytes and at no point in the
      efi_arch_mem_reserve() call path is that size rounded up to
      EFI_PAGE_SIZE, nor is the start address on an EFI_PAGE_SIZE boundary.
      
      Since the EFI memory map only deals with whole pages, inserting an EFI
      memory region with 56 bytes results in a new entry covering zero
      pages, and completely screws up the calculations for the old regions
      that were trimmed.
      
      Round all sizes upwards, and start addresses downwards, to the nearest
      EFI_PAGE_SIZE boundary.
      
      Additionally, efi_memmap_insert() expects the mem::range::end value to
      be one less than the end address for the region.
      
      Reported-by: default avatarMike Galbraith <umgwanakikbuti@gmail.com>
      Reported-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Tested-by: default avatarMike Krinkin <krinkin.m.u@gmail.com>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Taku Izumi <izumi.taku@jp.fujitsu.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      92dc3350
  23. 09 Sep, 2016 3 commits
    • Matt Fleming's avatar
      efi: Allow drivers to reserve boot services forever · 816e7612
      Matt Fleming authored
      
      
      Today, it is not possible for drivers to reserve EFI boot services for
      access after efi_free_boot_services() has been called on x86. For
      ARM/arm64 it can be done simply by calling memblock_reserve().
      
      Having this ability for all three architectures is desirable for a
      couple of reasons,
      
        1) It saves drivers copying data out of those regions
        2) kexec reboot can now make use of things like ESRT
      
      Instead of using the standard memblock_reserve() which is insufficient
      to reserve the region on x86 (see efi_reserve_boot_services()), a new
      API is introduced in this patch; efi_mem_reserve().
      
      efi.memmap now always represents which EFI memory regions are
      available. On x86 the EFI boot services regions that have not been
      reserved via efi_mem_reserve() will be removed from efi.memmap during
      efi_free_boot_services().
      
      This has implications for kexec, since it is not possible for a newly
      kexec'd kernel to access the same boot services regions that the
      initial boot kernel had access to unless they are reserved by every
      kexec kernel in the chain.
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      816e7612
    • Matt Fleming's avatar
      efi: Add efi_memmap_init_late() for permanent EFI memmap · dca0f971
      Matt Fleming authored
      
      
      Drivers need a way to access the EFI memory map at runtime. ARM and
      arm64 currently provide this by remapping the EFI memory map into the
      vmalloc space before setting up the EFI virtual mappings.
      
      x86 does not provide this functionality which has resulted in the code
      in efi_mem_desc_lookup() where it will manually map individual EFI
      memmap entries if the memmap has already been torn down on x86,
      
        /*
         * If a driver calls this after efi_free_boot_services,
         * ->map will be NULL, and the target may also not be mapped.
         * So just always get our own virtual map on the CPU.
         *
         */
        md = early_memremap(p, sizeof (*md));
      
      There isn't a good reason for not providing a permanent EFI memory map
      for runtime queries, especially since the EFI regions are not mapped
      into the standard kernel page tables.
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      dca0f971
    • Matt Fleming's avatar
      efi: Refactor efi_memmap_init_early() into arch-neutral code · 9479c7ce
      Matt Fleming authored
      
      
      Every EFI architecture apart from ia64 needs to setup the EFI memory
      map at efi.memmap, and the code for doing that is essentially the same
      across all implementations. Therefore, it makes sense to factor this
      out into the common code under drivers/firmware/efi/.
      
      The only slight variation is the data structure out of which we pull
      the initial memory map information, such as physical address, memory
      descriptor size and version, etc. We can address this by passing a
      generic data structure (struct efi_memory_map_data) as the argument to
      efi_memmap_init_early() which contains the minimum info required for
      initialising the memory map.
      
      In the process, this patch also fixes a few undesirable implementation
      differences:
      
       - ARM and arm64 were failing to clear the EFI_MEMMAP bit when
         unmapping the early EFI memory map. EFI_MEMMAP indicates whether
         the EFI memory map is mapped (not the regions contained within) and
         can be traversed.  It's more correct to set the bit as soon as we
         memremap() the passed in EFI memmap.
      
       - Rename efi_unmmap_memmap() to efi_memmap_unmap() to adhere to the
         regular naming scheme.
      
      This patch also uses a read-write mapping for the memory map instead
      of the read-only mapping currently used on ARM and arm64. x86 needs
      the ability to update the memory map in-place when assigning virtual
      addresses to regions (efi_map_region()) and tagging regions when
      reserving boot services (efi_reserve_boot_services()).
      
      There's no way for the generic fake_mem code to know which mapping to
      use without introducing some arch-specific constant/hook, so just use
      read-write since read-only is of dubious value for the EFI memory map.
      
      Tested-by: Dave Young <dyoung@redhat.com> [kexec/kdump]
      Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> [arm]
      Acked-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Leif Lindholm <leif.lindholm@linaro.org>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      9479c7ce
  24. 11 Aug, 2016 1 commit
    • Andy Lutomirski's avatar
      x86/efi: Allocate a trampoline if needed in efi_free_boot_services() · 5bc653b7
      Andy Lutomirski authored
      
      
      On my Dell XPS 13 9350 with firmware 1.4.4 and SGX on, if I boot
      Fedora 24's grub2-efi off a hard disk, my first 1MB of RAM looks
      like:
      
       efi: mem00: [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000000000-0x0000000000000fff] (0MB)
       efi: mem01: [Boot Data          |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000001000-0x0000000000027fff] (0MB)
       efi: mem02: [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000028000-0x0000000000029fff] (0MB)
       efi: mem03: [Reserved           |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002a000-0x000000000002bfff] (0MB)
       efi: mem04: [Runtime Data       |RUN|  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002c000-0x000000000002cfff] (0MB)
       efi: mem05: [Loader Data        |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002d000-0x000000000002dfff] (0MB)
       efi: mem06: [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x000000000002e000-0x0000000000057fff] (0MB)
       efi: mem07: [Reserved           |   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000058000-0x0000000000058fff] (0MB)
       efi: mem08: [Conventional Memory|   |  |  |  |  |  |  |   |WB|WT|WC|UC] range=[0x0000000000059000-0x000000000009ffff] (0MB)
      
      My EBDA is at 0x2c000, which blocks off everything from 0x2c000 and
      up, and my trampoline is 0x6000 bytes (6 pages), so it doesn't fit
      in the loader data range at 0x28000.
      
      Without this patch, it panics due to a failure to allocate the
      trampoline.  With this patch, it works:
      
       [  +0.001744] Base memory trampoline at [ffff880000001000] 1000 size 24576
      
      Signed-off-by: default avatarAndy Lutomirski <luto@kernel.org>
      Reviewed-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      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/998c77b3bf709f3dfed85cb30701ed1a5d8a438b.1470821230.git.luto@kernel.org
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      5bc653b7
  25. 28 Apr, 2016 1 commit
  26. 09 Apr, 2016 1 commit
  27. 12 Mar, 2016 1 commit
    • Matt Fleming's avatar
      x86/efi: Fix boot crash by always mapping boot service regions into new EFI page tables · 452308de
      Matt Fleming authored
      Some machines have EFI regions in page zero (physical address
      0x00000000) and historically that region has been added to the e820
      map via trim_bios_range(), and ultimately mapped into the kernel page
      tables. It was not mapped via efi_map_regions() as one would expect.
      
      Alexis reports that with the new separate EFI page tables some boot
      services regions, such as page zero, are not mapped. This triggers an
      oops during the SetVirtualAddressMap() runtime call.
      
      For the EFI boot services quirk on x86 we need to memblock_reserve()
      boot services regions until after SetVirtualAddressMap(). Doing that
      while respecting the ownership of regions that may have already been
      reserved by the kernel was the motivation behind this commit:
      
        7d68dc3f
      
       ("x86, efi: Do not reserve boot services regions within reserved areas")
      
      That patch was merged at a time when the EFI runtime virtual mappings
      were inserted into the kernel page tables as described above, and the
      trick of setting ->numpages (and hence the region size) to zero to
      track regions that should not be freed in efi_free_boot_services()
      meant that we never mapped those regions in efi_map_regions(). Instead
      we were relying solely on the existing kernel mappings.
      
      Now that we have separate page tables we need to make sure the EFI
      boot services regions are mapped correctly, even if someone else has
      already called memblock_reserve(). Instead of stashing a tag in
      ->numpages, set the EFI_MEMORY_RUNTIME bit of ->attribute. Since it
      generally makes no sense to mark a boot services region as required at
      runtime, it's pretty much guaranteed the firmware will not have
      already set this bit.
      
      For the record, the specific circumstances under which Alexis
      triggered this bug was that an EFI runtime driver on his machine was
      responding to the EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE event during
      SetVirtualAddressMap().
      
      The event handler for this driver looks like this,
      
        sub rsp,0x28
        lea rdx,[rip+0x2445] # 0xaa948720
        mov ecx,0x4
        call func_aa9447c0  ; call to ConvertPointer(4, & 0xaa948720)
        mov r11,QWORD PTR [rip+0x2434] # 0xaa948720
        xor eax,eax
        mov BYTE PTR [r11+0x1],0x1
        add rsp,0x28
        ret
      
      Which is pretty typical code for an EVT_SIGNAL_VIRTUAL_ADDRESS_CHANGE
      handler. The "mov r11, QWORD PTR [rip+0x2424]" was the faulting
      instruction because ConvertPointer() was being called to convert the
      address 0x0000000000000000, which when converted is left unchanged and
      remains 0x0000000000000000.
      
      The output of the oops trace gave the impression of a standard NULL
      pointer dereference bug, but because we're accessing physical
      addresses during ConvertPointer(), it wasn't. EFI boot services code
      is stored at that address on Alexis' machine.
      
      Reported-by: default avatarAlexis Murzeau <amurzeau@gmail.com>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      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: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Raphael Hertzog <hertzog@debian.org>
      Cc: Roger Shimizu <rogershimizu@gmail.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1457695163-29632-2-git-send-email-matt@codeblueprint.co.uk
      Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815125
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      452308de
  28. 03 Feb, 2016 1 commit
    • Ard Biesheuvel's avatar
      efi: Add nonblocking option to efi_query_variable_store() · ca0e30dc
      Ard Biesheuvel authored
      
      
      The function efi_query_variable_store() may be invoked by
      efivar_entry_set_nonblocking(), which itself takes care to only
      call a non-blocking version of the SetVariable() runtime
      wrapper. However, efi_query_variable_store() may call the
      SetVariable() wrapper directly, as well as the wrapper for
      QueryVariableInfo(), both of which could deadlock in the same
      way we are trying to prevent by calling
      efivar_entry_set_nonblocking() in the first place.
      
      So instead, modify efi_query_variable_store() to use the
      non-blocking variants of QueryVariableInfo() (and give up rather
      than free up space if the available space is below
      EFI_MIN_RESERVE) if invoked with the 'nonblocking' argument set
      to true.
      
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      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: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-efi@vger.kernel.org
      Link: http://lkml.kernel.org/r/1454364428-494-5-git-send-email-matt@codeblueprint.co.uk
      
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      ca0e30dc
  29. 19 Jan, 2016 1 commit
  30. 14 Dec, 2015 1 commit
    • Matt Fleming's avatar
      x86/efi: Preface all print statements with efi* tag · 26d7f65f
      Matt Fleming authored
      
      
      The pr_*() calls in the x86 EFI code may or may not include a
      subsystem tag, which makes it difficult to grep the kernel log for all
      relevant EFI messages and leads users to miss important information.
      
      Recently, a bug reporter provided all the EFI print messages from the
      kernel log when trying to diagnose an issue but missed the following
      statement because it wasn't prefixed with anything indicating it was
      related to EFI,
      
        pr_err("Error ident-mapping new memmap (0x%lx)!\n", pa_memmap);
      
      Cc: Borislav Petkov <bp@suse.de>
      Reviewed-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarMatt Fleming <matt@codeblueprint.co.uk>
      26d7f65f
  31. 18 Jul, 2014 1 commit
    • Matt Fleming's avatar
      x86/reboot: Add EFI reboot quirk for ACPI Hardware Reduced flag · 44be28e9
      Matt Fleming authored
      
      
      It appears that the BayTrail-T class of hardware requires EFI in order
      to powerdown and reboot and no other reliable method exists.
      
      This quirk is generally applicable to all hardware that has the ACPI
      Hardware Reduced bit set, since usually ACPI would be the preferred
      method.
      
      Cc: Len Brown <len.brown@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      44be28e9
  32. 19 Jun, 2014 2 commits
    • Matt Fleming's avatar
      x86/efi: Use early_memunmap() to squelch sparse errors · 98a716b6
      Matt Fleming authored
      The kbuild reports the following sparse errors,
      
      >> arch/x86/platform/efi/quirks.c:242:23: sparse: incorrect type in >> argument 1 (different address spaces)
         arch/x86/platform/efi/quirks.c:242:23:    expected void [noderef] <asn:2>*addr
         arch/x86/platform/efi/quirks.c:242:23:    got void *[assigned] tablep
      >> arch/x86/platform/efi/quirks.c:245:23: sparse: incorrect type in >> argument 1 (different address spaces)
         arch/x86/platform/efi/quirks.c:245:23:    expected void [noderef] <asn:2>*addr
         arch/x86/platform/efi/quirks.c:245:23:    got struct efi_setup_data *[assigned] data
      
      Dave Young had made previous attempts to convert the early_iounmap()
      calls to early_memunmap() but ran into merge conflicts with commit
      9e5c33d7
      
       ("mm: create generic early_ioremap() support").
      
      Now that we've got that commit in place we can switch to using
      early_memunmap() since we're already using early_memremap() in
      efi_reuse_config().
      
      Cc: Dave Young <dyoung@redhat.com>
      Cc: Saurabh Tangri <saurabh.tangri@intel.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      98a716b6
    • Saurabh Tangri's avatar
      x86/efi: Move all workarounds to a separate file quirks.c · eeb9db09
      Saurabh Tangri authored
      
      
      Currently, it's difficult to find all the workarounds that are
      applied when running on EFI, because they're littered throughout
      various code paths. This change moves all of them into a separate
      file with the hope that it will be come the single location for all
      our well documented quirks.
      
      Signed-off-by: default avatarSaurabh Tangri <saurabh.tangri@intel.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      eeb9db09