- 03 5月, 2014 1 次提交
-
-
由 Dave Young 提交于
earlyprintk=efi,keep will cause kernel hangs while freeing initmem like below: VFS: Mounted root (ext4 filesystem) readonly on device 254:2. devtmpfs: mounted Freeing unused kernel memory: 880K (ffffffff817d4000 - ffffffff818b0000) It is caused by efi earlyprintk use __init function which will be freed later. Such as early_efi_write is marked as __init, also it will use early_ioremap which is init function as well. To fix this issue, I added early initcall early_efi_map_fb which maps the whole efi fb for later use. OTOH, adding a wrapper function early_efi_map which calls early_ioremap before ioremap is available. With this patch applied efi boot ok with earlyprintk=efi,keep console=efi Signed-off-by: NDave Young <dyoung@redhat.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
- 11 4月, 2014 3 次提交
-
-
由 Matt Fleming 提交于
We're currently passing the file handle for the root file system to efi_file_read() and efi_file_close(), instead of the file handle for the file we wish to read/close. While this has worked up until now, it seems that it has only been by pure luck. Olivier explains, "The issue is the UEFI Fat driver might return the same function for 'fh->read()' and 'h->read()'. While in our case it does not work with a different implementation of EFI_SIMPLE_FILE_SYSTEM_PROTOCOL. In our case, we return a different pointer when reading a directory and reading a file." Fixing this actually clears up the two functions because we can drop one of the arguments, and instead only pass a file 'handle' argument. Reported-by: NOlivier Martin <olivier.martin@arm.com> Reviewed-by: NOlivier Martin <olivier.martin@arm.com> Reviewed-by: NMark Rutland <mark.rutland@arm.com> Cc: Leif Lindholm <leif.lindholm@linaro.org> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
code32_start should point at the start of the protected mode code, and *not* at the beginning of the bzImage. This is much easier to do in assembly so document that callers of make_boot_params() need to fill out code32_start. The fallout from this bug is that we would end up relocating the image but copying the image at some offset, resulting in what appeared to be memory corruption. Reported-by: NThomas Bächler <thomas@archlinux.org> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
commit 54b52d87 ("x86/efi: Build our own EFI services pointer table") introduced a regression because the 64-bit file_size() implementation passed a pointer to a 32-bit data object, instead of a pointer to a 64-bit object. Because the firmware treats the object as 64-bits regardless it was reading random values from the stack for the upper 32-bits. This resulted in people being unable to boot their machines, after seeing the following error messages, Failed to get file info size Failed to alloc highmem for files Reported-by: NDzmitry Sledneu <dzmitry.sledneu@gmail.com> Reported-by: NKoen Kooi <koen@dominion.thruhere.net> Tested-by: NKoen Kooi <koen@dominion.thruhere.net> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
- 27 3月, 2014 1 次提交
-
-
由 Matt Fleming 提交于
The ARM EFI boot stub doesn't need to care about the efi_early infrastructure that x86 requires in order to do mixed mode thunking. So wrap everything up in an efi_call_early() macro. This allows x86 to do the necessary indirection jumps to call whatever firmware interface is necessary (native or mixed mode), but also allows the ARM folks to mask the fact that they don't support relocation in the boot stub and need to pass 'sys_table_arg' to every function. [ hpa: there are no object code changes from this patch ] Signed-off-by: NMatt Fleming <matt.fleming@intel.com> Link: http://lkml.kernel.org/r/20140326091011.GB2958@console-pimps.org Cc: Roy Franz <roy.franz@linaro.org> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
- 18 3月, 2014 3 次提交
-
-
由 Matt Fleming 提交于
In the thunk patches the 'attr' argument was dropped to query_variable_info(). Restore it otherwise the firmware will return EFI_INVALID_PARAMETER. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
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: NDan 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: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
I was triggering a #GP(0) from userland when running with CONFIG_EFI_MIXED and CONFIG_IA32_EMULATION, from what looked like register corruption. Turns out that the mixed mode code was trashing the contents of %ds, %es and %ss in __efi64_thunk(). Save and restore the contents of these segment registers across the call to __efi64_thunk() so that we don't corrupt the CPU context. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
- 06 3月, 2014 3 次提交
-
-
由 Matt Fleming 提交于
-
由 Matt Fleming 提交于
Conflicts: arch/x86/kernel/setup.c arch/x86/platform/efi/efi.c arch/x86/platform/efi/efi_64.c
-
由 Matt Fleming 提交于
Conflicts: arch/x86/include/asm/efi.h
-
- 05 3月, 2014 29 次提交
-
-
由 Matt Fleming 提交于
The kbuild test robot reported the following errors, introduced with commit 54b52d87 ("x86/efi: Build our own EFI services pointer table"), arch/x86/boot/compressed/head_32.o: In function `efi32_config': >> (.data+0x58): undefined reference to `efi_call_phys' arch/x86/boot/compressed/head_64.o: In function `efi64_config': >> (.data+0x90): undefined reference to `efi_call6' Wrap the efi*_config structures in #ifdef CONFIG_EFI_STUB so that we don't make references to EFI functions if they're not compiled in. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
The kbuild test robot reported the following errors that were introduced with commit 993c30a0 ("x86, tools: Consolidate #ifdef code"), arch/x86/boot/tools/build.c: In function 'update_pecoff_setup_and_reloc': >> arch/x86/boot/tools/build.c:252:1: error: parameter name omitted static inline void update_pecoff_setup_and_reloc(unsigned int) {} ^ arch/x86/boot/tools/build.c: In function 'update_pecoff_text': >> arch/x86/boot/tools/build.c:253:1: error: parameter name omitted static inline void update_pecoff_text(unsigned int, unsigned int) {} ^ >> arch/x86/boot/tools/build.c:253:1: error: parameter name omitted arch/x86/boot/tools/build.c: In function 'main': >> arch/x86/boot/tools/build.c:372:2: warning: implicit declaration of function 'efi_stub_entry_update' [-Wimplicit-function-declaration] efi_stub_entry_update(); ^ Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Jiri Olsa 提交于
The trace_do_page_fault function trigger tracepoint and then handles the actual page fault. This could lead to error if the tracepoint caused page fault. The original cr2 value gets lost and the original page fault handler kills current process with SIGSEGV. This happens if you record page faults with callchain data, the user part of it will cause tracepoint handler to page fault: # perf record -g -e exceptions:page_fault_user ls Fixing this by saving the original cr2 value and using it after tracepoint handler is done. v2: Moving the cr2 read before exception_enter, because it could trigger tracepoint as well. Reported-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net> Reported-by: NVince Weaver <vincent.weaver@maine.edu> Tested-by: NVince Weaver <vincent.weaver@maine.edu> Acked-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Paul Mackerras <paulus@samba.org> Cc: Seiji Aguchi <seiji.aguchi@hds.com> Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com> Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1402211701380.6395@vincent-weaver-1.um.maine.edu Link: http://lkml.kernel.org/r/20140228160526.GD1133@krava.brq.redhat.com
-
由 H. Peter Anvin 提交于
* Disable the new EFI 1:1 virtual mapping for SGI UV because using it causes a crash during boot - Borislav Petkov Signed-off-by: NH. Peter Anvin <hpa@linux.intel.com>
-
由 Borislav Petkov 提交于
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: NRuss Anderson <rja@sgi.com> Cc: Alex Thorlton <athorlton@sgi.com Signed-off-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Some firmware appears to enable interrupts during boot service calls, even if we've explicitly disabled them prior to the call. This is actually allowed per the UEFI spec because boottime services expect to be called with interrupts enabled. So that's fine, we just need to ensure that we disable them again in efi_enter32() before switching to a 64-bit GDT, otherwise an interrupt may fire causing a 32-bit IRQ handler to run after we've left compatibility mode. Despite efi_enter32() being called both for boottime and runtime services, this really only affects boottime because the runtime services callchain is executed with interrupts disabled. See efi_thunk(). Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Some EFI firmware makes use of the FPU during boottime services and clearing X86_CR4_OSFXSR by overwriting %cr4 causes the firmware to crash. Add the PAE bit explicitly instead of trashing the existing contents, leaving the rest of the bits as the firmware set them. Cc: H. Peter Anvin <hpa@zytor.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
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_EFI_HANDOVER_32 and XLF_EFI_HANDOVER_64 when CONFIG_EFI_MIXED=y. 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 otherwise. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
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: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
The EFI handover code only works if the "bitness" of the firmware and the kernel match, i.e. 64-bit firmware and 64-bit kernel - it is not possible to mix the two. This goes against the tradition that a 32-bit kernel can be loaded on a 64-bit BIOS platform without having to do anything special in the boot loader. Linux distributions, for one thing, regularly run only 32-bit kernels on their live media. Despite having only one 'handover_offset' field in the kernel header, EFI boot loaders use two separate entry points to enter the kernel based on the architecture the boot loader was compiled for, (1) 32-bit loader: handover_offset (2) 64-bit loader: handover_offset + 512 Since we already have two entry points, we can leverage them to infer the bitness of the firmware we're running on, without requiring any boot loader modifications, by making (1) and (2) valid entry points for both CONFIG_X86_32 and CONFIG_X86_64 kernels. To be clear, a 32-bit boot loader will always use (1) and a 64-bit boot loader will always use (2). It's just that, if a single kernel image supports (1) and (2) that image can be used with both 32-bit and 64-bit boot loaders, and hence both 32-bit and 64-bit EFI. (1) and (2) must be 512 bytes apart at all times, but that is already part of the boot ABI and we could never change that delta without breaking existing boot loaders anyhow. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Make the decision which code path to take at runtime based on efi_early->is64. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Implement the transition code to go from IA32e mode to protected mode in the EFI boot stub. This is required to use 32-bit EFI services from a 64-bit kernel. Since EFI boot stub is executed in an identity-mapped region, there's not much we need to do before invoking the 32-bit EFI boot services. However, we do reload the firmware's global descriptor table (efi32_boot_gdt) in case things like timer events are still running in the firmware. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
It's not possible to dereference the EFI System table directly when booting a 64-bit kernel on a 32-bit EFI firmware because the size of pointers don't match. In preparation for supporting the above use case, build a list of function pointers on boot so that callers don't have to worry about converting pointer sizes through multiple levels of indirection. Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
The traditional approach of using machine-specific types such as 'unsigned long' does not allow the kernel to interact with firmware running in a different CPU mode, e.g. 64-bit kernel with 32-bit EFI. Add distinct EFI structure definitions for both 32-bit and 64-bit so that we can use them in the 32-bit and 64-bit code paths. Acked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
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: NBorislav Petkov <bp@suse.de> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Now that we have EFI-specific page tables we need to lookup the pgd when dumping those page tables, rather than assuming that swapper_pgdir is the current pgdir. Remove the double underscore prefix, which is usually reserved for static functions. Acked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
Instead of littering main() with #ifdef CONFIG_EFI_STUB, move the logic into separate functions that do nothing if the config option isn't set. This makes main() much easier to read. Acked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
handover_offset is now filled out by build.c. Don't set a default value as it will be overwritten anyway. Acked-by: NBorislav Petkov <bp@suse.de> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Daeseok Youn 提交于
Fix following sparse warnings: drivers/firmware/efi/efivars.c:230:66: warning: Using plain integer as NULL pointer drivers/firmware/efi/efi.c:236:27: warning: Using plain integer as NULL pointer Signed-off-by: NDaeseok Youn <daeseok.youn@gmail.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
There's no good reason to keep efi_enabled() under CONFIG_X86 anymore, since nothing about the implementation is specific to x86. Set EFI feature flags in the ia64 boot path instead of claiming to support all features. The old behaviour was actually buggy since efi.memmap never points to a valid memory map, so we shouldn't be claiming to support EFI_MEMMAP. Fortunately, this bug was never triggered because EFI_MEMMAP isn't used outside of arch/x86 currently, but that may not always be the case. Reviewed-and-tested-by: NTony Luck <tony.luck@intel.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Borislav Petkov 提交于
... into a kexec flavor for better code readability and simplicity. The original one was getting ugly with ifdeffery. Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NToshi Kani <toshi.kani@hp.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Borislav Petkov 提交于
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: http://lkml.kernel.org/r/1386806463.1791.295.camel@misato.fc.hp.com 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: NToshi Kani <toshi.kani@hp.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NToshi Kani <toshi.kani@hp.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Borislav Petkov 提交于
We will use it in efi so expose it. Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NToshi Kani <toshi.kani@hp.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Borislav Petkov 提交于
This is very useful for debugging issues with the recently added pagetable switching code for EFI virtual mode. Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NToshi Kani <toshi.kani@hp.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Borislav Petkov 提交于
With reusing the ->trampoline_pgd page table for mapping EFI regions in order to use them after having switched to EFI virtual mode, it is very useful to be able to dump aforementioned page table in dmesg. This adds that functionality through the walk_pgd_level() interface which can be called from somewhere else. The original functionality of dumping to debugfs remains untouched. Cc: Arjan van de Ven <arjan@linux.intel.com> Signed-off-by: NBorislav Petkov <bp@suse.de> Tested-by: NToshi Kani <toshi.kani@hp.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Joe Perches 提交于
Coalesce formats and remove spaces before tabs. Move __initdata after the variable declaration. Signed-off-by: NJoe Perches <joe@perches.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Madper Xie 提交于
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: NMadper Xie <cxie@redhat.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Geyslan G. Bem 提交于
This reorganization removes useless 'bytes' prior assignment and uses 'memdup_user' instead 'kmalloc' + 'copy_from_user'. Signed-off-by: NGeyslan G. Bem <geyslan@gmail.com> Signed-off-by: NMatt Fleming <matt.fleming@intel.com>
-
由 Matt Fleming 提交于
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: NMatt Fleming <matt.fleming@intel.com>
-