1. 04 10月, 2014 1 次提交
    • M
      x86/efi: Mark initialization code as such · 4e78eb05
      Mathias Krause 提交于
      The 32 bit and 64 bit implementations differ in their __init annotations
      for some functions referenced from the common EFI code. Namely, the 32
      bit variant is missing some of the __init annotations the 64 bit variant
      has.
      
      To solve the colliding annotations, mark the corresponding functions in
      efi_32.c as initialization code, too -- as it is such.
      
      Actually, quite a few more functions are only used during initialization
      and therefore can be marked __init. They are therefore annotated, too.
      Also add the __init annotation to the prototypes in the efi.h header so
      users of those functions will see it's meant as initialization code
      only.
      
      This patch also fixes the "prelog" typo. ("prologue" / "epilogue" might
      be more appropriate but this is C code after all, not an opera! :D)
      Signed-off-by: NMathias Krause <minipli@googlemail.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      4e78eb05
  2. 18 3月, 2014 1 次提交
  3. 05 3月, 2014 3 次提交
  4. 14 2月, 2014 1 次提交
  5. 29 12月, 2013 2 次提交
    • M
      x86/efi: Delete superfluous global variables · 518548ab
      Matt Fleming 提交于
      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: NMatt Fleming <matt.fleming@intel.com>
      518548ab
    • D
      x86/efi: Pass necessary EFI data for kexec via setup_data · 1fec0533
      Dave Young 提交于
      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
      SetVirtualAddressMap().
      
      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: NDave Young <dyoung@redhat.com>
      Tested-by: NToshi Kani <toshi.kani@hp.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      1fec0533
  6. 21 12月, 2013 2 次提交
  7. 02 11月, 2013 1 次提交
    • B
      x86/efi: Runtime services virtual mapping · d2f7cbe7
      Borislav Petkov 提交于
      We map the EFI regions needed for runtime services non-contiguously,
      with preserved alignment on virtual addresses starting from -4G down
      for a total max space of 64G. This way, we provide for stable runtime
      services addresses across kernels so that a kexec'd kernel can still use
      them.
      
      Thus, they're mapped in a separate pagetable so that we don't pollute
      the kernel namespace.
      
      Add an efi= kernel command line parameter for passing miscellaneous
      options and chicken bits from the command line.
      
      While at it, add a chicken bit called "efi=old_map" which can be used as
      a fallback to the old runtime services mapping method in case there's
      some b0rkage with a particular EFI implementation (haha, it is hard to
      hold up the sarcasm here...).
      
      Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt.
      Signed-off-by: NBorislav Petkov <bp@suse.de>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      d2f7cbe7
  8. 30 4月, 2013 1 次提交
  9. 18 1月, 2013 1 次提交
    • N
      efi, x86: Pass a proper identity mapping in efi_call_phys_prelog · b8f2c21d
      Nathan Zimmer 提交于
      Update efi_call_phys_prelog to install an identity mapping of all available
      memory.  This corrects a bug on very large systems with more then 512 GB in
      which bios would not be able to access addresses above not in the mapping.
      
      The result is a crash that looks much like this.
      
      BUG: unable to handle kernel paging request at 000000effd870020
      IP: [<0000000078bce331>] 0x78bce330
      PGD 0
      Oops: 0000 [#1] SMP
      Modules linked in:
      CPU 0
      Pid: 0, comm: swapper/0 Tainted: G        W    3.8.0-rc1-next-20121224-medusa_ntz+ #2 Intel Corp. Stoutland Platform
      RIP: 0010:[<0000000078bce331>]  [<0000000078bce331>] 0x78bce330
      RSP: 0000:ffffffff81601d28  EFLAGS: 00010006
      RAX: 0000000078b80e18 RBX: 0000000000000004 RCX: 0000000000000004
      RDX: 0000000078bcf958 RSI: 0000000000002400 RDI: 8000000000000000
      RBP: 0000000078bcf760 R08: 000000effd870000 R09: 0000000000000000
      R10: 0000000000000000 R11: 00000000000000c3 R12: 0000000000000030
      R13: 000000effd870000 R14: 0000000000000000 R15: ffff88effd870000
      FS:  0000000000000000(0000) GS:ffff88effe400000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 000000effd870020 CR3: 000000000160c000 CR4: 00000000000006b0
      DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
      Process swapper/0 (pid: 0, threadinfo ffffffff81600000, task ffffffff81614400)
      Stack:
       0000000078b80d18 0000000000000004 0000000078bced7b ffff880078b81fff
       0000000000000000 0000000000000082 0000000078bce3a8 0000000000002400
       0000000060000202 0000000078b80da0 0000000078bce45d ffffffff8107cb5a
      Call Trace:
       [<ffffffff8107cb5a>] ? on_each_cpu+0x77/0x83
       [<ffffffff8102f4eb>] ? change_page_attr_set_clr+0x32f/0x3ed
       [<ffffffff81035946>] ? efi_call4+0x46/0x80
       [<ffffffff816c5abb>] ? efi_enter_virtual_mode+0x1f5/0x305
       [<ffffffff816aeb24>] ? start_kernel+0x34a/0x3d2
       [<ffffffff816ae5ed>] ? repair_env_string+0x60/0x60
       [<ffffffff816ae2be>] ? x86_64_start_reservations+0xba/0xc1
       [<ffffffff816ae120>] ? early_idt_handlers+0x120/0x120
       [<ffffffff816ae419>] ? x86_64_start_kernel+0x154/0x163
      Code:  Bad RIP value.
      RIP  [<0000000078bce331>] 0x78bce330
       RSP <ffffffff81601d28>
      CR2: 000000effd870020
      ---[ end trace ead828934fef5eab ]---
      
      Cc: stable@vger.kernel.org
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Signed-off-by: NNathan Zimmer <nzimmer@sgi.com>
      Signed-off-by: NRobin Holt <holt@sgi.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      b8f2c21d
  10. 16 12月, 2012 1 次提交
  11. 30 10月, 2012 1 次提交
    • M
      x86, efi: 1:1 pagetable mapping for virtual EFI calls · 185034e7
      Matt Fleming 提交于
      Some firmware still needs a 1:1 (virt->phys) mapping even after we've
      called SetVirtualAddressMap(). So install the mapping alongside our
      existing kernel mapping whenever we make EFI calls in virtual mode.
      
      This bug was discovered on ASUS machines where the firmware
      implementation of GetTime() accesses the RTC device via physical
      addresses, even though that's bogus per the UEFI spec since we've
      informed the firmware via SetVirtualAddressMap() that the boottime
      memory map is no longer valid.
      
      This bug seems to be present in a lot of consumer devices, so there's
      not a lot we can do about this spec violation apart from workaround
      it.
      
      Cc: JérômeCarretero <cJ-ko@zougloub.eu>
      Cc: Vasco Dias <rafa.vasco@gmail.com>
      Acked-by: NJan Beulich <jbeulich@suse.com>
      Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
      185034e7
  12. 24 10月, 2012 1 次提交
    • M
      x86/efi: Fix oops caused by incorrect set_memory_uc() usage · 3e8fa263
      Matt Fleming 提交于
      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: NMatt 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.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3e8fa263
  13. 13 12月, 2011 1 次提交
  14. 09 12月, 2011 1 次提交
    • M
      x86, efi: Calling __pa() with an ioremap()ed address is invalid · e8c71062
      Matt Fleming 提交于
      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: NMatt 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.orgSigned-off-by: NIngo Molnar <mingo@elte.hu>
      e8c71062
  15. 26 5月, 2011 1 次提交
    • M
      x86, efi: Retain boot service code until after switching to virtual mode · 916f676f
      Matthew Garrett 提交于
      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: NMatthew Garrett <mjg@redhat.com>
      Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: <stable@kernel.org>
      916f676f
  16. 10 5月, 2011 2 次提交
  17. 27 10月, 2010 1 次提交
  18. 04 8月, 2009 1 次提交
    • P
      x86: Make 64-bit efi_ioremap use ioremap on MMIO regions · 6a7bbd57
      Paul Mackerras 提交于
      Booting current 64-bit x86 kernels on the latest Apple MacBook
      (MacBook5,2) via EFI gives the following warning:
      
      [    0.182209] ------------[ cut here ]------------
      [    0.182222] WARNING: at arch/x86/mm/pageattr.c:581 __cpa_process_fault+0x44/0xa0()
      [    0.182227] Hardware name: MacBook5,2
      [    0.182231] CPA: called for zero pte. vaddr = ffff8800ffe00000 cpa->vaddr = ffff8800ffe00000
      [    0.182236] Modules linked in:
      [    0.182242] Pid: 0, comm: swapper Not tainted 2.6.31-rc4 #6
      [    0.182246] Call Trace:
      [    0.182254]  [<ffffffff8102c754>] ? __cpa_process_fault+0x44/0xa0
      [    0.182261]  [<ffffffff81048668>] warn_slowpath_common+0x78/0xd0
      [    0.182266]  [<ffffffff81048744>] warn_slowpath_fmt+0x64/0x70
      [    0.182272]  [<ffffffff8102c7ec>] ? update_page_count+0x3c/0x50
      [    0.182280]  [<ffffffff818d25c5>] ? phys_pmd_init+0x140/0x22e
      [    0.182286]  [<ffffffff8102c754>] __cpa_process_fault+0x44/0xa0
      [    0.182292]  [<ffffffff8102ce60>] __change_page_attr_set_clr+0x5f0/0xb40
      [    0.182301]  [<ffffffff810d1035>] ? vm_unmap_aliases+0x175/0x190
      [    0.182307]  [<ffffffff8102d4ae>] change_page_attr_set_clr+0xfe/0x3d0
      [    0.182314]  [<ffffffff8102dcca>] _set_memory_uc+0x2a/0x30
      [    0.182319]  [<ffffffff8102dd4b>] set_memory_uc+0x7b/0xb0
      [    0.182327]  [<ffffffff818afe31>] efi_enter_virtual_mode+0x2ad/0x2c9
      [    0.182334]  [<ffffffff818a1c66>] start_kernel+0x2db/0x3f4
      [    0.182340]  [<ffffffff818a1289>] x86_64_start_reservations+0x99/0xb9
      [    0.182345]  [<ffffffff818a1389>] x86_64_start_kernel+0xe0/0xf2
      [    0.182357] ---[ end trace 4eaa2a86a8e2da22 ]---
      [    0.182982] init_memory_mapping: 00000000ffffc000-0000000100000000
      [    0.182993]  00ffffc000 - 0100000000 page 4k
      
      This happens because the 64-bit version of efi_ioremap calls
      init_memory_mapping for all addresses, regardless of whether they are
      RAM or MMIO.  The EFI tables on this machine ask for runtime access to
      some MMIO regions:
      
      [    0.000000] EFI: mem195: type=11, attr=0x8000000000000000, range=[0x0000000093400000-0x0000000093401000) (0MB)
      [    0.000000] EFI: mem196: type=11, attr=0x8000000000000000, range=[0x00000000ffc00000-0x00000000ffc40000) (0MB)
      [    0.000000] EFI: mem197: type=11, attr=0x8000000000000000, range=[0x00000000ffc40000-0x00000000ffc80000) (0MB)
      [    0.000000] EFI: mem198: type=11, attr=0x8000000000000000, range=[0x00000000ffc80000-0x00000000ffca4000) (0MB)
      [    0.000000] EFI: mem199: type=11, attr=0x8000000000000000, range=[0x00000000ffca4000-0x00000000ffcb4000) (0MB)
      [    0.000000] EFI: mem200: type=11, attr=0x8000000000000000, range=[0x00000000ffcb4000-0x00000000ffffc000) (3MB)
      [    0.000000] EFI: mem201: type=11, attr=0x8000000000000000, range=[0x00000000ffffc000-0x0000000100000000) (0MB)
      
      This arranges to pass the EFI memory type through to efi_ioremap, and
      makes efi_ioremap use ioremap rather than init_memory_mapping if the
      type is EFI_MEMORY_MAPPED_IO.  With this, the above warning goes away.
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
      Cc: Huang Ying <ying.huang@intel.com>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      6a7bbd57
  19. 05 3月, 2009 1 次提交
  20. 23 1月, 2009 1 次提交
  21. 08 7月, 2008 1 次提交
    • B
      x86: add flags parameter to reserve_bootmem_generic() · 3fd052b1
      Bernhard Walle 提交于
      This patch adds a 'flags' parameter to reserve_bootmem_generic() like it
      already has been added in reserve_bootmem() with commit
      72a7fe39.
      
      It also changes all users to use BOOTMEM_DEFAULT, which doesn't effectively
      change the behaviour. Since the change is x86-specific, I don't think it's
      necessary to add a new API for migration. There are only 4 users of that
      function.
      
      The change is necessary for the next patch, using reserve_bootmem_generic()
      for crashkernel reservation.
      Signed-off-by: NBernhard Walle <bwalle@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3fd052b1
  22. 05 6月, 2008 1 次提交
  23. 25 5月, 2008 1 次提交
  24. 20 4月, 2008 1 次提交
  25. 13 2月, 2008 1 次提交
    • H
      x86: EFI runtime code mapping enhancement · 4de0d4a6
      Huang, Ying 提交于
      This patch enhances EFI runtime code memory mapping as following:
      
      - Move __supported_pte_mask & _PAGE_NX checking before invoking
        runtime_code_page_mkexec(). This makes it possible for compiler to
        eliminate runtime_code_page_mkexec() on machine without NX support.
      
      - Use set_memory_x/nx in early_mapping_set_exec(). This eliminates the
        duplicated implementation.
      
      This patch has been tested on Intel x86_64 platform with EFI64/32
      firmware.
      Signed-off-by: NHuang Ying <ying.huang@intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4de0d4a6
  26. 04 2月, 2008 1 次提交
  27. 02 2月, 2008 1 次提交
  28. 30 1月, 2008 5 次提交