1. 17 Apr, 2014 2 commits
    • Ricardo Neri's avatar
      x86/efi: Implement a __efi_call_virt macro · 982e239c
      Ricardo Neri authored
      For i386, all the EFI system runtime services functions return efi_status_t
      except efi_reset_system_system. Therefore, not all functions can be covered
      by the same macro in case the macro needs to do more than calling the function
      (i.e., return a value). The purpose of the __efi_call_virt macro is to be used
      when no return value is expected.
      For x86_64, this macro would not be needed as all the runtime services return
      u64. However, the same code is used for both x86_64 and i386. Thus, the macro
      __efi_call_virt is also defined to not break compilation.
      Signed-off-by: default avatarRicardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Matt Fleming's avatar
      x86/efi: Delete most of the efi_call* macros · 62fa6e69
      Matt Fleming authored
      We really only need one phys and one virt function call, and then only
      one assembly function to make firmware calls.
      Since we are not using the C type system anyway, we're not really losing
      much by deleting the macros apart from no longer having a check that
      we are passing the correct number of parameters. The lack of duplicated
      code seems like a worthwhile trade-off.
      Cc: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
      Cc: Borislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  2. 17 Mar, 2014 1 commit
    • Matt Fleming's avatar
      x86/efi: Rip out phys_efi_get_time() · 3f4a7836
      Matt Fleming authored
      Dan reported that phys_efi_get_time() is doing kmalloc(..., GFP_KERNEL)
      under a spinlock which is very clearly a bug. Since phys_efi_get_time()
      has no users let's just delete it instead of trying to fix it.
      Note that since there are no users of phys_efi_get_time(), it is not
      possible to actually trigger a GFP_KERNEL alloc under the spinlock.
      Reported-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Nathan Zimmer <nzimmer@sgi.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Jan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  3. 04 Mar, 2014 11 commits
    • Borislav Petkov's avatar
      x86/efi: Quirk out SGI UV · a5d90c92
      Borislav Petkov authored
      Alex reported hitting the following BUG after the EFI 1:1 virtual
      mapping work was merged,
       kernel BUG at arch/x86/mm/init_64.c:351!
       invalid opcode: 0000 [#1] SMP
       Call Trace:
        [<ffffffff818aa71d>] init_extra_mapping_uc+0x13/0x15
        [<ffffffff818a5e20>] uv_system_init+0x22b/0x124b
        [<ffffffff8108b886>] ? clockevents_register_device+0x138/0x13d
        [<ffffffff81028dbb>] ? setup_APIC_timer+0xc5/0xc7
        [<ffffffff8108b620>] ? clockevent_delta2ns+0xb/0xd
        [<ffffffff818a3a92>] ? setup_boot_APIC_clock+0x4a8/0x4b7
        [<ffffffff8153d955>] ? printk+0x72/0x74
        [<ffffffff818a1757>] native_smp_prepare_cpus+0x389/0x3d6
        [<ffffffff818957bc>] kernel_init_freeable+0xb7/0x1fb
        [<ffffffff81535530>] ? rest_init+0x74/0x74
        [<ffffffff81535539>] kernel_init+0x9/0xff
        [<ffffffff81541dfc>] ret_from_fork+0x7c/0xb0
        [<ffffffff81535530>] ? rest_init+0x74/0x74
      Getting this thing to work with the new mapping scheme would need more
      work, so automatically switch to the old memmap layout for SGI UV.
      Acked-by: default avatarRuss Anderson <rja@sgi.com>
      Cc: Alex Thorlton <athorlton@sgi.com
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Matt Fleming's avatar
      x86/efi: Wire up CONFIG_EFI_MIXED · 7d453eee
      Matt Fleming authored
      Add the Kconfig option and bump the kernel header version so that boot
      loaders can check whether the handover code is available if they want.
      The xloadflags field in the bzImage header is also updated to reflect
      that the kernel supports both entry points by setting both of
      XLF_CAN_BE_LOADED_ABOVE_4G is disabled so that the kernel text is
      guaranteed to be addressable with 32-bits.
      Note that no boot loaders should be using the bits set in xloadflags to
      decide which entry point to jump to. The entire scheme is based on the
      concept that 32-bit bootloaders always jump to ->handover_offset and
      64-bit loaders always jump to ->handover_offset + 512. We set both bits
      merely to inform the boot loader that it's safe to use the native
      handover offset even if the machine type in the PE/COFF header claims
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Matt Fleming's avatar
      x86/efi: Add mixed runtime services support · 4f9dbcfc
      Matt Fleming authored
      Setup the runtime services based on whether we're booting in EFI native
      mode or not. For non-native mode we need to thunk from 64-bit into
      32-bit mode before invoking the EFI runtime services.
      Using the runtime services after SetVirtualAddressMap() is slightly more
      complicated because we need to ensure that all the addresses we pass to
      the firmware are below the 4GB boundary so that they can be addressed
      with 32-bit pointers, see efi_setup_page_tables().
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Matt Fleming's avatar
      x86/efi: Delete dead code when checking for non-native · 099240ac
      Matt Fleming authored
      Both efi_free_boot_services() and efi_enter_virtual_mode() are invoked
      from init/main.c, but only if the EFI runtime services are available.
      This is not the case for non-native boots, e.g. where a 64-bit kernel is
      booted with 32-bit EFI firmware.
      Delete the dead code.
      Acked-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Borislav Petkov's avatar
      x86/efi: Split efi_enter_virtual_mode · fabb37c7
      Borislav Petkov authored
      ... into a kexec flavor for better code readability and simplicity. The
      original one was getting ugly with ifdeffery.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Borislav Petkov's avatar
      x86/efi: Make efi virtual runtime map passing more robust · b7b898ae
      Borislav Petkov authored
      Currently, running SetVirtualAddressMap() and passing the physical
      address of the virtual map array was working only by a lucky coincidence
      because the memory was present in the EFI page table too. Until Toshi
      went and booted this on a big HP box - the krealloc() manner of resizing
      the memmap we're doing did allocate from such physical addresses which
      were not mapped anymore and boom:
      One way to take care of that issue is to reimplement the krealloc thing
      but with pages. We start with contiguous pages of order 1, i.e. 2 pages,
      and when we deplete that memory (shouldn't happen all that often but you
      know firmware) we realloc the next power-of-two pages.
      Having the pages, it is much more handy and easy to map them into the
      EFI page table with the already existing mapping code which we're using
      for building the virtual mappings.
      Thanks to Toshi Kani and Matt for the great debugging help.
      Reported-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Borislav Petkov's avatar
      x86/efi: Dump the EFI page table · 11cc8512
      Borislav Petkov authored
      This is very useful for debugging issues with the recently added
      pagetable switching code for EFI virtual mode.
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Joe Perches's avatar
      x86/efi: Style neatening · 9b7d2049
      Joe Perches authored
      Coalesce formats and remove spaces before tabs.
      Move __initdata after the variable declaration.
      Signed-off-by: default avatarJoe Perches <joe@perches.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Madper Xie's avatar
      x86/efi: Delete out-of-date comments of efi_query_variable_store · 5db80c65
      Madper Xie authored
      For now we only ensure about 5kb free space for avoiding our board
      refusing boot. But the comment lies that we retain 50% space.
      Signed-off-by: default avatarMadper Xie <cxie@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Matt Fleming's avatar
      efi: Set feature flags inside feature init functions · 0f8093a9
      Matt Fleming authored
      It makes more sense to set the feature flag in the success path of the
      detection function than it does to rely on the caller doing it. Apart
      from it being more logical to group the code and data together, it sets
      a much better example for new EFI architectures.
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Matt Fleming's avatar
      efi: Move facility flags to struct efi · 3e909599
      Matt Fleming authored
      As we grow support for more EFI architectures they're going to want the
      ability to query which EFI features are available on the running system.
      Instead of storing this information in an architecture-specific place,
      stick it in the global 'struct efi', which is already the central
      location for EFI state.
      While we're at it, let's change the return value of efi_enabled() to be
      bool and replace all references to 'facility' with 'feature', which is
      the usual word used to describe the attributes of the running system.
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  4. 14 Feb, 2014 1 commit
  5. 29 Dec, 2013 2 commits
    • Matt Fleming's avatar
      x86/efi: Delete superfluous global variables · 518548ab
      Matt Fleming authored
      There's no need to save the runtime map details in global variables, the
      values are only required to pass to efi_runtime_map_setup().
      And because 'nr_efi_runtime_map' isn't needed, get_nr_runtime_map() can
      be deleted along with 'efi_data_len'.
      Cc: Dave Young <dyoung@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Dave Young's avatar
      x86/efi: Pass necessary EFI data for kexec via setup_data · 1fec0533
      Dave Young authored
      Add a new setup_data type SETUP_EFI for kexec use.  Passing the saved
      fw_vendor, runtime, config tables and EFI runtime mappings.
      When entering virtual mode, directly mapping the EFI runtime regions
      which we passed in previously. And skip the step to call
      Specially for HP z420 workstation we need save the smbios physical
      address.  The kernel boot sequence proceeds in the following order.
      Step 2 requires efi.smbios to be the physical address.  However, I found
      that on HP z420 EFI system table has a virtual address of SMBIOS in step
      1.  Hence, we need set it back to the physical address with the smbios
      in efi_setup_data.  (When it is still the physical address, it simply
      sets the same value.)
      1. efi_init() - Set efi.smbios from EFI system table
      2. dmi_scan_machine() - Temporary map efi.smbios to access SMBIOS table
      3. efi_enter_virtual_mode() - Map EFI ranges
      Tested on ovmf+qemu, lenovo thinkpad, a dell laptop and an
      HP z420 workstation.
      Signed-off-by: default avatarDave Young <dyoung@redhat.com>
      Tested-by: default avatarToshi Kani <toshi.kani@hp.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  6. 21 Dec, 2013 4 commits
  7. 10 Dec, 2013 1 commit
  8. 02 Nov, 2013 3 commits
  9. 04 Oct, 2013 1 commit
  10. 18 Sep, 2013 1 commit
    • Josh Boyer's avatar
      x86, efi: Don't map Boot Services on i386 · 70087011
      Josh Boyer authored
      Add patch to fix 32bit EFI service mapping (rhbz 726701)
      Multiple people are reporting hitting the following WARNING on i386,
        WARNING: at arch/x86/mm/ioremap.c:102 __ioremap_caller+0x3d3/0x440()
        Modules linked in:
        Pid: 0, comm: swapper Not tainted 3.9.0-rc7+ #95
        Call Trace:
         [<c102b6af>] warn_slowpath_common+0x5f/0x80
         [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
         [<c1023fb3>] ? __ioremap_caller+0x3d3/0x440
         [<c102b6ed>] warn_slowpath_null+0x1d/0x20
         [<c1023fb3>] __ioremap_caller+0x3d3/0x440
         [<c106007b>] ? get_usage_chars+0xfb/0x110
         [<c102d937>] ? vprintk_emit+0x147/0x480
         [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
         [<c102406a>] ioremap_cache+0x1a/0x20
         [<c1418593>] ? efi_enter_virtual_mode+0x1e4/0x3de
         [<c1418593>] efi_enter_virtual_mode+0x1e4/0x3de
         [<c1407984>] start_kernel+0x286/0x2f4
         [<c1407535>] ? repair_env_string+0x51/0x51
         [<c1407362>] i386_start_kernel+0x12c/0x12f
      Due to the workaround described in commit 916f676f ("x86, efi: Retain
      boot service code until after switching to virtual mode") EFI Boot
      Service regions are mapped for a period during boot. Unfortunately, with
      the limited size of the i386 direct kernel map it's possible that some
      of the Boot Service regions will not be directly accessible, which
      causes them to be ioremap()'d, triggering the above warning as the
      regions are marked as E820_RAM in the e820 memmap.
      There are currently only two situations where we need to map EFI Boot
      Service regions,
        1. To workaround the firmware bug described in 916f676f
        2. To access the ACPI BGRT image
      but since we haven't seen an i386 implementation that requires either,
      this simple fix should suffice for now.
      [ Added to changelog - Matt ]
      Reported-by: default avatarBryan O'Donoghue <bryan.odonoghue.lkml@nexus-software.ie>
      Acked-by: default avatarTom Zanussi <tom.zanussi@intel.com>
      Acked-by: default avatarDarren Hart <dvhart@linux.intel.com>
      Cc: Josh Triplett <josh@joshtriplett.org>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarJosh Boyer <jwboyer@redhat.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  11. 05 Sep, 2013 2 commits
  12. 11 Jul, 2013 1 commit
  13. 21 Jun, 2013 1 commit
  14. 10 Jun, 2013 1 commit
    • Matthew Garrett's avatar
      Modify UEFI anti-bricking code · f8b84043
      Matthew Garrett authored
      This patch reworks the UEFI anti-bricking code, including an effective
      reversion of cc5a080c and 31ff2f20
      . It turns out that calling
      QueryVariableInfo() from boot services results in some firmware
      implementations jumping to physical addresses even after entering virtual
      mode, so until we have 1:1 mappings for UEFI runtime space this isn't
      going to work so well.
      Reverting these gets us back to the situation where we'd refuse to create
      variables on some systems because they classify deleted variables as "used"
      until the firmware triggers a garbage collection run, which they won't do
      until they reach a lower threshold. This results in it being impossible to
      install a bootloader, which is unhelpful.
      Feedback from Samsung indicates that the firmware doesn't need more than
      5KB of storage space for its own purposes, so that seems like a reasonable
      threshold. However, there's still no guarantee that a platform will attempt
      garbage collection merely because it drops below this threshold. It seems
      that this is often only triggered if an attempt to write generates a
      genuine EFI_OUT_OF_RESOURCES error. We can force that by attempting to
      create a variable larger than the remaining space. This should fail, but if
      it somehow succeeds we can then immediately delete it.
      I've tested this on the UEFI machines I have available, but I don't have
      a Samsung and so can't verify that it avoids the bricking problem.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: Lee, Chun-Y <jlee@suse.com> [ dummy variable cleanup ]
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  15. 06 Jun, 2013 1 commit
  16. 28 May, 2013 1 commit
    • David Vrabel's avatar
      x86: Increase precision of x86_platform.get/set_wallclock() · 3565184e
      David Vrabel authored
      All the virtualized platforms (KVM, lguest and Xen) have persistent
      wallclocks that have more than one second of precision.
      read_persistent_wallclock() and update_persistent_wallclock() allow
      for nanosecond precision but their implementation on x86 with
      x86_platform.get/set_wallclock() only allows for one second precision.
      This means guests may see a wallclock time that is off by up to 1
      Make set_wallclock() and get_wallclock() take a struct timespec
      parameter (which allows for nanosecond precision) so KVM and Xen
      guests may start with a more accurate wallclock time and a Xen dom0
      can maintain a more accurate wallclock for guests.
      Signed-off-by: default avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
  17. 14 May, 2013 1 commit
    • Lee, Chun-Yi's avatar
      x86, efi: initial the local variable of DataSize to zero · eccaf52f
      Lee, Chun-Yi authored
      That will be better initial the value of DataSize to zero for the input of
      GetVariable(), otherwise we will feed a random value. The debug log of input
      DataSize like this:
      [  195.915612] EFI Variables Facility v0.08 2004-May-17
      [  195.915819] efi: size: 18446744071581821342
      [  195.915969] efi:  size': 18446744071581821342
      [  195.916324] efi: size: 18446612150714306560
      [  195.916632] efi:  size': 18446612150714306560
      [  195.917159] efi: size: 18446612150714306560
      [  195.917453] efi:  size': 18446612150714306560
      The size' is value that was returned by BIOS.
      After applied this patch:
      [   82.442042] EFI Variables Facility v0.08 2004-May-17
      [   82.442202] efi: size: 0
      [   82.442360] efi:  size': 1039
      [   82.443828] efi: size: 0
      [   82.444127] efi:  size': 2616
      [   82.447057] efi: size: 0
      [   82.447356] efi:  size': 5832
      Found on Acer Aspire V3 BIOS, it will not return the size of data if we input a
      non-zero DataSize.
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: default avatarLee, Chun-Yi <jlee@suse.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
  18. 29 Apr, 2013 1 commit
  19. 17 Apr, 2013 1 commit
  20. 16 Apr, 2013 1 commit
  21. 15 Apr, 2013 2 commits
    • Matthew Garrett's avatar
      efi: Distinguish between "remaining space" and actually used space · 31ff2f20
      Matthew Garrett authored
      EFI implementations distinguish between space that is actively used by a
      variable and space that merely hasn't been garbage collected yet. Space
      that hasn't yet been garbage collected isn't available for use and so isn't
      counted in the remaining_space field returned by QueryVariableInfo().
      Combined with commit 68d92986 this can cause problems. Some implementations
      don't garbage collect until the remaining space is smaller than the maximum
      variable size, and as a result check_var_size() will always fail once more
      than 50% of the variable store has been used even if most of that space is
      marked as available for garbage collection. The user is unable to create
      new variables, and deleting variables doesn't increase the remaining space.
      The problem that 68d92986 was attempting to avoid was one where certain
      platforms fail if the actively used space is greater than 50% of the
      available storage space. We should be able to calculate that by simply
      summing the size of each available variable and subtracting that from
      the total storage space. With luck this will fix the problem described in
      https://bugzilla.kernel.org/show_bug.cgi?id=55471 without permitting
      damage to occur to the machines 68d92986
       was attempting to fix.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
    • Matthew Garrett's avatar
      efi: Pass boot services variable info to runtime code · cc5a080c
      Matthew Garrett authored
      EFI variables can be flagged as being accessible only within boot services.
      This makes it awkward for us to figure out how much space they use at
      runtime. In theory we could figure this out by simply comparing the results
      from QueryVariableInfo() to the space used by all of our variables, but
      that fails if the platform doesn't garbage collect on every boot. Thankfully,
      calling QueryVariableInfo() while still inside boot services gives a more
      reliable answer. This patch passes that information from the EFI boot stub
      up to the efi platform code.
      Signed-off-by: default avatarMatthew Garrett <matthew.garrett@nebula.com>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>