linux.git/arch/x86/kernel/setup.c, branch v3.14

x86/efi: Quirk out SGI UV

2014-03-04T23:43:33+00:00

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:
  [] init_extra_mapping_uc+0x13/0x15
  [] uv_system_init+0x22b/0x124b
  [] ? clockevents_register_device+0x138/0x13d
  [] ? setup_APIC_timer+0xc5/0xc7
  [] ? clockevent_delta2ns+0xb/0xd
  [] ? setup_boot_APIC_clock+0x4a8/0x4b7
  [] ? printk+0x72/0x74
  [] native_smp_prepare_cpus+0x389/0x3d6
  [] kernel_init_freeable+0xb7/0x1fb
  [] ? rest_init+0x74/0x74
  [] kernel_init+0x9/0xff
  [] ret_from_fork+0x7c/0xb0
  [] ? 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: Russ Anderson 
Cc: Alex Thorlton 
Signed-off-by: Matt Fleming

x86: revert wrong memblock current limit setting

2014-01-28T05:02:38+00:00

Dave reported big numa system booting is broken.

It turns out that commit 5b6e529521d3 ("x86: memblock: set current limit
to max low memory address") sets the limit to low wrongly.

max_low_pfn_mapped is different from max_pfn_mapped.
max_low_pfn_mapped is always under 4G.

That will memblock_alloc_nid all go under 4G.

Revert 5b6e529521d3 to fix a no-boot regression which was triggered by
457ff1de2d24 ("lib/swiotlb.c: use memblock apis for early memory
allocations").

Signed-off-by: Yinghai Lu 
Reported-by: Dave Hansen 
Acked-by: Santosh Shilimkar 
Cc: Russell King 
Cc: Konrad Rzeszutek Wilk 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

x86: memblock: set current limit to max low memory address

2014-01-22T00:19:46+00:00

The memblock current limit value is used to limit early boot memory
allocations below max low memory address by default, as the kernel can
access only to the low memory.

Hence, set memblock current limit value to the max mapped low memory
address instead of max mapped memory address.

Signed-off-by: Santosh Shilimkar 
Cc: Tejun Heo 
Cc: Grygorii Strashko 
Cc: Yinghai Lu 
Cc: "Rafael J. Wysocki" 
Cc: Arnd Bergmann 
Cc: Christoph Lameter 
Cc: Greg Kroah-Hartman 
Cc: H. Peter Anvin 
Cc: Johannes Weiner 
Cc: KAMEZAWA Hiroyuki 
Cc: Konrad Rzeszutek Wilk 
Cc: Michal Hocko 
Cc: Paul Walmsley 
Cc: Pavel Machek 
Cc: Russell King 
Cc: Tony Lindgren 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

Merge branch 'x86-kaslr-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-01-20T22:45:50+00:00

Pull x86 kernel address space randomization support from Peter Anvin:
 "This enables kernel address space randomization for x86"

* 'x86-kaslr-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, kaslr: Clarify RANDOMIZE_BASE_MAX_OFFSET
  x86, kaslr: Remove unused including 
  x86, kaslr: Use char array to gain sizeof sanity
  x86, kaslr: Add a circular multiply for better bit diffusion
  x86, kaslr: Mix entropy sources together as needed
  x86/relocs: Add percpu fixup for GNU ld 2.23
  x86, boot: Rename get_flags() and check_flags() to *_cpuflags()
  x86, kaslr: Raise the maximum virtual address to -1 GiB on x86_64
  x86, kaslr: Report kernel offset on panic
  x86, kaslr: Select random position from e820 maps
  x86, kaslr: Provide randomness functions
  x86, kaslr: Return location from decompress_kernel
  x86, boot: Move CPU flags out of cpucheck
  x86, relocs: Add more per-cpu gold special cases

Merge branch 'x86-microcode-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-01-20T20:07:54+00:00

Pull x86 microcode loader updates from Ingo Molnar:
 "There are two main changes in this tree:

   - AMD microcode early loading fixes
   - some microcode loader source files reorganization"

* 'x86-microcode-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, microcode: Move to a proper location
  x86, microcode, AMD: Fix early ucode loading
  x86, microcode: Share native MSR accessing variants
  x86, ramdisk: Export relocated ramdisk VA

x86, ramdisk: Export relocated ramdisk VA

2014-01-13T18:56:25+00:00

The ramdisk can possibly get relocated if the whole image is not mapped.
And since we're going over it in the microcode loader and fishing out
the relevant microcode patches, we want access it at its new location.
Thus, export it.

Signed-off-by: Borislav Petkov 
Tested-by: Aravind Gopalakrishnan

x86: Reserve setup_data ranges late after parsing memmap cmdline

2013-12-29T13:09:07+00:00

Currently e820_reserve_setup_data() is called before parsing early
params, it works in normal case. But for memmap=exactmap, the final
memory ranges are created after parsing memmap= cmdline params, so the
previous e820_reserve_setup_data() has no effect. For example,
setup_data ranges will still be marked as normal system ram, thus when
later sysfs driver ioremap them kernel will warn about mapping normal
ram.

This patch fix it by moving the e820_reserve_setup_data() callback after
parsing early params so they can be set as reserved ranges and later
ioremap will be fine with it.

Signed-off-by: Dave Young 
Acked-by: Borislav Petkov 
Tested-by: Toshi Kani 
Signed-off-by: Matt Fleming

x86/efi: Pass necessary EFI data for kexec via setup_data

2013-12-29T13:09:05+00:00

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: Dave Young 
Tested-by: Toshi Kani 
Signed-off-by: Matt Fleming

x86, acpi, crash, kdump: do reserve_crashkernel() after SRAT is parsed.

2013-11-13T03:09:08+00:00

Memory reserved for crashkernel could be large.  So we should not allocate
this memory bottom up from the end of kernel image.

When SRAT is parsed, we will be able to know which memory is hotpluggable,
and we can avoid allocating this memory for the kernel.  So reorder
reserve_crashkernel() after SRAT is parsed.

Signed-off-by: Tang Chen 
Signed-off-by: Zhang Yanfei 
Acked-by: Tejun Heo 
Acked-by: Toshi Kani 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Wanpeng Li 
Cc: Thomas Renninger 
Cc: Yinghai Lu 
Cc: Jiang Liu 
Cc: Wen Congyang 
Cc: Lai Jiangshan 
Cc: Yasuaki Ishimatsu 
Cc: Taku Izumi 
Cc: Mel Gorman 
Cc: Michal Nazarewicz 
Cc: Minchan Kim 
Cc: Rik van Riel 
Cc: Johannes Weiner 
Cc: Kamezawa Hiroyuki 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

DMI: Parse memory device (type 17) in SMBIOS

2013-10-23T17:10:12+00:00

This patch adds a new interface to decode memory device (type 17)
to help error reporting on DIMMs.

Original-author: Tony Luck 
Signed-off-by: Chen, Gong 
Acked-by: Naveen N. Rao 
Acked-by: Borislav Petkov 
Reviewed-by: Mauro Carvalho Chehab 
Signed-off-by: Tony Luck