2008-01-30 20:31:19 +08:00
|
|
|
/*
|
|
|
|
* x86_64 specific EFI support functions
|
|
|
|
* Based on Extensible Firmware Interface Specification version 1.0
|
|
|
|
*
|
|
|
|
* Copyright (C) 2005-2008 Intel Co.
|
|
|
|
* Fenghua Yu <fenghua.yu@intel.com>
|
|
|
|
* Bibo Mao <bibo.mao@intel.com>
|
|
|
|
* Chandramouli Narayanan <mouli@linux.intel.com>
|
|
|
|
* Huang Ying <ying.huang@intel.com>
|
|
|
|
*
|
|
|
|
* Code to convert EFI to E820 map has been implemented in elilo bootloader
|
|
|
|
* based on a EFI patch by Edgar Hucek. Based on the E820 map, the page table
|
|
|
|
* is setup appropriately for EFI runtime code.
|
|
|
|
* - mouli 06/14/2007.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
#include <linux/mm.h>
|
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/spinlock.h>
|
|
|
|
#include <linux/bootmem.h>
|
|
|
|
#include <linux/ioport.h>
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/efi.h>
|
|
|
|
#include <linux/uaccess.h>
|
|
|
|
#include <linux/io.h>
|
|
|
|
#include <linux/reboot.h>
|
|
|
|
|
|
|
|
#include <asm/setup.h>
|
|
|
|
#include <asm/page.h>
|
|
|
|
#include <asm/e820.h>
|
|
|
|
#include <asm/pgtable.h>
|
|
|
|
#include <asm/tlbflush.h>
|
|
|
|
#include <asm/proto.h>
|
|
|
|
#include <asm/efi.h>
|
2008-02-13 17:22:41 +08:00
|
|
|
#include <asm/cacheflush.h>
|
2009-01-23 10:03:29 +08:00
|
|
|
#include <asm/fixmap.h>
|
2008-01-30 20:31:19 +08:00
|
|
|
|
|
|
|
static pgd_t save_pgd __initdata;
|
|
|
|
static unsigned long efi_flags __initdata;
|
|
|
|
|
2011-05-06 03:19:43 +08:00
|
|
|
static void __init early_code_mapping_set_exec(int executable)
|
2008-01-30 20:31:19 +08:00
|
|
|
{
|
|
|
|
efi_memory_desc_t *md;
|
|
|
|
void *p;
|
|
|
|
|
2008-01-30 20:33:55 +08:00
|
|
|
if (!(__supported_pte_mask & _PAGE_NX))
|
|
|
|
return;
|
|
|
|
|
x86, efi: Retain boot service code until after switching to virtual mode
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: Matthew Garrett <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <stable@kernel.org>
2011-05-25 21:53:13 +08:00
|
|
|
/* Make EFI service code area executable */
|
2008-01-30 20:31:19 +08:00
|
|
|
for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
|
|
|
|
md = p;
|
x86, efi: Retain boot service code until after switching to virtual mode
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: Matthew Garrett <mjg@redhat.com>
Link: http://lkml.kernel.org/r/1306331593-28715-1-git-send-email-mjg@redhat.com
Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
Cc: Tony Luck <tony.luck@intel.com>
Cc: <stable@kernel.org>
2011-05-25 21:53:13 +08:00
|
|
|
if (md->type == EFI_RUNTIME_SERVICES_CODE ||
|
|
|
|
md->type == EFI_BOOT_SERVICES_CODE)
|
2011-05-06 03:19:43 +08:00
|
|
|
efi_set_executable(md, executable);
|
2008-01-30 20:31:19 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init efi_call_phys_prelog(void)
|
|
|
|
{
|
|
|
|
unsigned long vaddress;
|
|
|
|
|
2011-05-06 03:19:43 +08:00
|
|
|
early_code_mapping_set_exec(1);
|
2008-02-13 17:22:41 +08:00
|
|
|
local_irq_save(efi_flags);
|
2008-01-30 20:31:19 +08:00
|
|
|
vaddress = (unsigned long)__va(0x0UL);
|
2008-01-30 20:32:44 +08:00
|
|
|
save_pgd = *pgd_offset_k(0x0UL);
|
2008-01-30 20:31:19 +08:00
|
|
|
set_pgd(pgd_offset_k(0x0UL), *pgd_offset_k(vaddress));
|
|
|
|
__flush_tlb_all();
|
|
|
|
}
|
|
|
|
|
|
|
|
void __init efi_call_phys_epilog(void)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* After the lock is released, the original page table is restored.
|
|
|
|
*/
|
|
|
|
set_pgd(pgd_offset_k(0x0UL), save_pgd);
|
|
|
|
__flush_tlb_all();
|
|
|
|
local_irq_restore(efi_flags);
|
2011-05-06 03:19:43 +08:00
|
|
|
early_code_mapping_set_exec(0);
|
2008-01-30 20:31:19 +08:00
|
|
|
}
|
|
|
|
|
x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
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: Paul Mackerras <paulus@samba.org>
LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-08-03 20:38:10 +08:00
|
|
|
void __iomem *__init efi_ioremap(unsigned long phys_addr, unsigned long size,
|
|
|
|
u32 type)
|
2008-01-30 20:31:19 +08:00
|
|
|
{
|
2009-03-04 10:58:33 +08:00
|
|
|
unsigned long last_map_pfn;
|
2008-01-30 20:31:19 +08:00
|
|
|
|
x86: Make 64-bit efi_ioremap use ioremap on MMIO regions
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: Paul Mackerras <paulus@samba.org>
LKML-Reference: <19062.55858.533494.471153@cargo.ozlabs.ibm.com>
Cc: Huang Ying <ying.huang@intel.com>
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
2009-08-03 20:38:10 +08:00
|
|
|
if (type == EFI_MEMORY_MAPPED_IO)
|
|
|
|
return ioremap(phys_addr, size);
|
|
|
|
|
2009-03-04 10:58:33 +08:00
|
|
|
last_map_pfn = init_memory_mapping(phys_addr, phys_addr + size);
|
2011-05-06 03:19:46 +08:00
|
|
|
if ((last_map_pfn << PAGE_SHIFT) < phys_addr + size) {
|
|
|
|
unsigned long top = last_map_pfn << PAGE_SHIFT;
|
|
|
|
efi_ioremap(top, size - (top - phys_addr), type);
|
|
|
|
}
|
2008-01-30 20:31:19 +08:00
|
|
|
|
2009-03-04 10:58:33 +08:00
|
|
|
return (void __iomem *)__va(phys_addr);
|
2008-01-30 20:31:19 +08:00
|
|
|
}
|