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

x86: Store a per-cpu shadow copy of CR4

2015-06-28T17:39:27+00:00

[ Upstream commit 1e02ce4cccdcb9688386e5b8d2c9fa4660b45389 ]

Context switches and TLB flushes can change individual bits of CR4.
CR4 reads take several cycles, so store a shadow copy of CR4 in a
per-cpu variable.

To avoid wasting a cache line, I added the CR4 shadow to
cpu_tlbstate, which is already touched in switch_mm.  The heaviest
users of the cr4 shadow will be switch_mm and __switch_to_xtra, and
__switch_to_xtra is called shortly after switch_mm during context
switch, so the cacheline is likely to be hot.

Signed-off-by: Andy Lutomirski 
Reviewed-by: Thomas Gleixner 
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Kees Cook 
Cc: Andrea Arcangeli 
Cc: Vince Weaver 
Cc: "hillf.zj" 
Cc: Valdis Kletnieks 
Cc: Paul Mackerras 
Cc: Arnaldo Carvalho de Melo 
Cc: Linus Torvalds 
Link: http://lkml.kernel.org/r/3a54dd3353fffbf84804398e00dfdc5b7c1afd7d.1414190806.git.luto@amacapital.net
Signed-off-by: Ingo Molnar 
Signed-off-by: Sasha Levin

x86, cma: Reserve DMA contiguous area after initmem_init()

2014-10-28T06:36:50+00:00

Fengguang Wu reported a boot crash on the x86 platform
via the 0-day Linux Kernel Performance Test:

  cma: dma_contiguous_reserve: reserving 31 MiB for global area
  BUG: Int 6: CR2   (null)
  [<41850786>] dump_stack+0x16/0x18
  [<41d2b1db>] early_idt_handler+0x6b/0x6b
  [<41072227>] ? __phys_addr+0x2e/0xca
  [<41d4ee4d>] cma_declare_contiguous+0x3c/0x2d7
  [<41d6d359>] dma_contiguous_reserve_area+0x27/0x47
  [<41d6d4d1>] dma_contiguous_reserve+0x158/0x163
  [<41d33e0f>] setup_arch+0x79b/0xc68
  [<41d2b7cf>] start_kernel+0x9c/0x456
  [<41d2b2ca>] i386_start_kernel+0x79/0x7d

(See details at: https://lkml.org/lkml/2014/10/8/708)

It is because dma_contiguous_reserve() is called before
initmem_init() in x86, the variable high_memory is not
initialized but accessed by __pa(high_memory) in
dma_contiguous_reserve().

This patch moves dma_contiguous_reserve() after initmem_init()
so that high_memory is initialized before accessed.

Reported-by: Fengguang Wu 
Signed-off-by: Weijie Yang 
Acked-by: Andrew Morton 
Acked-by: Marek Szyprowski 
Acked-by: Michal Nazarewicz 
Cc: iamjoonsoo.kim@lge.com
Cc: 'Linux-MM' 
Cc: 'Weijie Yang' 
Link: http://lkml.kernel.org/r/000101cfef69%2431e528a0%2495af79e0%24%25yang@samsung.com
Signed-off-by: Ingo Molnar

x86: Quark: Comment setup_arch() to document TLB/PGE bug

2014-10-08T08:07:46+00:00

Quark SoC X1000 advertises Page Global Enable for it's
Translation Lookaside Buffer via cpuid. The silicon does not
in fact support PGE and hence will not flush the TLB when CR4.PGE
is rewritten. The Quark documentation makes clear the necessity to
instead rewrite CR3 in order to flush any TLB entries, irrespective
of the state of CR4.PGE or an individual PTE.PGE

See Intel Quark Core DevMan_001.pdf section 6.4.11

In setup.c setup_arch() the code will load_cr3() and then do a
__flush_tlb_all().

On Quark the entire TLB will be flushed at the load_cr3().
The __flush_tlb_all() have no effect and can be safely ignored.

Later on in the boot process we switch off the flag for cpu_has_pge()
which means that subsequent calls to __flush_tlb_all() will
call __flush_tlb() not __flush_tlb_global() flushing the TLB in the
correct way via load_cr3() not CR4.PGE rewrite

This patch documents the behaviour of flushing the TLB for Quark in
setup_arch()

Comment text suggested by Thomas Gleixner

Signed-off-by: Bryan O'Donoghue 
Cc: davej@redhat.com
Cc: hmh@hmh.eng.br
Link: http://lkml.kernel.org/r/1412641189-12415-2-git-send-email-pure.logic@nexus-software.ie
Signed-off-by: Thomas Gleixner

arch/x86: Replace plain strings with constants

2014-07-18T20:23:59+00:00

We've got constants, so let's use them instead of hard-coded values.

Signed-off-by: Daniel Kiper 
Signed-off-by: Matt Fleming

cma: add placement specifier for "cma=" kernel parameter

2014-06-04T23:53:57+00:00

Currently, "cma=" kernel parameter is used to specify the size of CMA,
but we can't specify where it is located.  We want to locate CMA below
4GB for devices only supporting 32-bit addressing on 64-bit systems
without iommu.

This enables to specify the placement of CMA by extending "cma=" kernel
parameter.

Examples:
 1. locate 64MB CMA below 4GB by "cma=64M@0-4G"
 2. locate 64MB CMA exact at 512MB by "cma=64M@512M"

Note that the DMA contiguous memory allocator on x86 assumes that
page_address() works for the pages to allocate.  So this change requires
to limit end address of contiguous memory area upto max_pfn_mapped to
prevent from locating it on highmem area by the argument of
dma_contiguous_reserve().

Signed-off-by: Akinobu Mita 
Cc: Marek Szyprowski 
Cc: Konrad Rzeszutek Wilk 
Cc: David Woodhouse 
Cc: Don Dutile 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Andi Kleen 
Cc: Yinghai Lu 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

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

2014-04-02T20:15:58+00:00

Pull x86 old platform removal from Peter Anvin:
 "This patchset removes support for several completely obsolete
  platforms, where the maintainers either have completely vanished or
  acked the removal.  For some of them it is questionable if there even
  exists functional specimens of the hardware"

Geert Uytterhoeven apparently thought this was a April Fool's pull request ;)

* 'x86-nuke-platforms-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86, platforms: Remove NUMAQ
  x86, platforms: Remove SGI Visual Workstation
  x86, apic: Remove support for IBM Summit/EXA chipset
  x86, apic: Remove support for ia32-based Unisys ES7000

Merge remote-tracking branch 'tip/x86/urgent' into efi-for-mingo

2014-03-05T17:31:41+00:00

Conflicts:
	arch/x86/include/asm/efi.h

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

efi: Move facility flags to struct efi

2014-03-04T16:16:16+00:00

As we grow support for more EFI architectures they're going to want the
ability to query which EFI features are available on the running system.
Instead of storing this information in an architecture-specific place,
stick it in the global 'struct efi', which is already the central
location for EFI state.

While we're at it, let's change the return value of efi_enabled() to be
bool and replace all references to 'facility' with 'feature', which is
the usual word used to describe the attributes of the running system.

Signed-off-by: Matt Fleming

x86, platforms: Remove SGI Visual Workstation

2014-02-27T16:07:39+00:00

The SGI Visual Workstation seems to be dead; remove support so we
don't have to continue maintaining it.

Cc: Andrey Panin 
Cc: Michael Reed 
Link: http://lkml.kernel.org/r/530CFD6C.7040705@zytor.com
Signed-off-by: H. Peter Anvin