1. 13 Feb, 2013 1 commit
    • Satoru Takeuchi's avatar
      efi: Clear EFI_RUNTIME_SERVICES rather than EFI_BOOT by "noefi" boot parameter · 1de63d60
      Satoru Takeuchi authored
      There was a serious problem in samsung-laptop that its platform driver is
      designed to run under BIOS and running under EFI can cause the machine to
      become bricked or can cause Machine Check Exceptions.
      
          Discussion about this problem:
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
          The patches to fix this problem:
          efi: Make 'efi_enabled' a function to query EFI facilities
          83e68189
      
          samsung-laptop: Disable on EFI hardware
          e0094244
      
      
      
      Unfortunately this problem comes back again if users specify "noefi" option.
      This parameter clears EFI_BOOT and that driver continues to run even if running
      under EFI. Refer to the document, this parameter should clear
      EFI_RUNTIME_SERVICES instead.
      
      Documentation/kernel-parameters.txt:
      ===============================================================================
      ...
      	noefi		[X86] Disable EFI runtime services support.
      ...
      ===============================================================================
      
      Documentation/x86/x86_64/uefi.txt:
      ===============================================================================
      ...
      - If some or all EFI runtime services don't work, you can try following
        kernel command line parameters to turn off some or all EFI runtime
        services.
      	noefi		turn off all EFI runtime services
      ...
      ===============================================================================
      Signed-off-by: default avatarSatoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
      Link: http://lkml.kernel.org/r/511C2C04.2070108@jp.fujitsu.com
      
      
      Cc: Matt Fleming <matt.fleming@intel.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      1de63d60
  2. 30 Jan, 2013 1 commit
    • Matt Fleming's avatar
      efi: Make 'efi_enabled' a function to query EFI facilities · 83e68189
      Matt Fleming authored
      Originally 'efi_enabled' indicated whether a kernel was booted from
      EFI firmware. Over time its semantics have changed, and it now
      indicates whether or not we are booted on an EFI machine with
      bit-native firmware, e.g. 64-bit kernel with 64-bit firmware.
      
      The immediate motivation for this patch is the bug report at,
      
          https://bugs.launchpad.net/ubuntu-cdimage/+bug/1040557
      
      which details how running a platform driver on an EFI machine that is
      designed to run under BIOS can cause the machine to become
      bricked. Also, the following report,
      
          https://bugzilla.kernel.org/show_bug.cgi?id=47121
      
      
      
      details how running said driver can also cause Machine Check
      Exceptions. Drivers need a new means of detecting whether they're
      running on an EFI machine, as sadly the expression,
      
          if (!efi_enabled)
      
      hasn't been a sufficient condition for quite some time.
      
      Users actually want to query 'efi_enabled' for different reasons -
      what they really want access to is the list of available EFI
      facilities.
      
      For instance, the x86 reboot code needs to know whether it can invoke
      the ResetSystem() function provided by the EFI runtime services, while
      the ACPI OSL code wants to know whether the EFI config tables were
      mapped successfully. There are also checks in some of the platform
      driver code to simply see if they're running on an EFI machine (which
      would make it a bad idea to do BIOS-y things).
      
      This patch is a prereq for the samsung-laptop fix patch.
      
      Cc: David Airlie <airlied@linux.ie>
      Cc: Corentin Chary <corentincj@iksaif.net>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Dave Jiang <dave.jiang@intel.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Peter Jones <pjones@redhat.com>
      Cc: Colin Ian King <colin.king@canonical.com>
      Cc: Steve Langasek <steve.langasek@canonical.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Konrad Rzeszutek Wilk <konrad@kernel.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      83e68189
  3. 25 Jan, 2013 1 commit
    • Matt Fleming's avatar
      x86, efi: Set runtime_version to the EFI spec revision · 712ba9e9
      Matt Fleming authored
      
      
      efi.runtime_version is erroneously being set to the value of the
      vendor's firmware revision instead of that of the implemented EFI
      specification. We can't deduce which EFI functions are available based
      on the revision of the vendor's firmware since the version scheme is
      likely to be unique to each vendor.
      
      What we really need to know is the revision of the implemented EFI
      specification, which is available in the EFI System Table header.
      
      Cc: Seiji Aguchi <seiji.aguchi@hds.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: stable@vger.kernel.org # 3.7.x
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      712ba9e9
  4. 15 Dec, 2012 1 commit
  5. 30 Oct, 2012 1 commit
    • Jan Beulich's avatar
      x86-64/efi: Use EFI to deal with platform wall clock (again) · bd52276f
      Jan Beulich authored
      Other than ix86, x86-64 on EFI so far didn't set the
      {g,s}et_wallclock accessors to the EFI routines, thus
      incorrectly using raw RTC accesses instead.
      
      Simply removing the #ifdef around the respective code isn't
      enough, however: While so far early get-time calls were done in
      physical mode, this doesn't work properly for x86-64, as virtual
      addresses would still need to be set up for all runtime regions
      (which wasn't the case on the system I have access to), so
      instead the patch moves the call to efi_enter_virtual_mode()
      ahead (which in turn allows to drop all code related to calling
      efi-get-time in physical mode).
      
      Additionally the earlier calling of efi_set_executable()
      requires the CPA code to cope, i.e. during early boot it must be
      avoided to call cpa_flush_array(), as the first thing this
      function does is a BUG_ON(irqs_disabled()).
      
      Also make the two EFI functions in question here static -
      they're not being referenced elsewhere.
      
      History:
      
          This commit was originally merged as bacef661 ("x86-64/efi:
          Use EFI to deal with platform wall clock") but it resulted in some
          ASUS machines no longer booting due to a firmware bug, and so was
          reverted in f026cfa8
      
      . A pre-emptive fix for the buggy ASUS
          firmware was merged in 03a1c254975e ("x86, efi: 1:1 pagetable
          mapping for virtual EFI calls") so now this patch can be
          reapplied.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Tested-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Acked-by: default avatarMatthew Garrett <mjg@redhat.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Signed-off-by: Matt Fleming <matt.fleming@intel.com> [added commit history]
      bd52276f
  6. 25 Oct, 2012 1 commit
  7. 24 Oct, 2012 1 commit
    • Matt Fleming's avatar
      x86/efi: Fix oops caused by incorrect set_memory_uc() usage · 3e8fa263
      Matt Fleming authored
      Calling __pa() with an ioremap'd address is invalid. If we
      encounter an efi_memory_desc_t without EFI_MEMORY_WB set in
      ->attribute we currently call set_memory_uc(), which in turn
      calls __pa() on a potentially ioremap'd address.
      
      On CONFIG_X86_32 this results in the following oops:
      
        BUG: unable to handle kernel paging request at f7f22280
        IP: [<c10257b9>] reserve_ram_pages_type+0x89/0x210
        *pdpt = 0000000001978001 *pde = 0000000001ffb067 *pte = 0000000000000000
        Oops: 0000 [#1] PREEMPT SMP
        Modules linked in:
      
        Pid: 0, comm: swapper Not tainted 3.0.0-acpi-efi-0805 #3
         EIP: 0060:[<c10257b9>] EFLAGS: 00010202 CPU: 0
         EIP is at reserve_ram_pages_type+0x89/0x210
         EAX: 0070e280 EBX: 38714000 ECX: f7814000 EDX: 00000000
         ESI: 00000000 EDI: 38715000 EBP: c189fef0 ESP: c189fea8
         DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
        Process swapper (pid: 0, ti=c189e000 task=c18bbe60 task.ti=c189e000)
        Stack:
         80000200 ff108000 00000000 c189ff00 00038714 00000000 00000000 c189fed0
         c104f8ca 00038714 00000000 00038715 00000000 00000000 00038715 00000000
         00000010 38715000 c189ff48 c1025aff 38715000 00000000 00000010 00000000
        Call Trace:
         [<c104f8ca>] ? page_is_ram+0x1a/0x40
         [<c1025aff>] reserve_memtype+0xdf/0x2f0
         [<c1024dc9>] set_memory_uc+0x49/0xa0
         [<c19334d0>] efi_enter_virtual_mode+0x1c2/0x3aa
         [<c19216d4>] start_kernel+0x291/0x2f2
         [<c19211c7>] ? loglevel+0x1b/0x1b
         [<c19210bf>] i386_start_kernel+0xbf/0xc8
      
      The only time we can call set_memory_uc() for a memory region is
      when it is part of the direct kernel mapping. For the case where
      we ioremap a memory region we must leave it alone.
      
      This patch reimplements the fix from e8c71062 ("x86, efi:
      Calling __pa() with an ioremap()ed address is invalid") which
      was reverted in e1ad783b because it caused a regression on
      some MacBooks (they hung at boot). The regression was caused
      because the commit only marked EFI_RUNTIME_SERVICES_DATA as
      E820_RESERVED_EFI, when it should have marked all regions that
      have the EFI_MEMORY_RUNTIME attribute.
      
      Despite first impressions, it's not possible to use
      ioremap_cache() to map all cached memory regions on
      CONFIG_X86_64 because of the way that the memory map might be
      configured as detailed in the following bug report,
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=748516
      
      
      
      e.g. some of the EFI memory regions *need* to be mapped as part
      of the direct kernel mapping.
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Huang Ying <huang.ying.caritas@gmail.com>
      Cc: Keith Packard <keithp@keithp.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1350649546-23541-1-git-send-email-matt@console-pimps.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      3e8fa263
  8. 29 Sep, 2012 3 commits
  9. 17 Sep, 2012 1 commit
  10. 14 Aug, 2012 1 commit
  11. 06 Jun, 2012 1 commit
    • Jan Beulich's avatar
      x86-64/efi: Use EFI to deal with platform wall clock · bacef661
      Jan Beulich authored
      
      
      Other than ix86, x86-64 on EFI so far didn't set the
      {g,s}et_wallclock accessors to the EFI routines, thus
      incorrectly using raw RTC accesses instead.
      
      Simply removing the #ifdef around the respective code isn't
      enough, however: While so far early get-time calls were done in
      physical mode, this doesn't work properly for x86-64, as virtual
      addresses would still need to be set up for all runtime regions
      (which wasn't the case on the system I have access to), so
      instead the patch moves the call to efi_enter_virtual_mode()
      ahead (which in turn allows to drop all code related to calling
      efi-get-time in physical mode).
      
      Additionally the earlier calling of efi_set_executable()
      requires the CPA code to cope, i.e. during early boot it must be
      avoided to call cpa_flush_array(), as the first thing this
      function does is a BUG_ON(irqs_disabled()).
      
      Also make the two EFI functions in question here static -
      they're not being referenced elsewhere.
      Signed-off-by: default avatarJan Beulich <jbeulich@suse.com>
      Tested-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Acked-by: default avatarMatthew Garrett <mjg@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/4FBFBF5F020000780008637F@nat28.tlf.novell.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      bacef661
  12. 23 Feb, 2012 5 commits
  13. 12 Dec, 2011 1 commit
  14. 09 Dec, 2011 1 commit
    • Matt Fleming's avatar
      x86, efi: Calling __pa() with an ioremap()ed address is invalid · e8c71062
      Matt Fleming authored
      If we encounter an efi_memory_desc_t without EFI_MEMORY_WB set
      in ->attribute we currently call set_memory_uc(), which in turn
      calls __pa() on a potentially ioremap'd address.
      
      On CONFIG_X86_32 this is invalid, resulting in the following
      oops on some machines:
      
        BUG: unable to handle kernel paging request at f7f22280
        IP: [<c10257b9>] reserve_ram_pages_type+0x89/0x210
        [...]
      
        Call Trace:
         [<c104f8ca>] ? page_is_ram+0x1a/0x40
         [<c1025aff>] reserve_memtype+0xdf/0x2f0
         [<c1024dc9>] set_memory_uc+0x49/0xa0
         [<c19334d0>] efi_enter_virtual_mode+0x1c2/0x3aa
         [<c19216d4>] start_kernel+0x291/0x2f2
         [<c19211c7>] ? loglevel+0x1b/0x1b
         [<c19210bf>] i386_start_kernel+0xbf/0xc8
      
      A better approach to this problem is to map the memory region
      with the correct attributes from the start, instead of modifying
      it after the fact. The uncached case can be handled by
      ioremap_nocache() and the cached by ioremap_cache().
      
      Despite first impressions, it's not possible to use
      ioremap_cache() to map all cached memory regions on
      CONFIG_X86_64 because EFI_RUNTIME_SERVICES_DATA regions really
      don't like being mapped into the vmalloc space, as detailed in
      the following bug report,
      
      	https://bugzilla.redhat.com/show_bug.cgi?id=748516
      
      
      
      Therefore, we need to ensure that any EFI_RUNTIME_SERVICES_DATA
      regions are covered by the direct kernel mapping table on
      CONFIG_X86_64. To accomplish this we now map E820_RESERVED_EFI
      regions via the direct kernel mapping with the initial call to
      init_memory_mapping() in setup_arch(), whereas previously these
      regions wouldn't be mapped if they were after the last E820_RAM
      region until efi_ioremap() was called. Doing it this way allows
      us to delete efi_ioremap() completely.
      Signed-off-by: default avatarMatt Fleming <matt.fleming@intel.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg@redhat.com>
      Cc: Zhang Rui <rui.zhang@intel.com>
      Cc: Huang Ying <huang.ying.caritas@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/r/1321621751-3650-1-git-send-email-matt@console-pimps.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      e8c71062
  15. 05 Dec, 2011 1 commit
  16. 31 Oct, 2011 1 commit
    • Paul Gortmaker's avatar
      x86: Fix files explicitly requiring export.h for EXPORT_SYMBOL/THIS_MODULE · 69c60c88
      Paul Gortmaker authored
      
      
      These files were implicitly getting EXPORT_SYMBOL via device.h
      which was including module.h, but that will be fixed up shortly.
      
      By fixing these now, we can avoid seeing things like:
      
      arch/x86/kernel/rtc.c:29: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/pci-dma.c:20: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL’
      arch/x86/kernel/e820.c:69: warning: type defaults to ‘int’ in declaration of ‘EXPORT_SYMBOL_GPL’
      
      [ with input from Randy Dunlap <rdunlap@xenotime.net> and also
        from Stephen Rothwell <sfr@canb.auug.org.au> ]
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      69c60c88
  17. 21 Jul, 2011 1 commit
  18. 14 Jul, 2011 1 commit
  19. 13 Jul, 2011 1 commit
  20. 07 Jul, 2011 1 commit
  21. 05 Jul, 2011 1 commit
  22. 18 Jun, 2011 1 commit
  23. 06 Jun, 2011 2 commits
  24. 25 May, 2011 1 commit
    • Matthew Garrett's avatar
      x86, efi: Retain boot service code until after switching to virtual mode · 916f676f
      Matthew Garrett authored
      
      
      UEFI stands for "Unified Extensible Firmware Interface", where "Firmware"
      is an ancient African word meaning "Why do something right when you can
      do it so wrong that children will weep and brave adults will cower before
      you", and "UEI" is Celtic for "We missed DOS so we burned it into your
      ROMs". The UEFI specification provides for runtime services (ie, another
      way for the operating system to be forced to depend on the firmware) and
      we rely on these for certain trivial tasks such as setting up the
      bootloader. But some hardware fails to work if we attempt to use these
      runtime services from physical mode, and so we have to switch into virtual
      mode. So far so dreadful.
      
      The specification makes it clear that the operating system is free to do
      whatever it wants with boot services code after ExitBootServices() has been
      called. SetVirtualAddressMap() can't be called until ExitBootServices() has
      been. So, obviously, a whole bunch of EFI implementations call into boot
      services code when we do that. Since we've been charmingly naive and
      trusted that the specification may be somehow relevant to the real world,
      we've already stuffed a picture of a penguin or something in that address
      space. And just to make things more entertaining, we've also marked it
      non-executable.
      
      This patch allocates the boot services regions during EFI init and makes
      sure that they're executable. Then, after SetVirtualAddressMap(), it
      discards them and everyone lives happily ever after. Except for the ones
      who have to work on EFI, who live sad lives haunted by the knowledge that
      someone's eventually going to write yet another firmware specification.
      
      [ hpa: adding this to urgent with a stable tag since it fixes currently-broken
        hardware.  However, I do not know what the dependencies are and so I do
        not know which -stable versions this may be a candidate for. ]
      Signed-off-by: default avatarMatthew Garrett <mjg@redhat.com>
      Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: <stable@kernel.org>
      916f676f
  25. 09 May, 2011 4 commits
  26. 27 Oct, 2010 1 commit
  27. 27 Aug, 2010 1 commit
  28. 07 Feb, 2010 1 commit
  29. 27 Oct, 2009 1 commit
  30. 16 Sep, 2009 1 commit