Merge branch 'x86/urgent' into x86/asm to pick up dependent fixes (95a8e746) · Commits · e / devices / android_kernel_fairphone_FP5

Documentation/x86/protection-keys.txt

0 → 100644

+27 −0

Original line number	Original line	Diff line number	Diff line
			Memory Protection Keys for Userspace (PKU aka PKEYs) is a CPU feature
			which will be found on future Intel CPUs.

			Memory Protection Keys provides a mechanism for enforcing page-based
			protections, but without requiring modification of the page tables
			when an application changes protection domains. It works by
			dedicating 4 previously ignored bits in each page table entry to a
			"protection key", giving 16 possible keys.

			There is also a new user-accessible register (PKRU) with two separate
			bits (Access Disable and Write Disable) for each key. Being a CPU
			register, PKRU is inherently thread-local, potentially giving each
			thread a different set of protections from every other thread.

			There are two new instructions (RDPKRU/WRPKRU) for reading and writing
			to the new register. The feature is only available in 64-bit mode,
			even though there is theoretically space in the PAE PTEs. These
			permissions are enforced on data access only and have no effect on
			instruction fetches.

			=========================== Config Option ===========================

			This config option adds approximately 1.5kb of text. and 50 bytes of
			data to the executable. A workload which does large O_DIRECT reads
			of holes in XFS files was run to exercise get_user_pages_fast(). No
			performance delta was observed with the config option
			enabled or disabled.

Documentation/x86/topology.txt

0 → 100644

+208 −0

Original line number	Original line	Diff line number	Diff line
			x86 Topology
			============

			This documents and clarifies the main aspects of x86 topology modelling and
			representation in the kernel. Update/change when doing changes to the
			respective code.

			The architecture-agnostic topology definitions are in
			Documentation/cputopology.txt. This file holds x86-specific
			differences/specialities which must not necessarily apply to the generic
			definitions. Thus, the way to read up on Linux topology on x86 is to start
			with the generic one and look at this one in parallel for the x86 specifics.

			Needless to say, code should use the generic functions - this file is only
			here to document the inner workings of x86 topology.

			Started by Thomas Gleixner <tglx@linutronix.de> and Borislav Petkov <bp@alien8.de>.

			The main aim of the topology facilities is to present adequate interfaces to
			code which needs to know/query/use the structure of the running system wrt
			threads, cores, packages, etc.

			The kernel does not care about the concept of physical sockets because a
			socket has no relevance to software. It's an electromechanical component. In
			the past a socket always contained a single package (see below), but with the
			advent of Multi Chip Modules (MCM) a socket can hold more than one package. So
			there might be still references to sockets in the code, but they are of
			historical nature and should be cleaned up.

			The topology of a system is described in the units of:

			- packages
			- cores
			- threads

			* Package:

			Packages contain a number of cores plus shared resources, e.g. DRAM
			controller, shared caches etc.

			AMD nomenclature for package is 'Node'.

			Package-related topology information in the kernel:

			- cpuinfo_x86.x86_max_cores:

			The number of cores in a package. This information is retrieved via CPUID.

			- cpuinfo_x86.phys_proc_id:

			The physical ID of the package. This information is retrieved via CPUID
			and deduced from the APIC IDs of the cores in the package.

			- cpuinfo_x86.logical_id:

			The logical ID of the package. As we do not trust BIOSes to enumerate the
			packages in a consistent way, we introduced the concept of logical package
			ID so we can sanely calculate the number of maximum possible packages in
			the system and have the packages enumerated linearly.

			- topology_max_packages():

			The maximum possible number of packages in the system. Helpful for per
			package facilities to preallocate per package information.


			* Cores:

			A core consists of 1 or more threads. It does not matter whether the threads
			are SMT- or CMT-type threads.

			AMDs nomenclature for a CMT core is "Compute Unit". The kernel always uses
			"core".

			Core-related topology information in the kernel:

			- smp_num_siblings:

			The number of threads in a core. The number of threads in a package can be
			calculated by:

			threads_per_package = cpuinfo_x86.x86_max_cores * smp_num_siblings


			* Threads:

			A thread is a single scheduling unit. It's the equivalent to a logical Linux
			CPU.

			AMDs nomenclature for CMT threads is "Compute Unit Core". The kernel always
			uses "thread".

			Thread-related topology information in the kernel:

			- topology_core_cpumask():

			The cpumask contains all online threads in the package to which a thread
			belongs.

			The number of online threads is also printed in /proc/cpuinfo "siblings."

			- topology_sibling_mask():

			The cpumask contains all online threads in the core to which a thread
			belongs.

			- topology_logical_package_id():

			The logical package ID to which a thread belongs.

			- topology_physical_package_id():

			The physical package ID to which a thread belongs.

			- topology_core_id();

			The ID of the core to which a thread belongs. It is also printed in /proc/cpuinfo
			"core_id."



			System topology examples

			Note:

			The alternative Linux CPU enumeration depends on how the BIOS enumerates the
			threads. Many BIOSes enumerate all threads 0 first and then all threads 1.
			That has the "advantage" that the logical Linux CPU numbers of threads 0 stay
			the same whether threads are enabled or not. That's merely an implementation
			detail and has no practical impact.

			1) Single Package, Single Core

			[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0

			2) Single Package, Dual Core

			a) One thread per core

			[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
			-> [core 1] -> [thread 0] -> Linux CPU 1

			b) Two threads per core

			[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
			-> [thread 1] -> Linux CPU 1
			-> [core 1] -> [thread 0] -> Linux CPU 2
			-> [thread 1] -> Linux CPU 3

			Alternative enumeration:

			[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
			-> [thread 1] -> Linux CPU 2
			-> [core 1] -> [thread 0] -> Linux CPU 1
			-> [thread 1] -> Linux CPU 3

			AMD nomenclature for CMT systems:

			[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
			-> [Compute Unit Core 1] -> Linux CPU 1
			-> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
			-> [Compute Unit Core 1] -> Linux CPU 3

			4) Dual Package, Dual Core

			a) One thread per core

			[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
			-> [core 1] -> [thread 0] -> Linux CPU 1

			[package 1] -> [core 0] -> [thread 0] -> Linux CPU 2
			-> [core 1] -> [thread 0] -> Linux CPU 3

			b) Two threads per core

			[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
			-> [thread 1] -> Linux CPU 1
			-> [core 1] -> [thread 0] -> Linux CPU 2
			-> [thread 1] -> Linux CPU 3

			[package 1] -> [core 0] -> [thread 0] -> Linux CPU 4
			-> [thread 1] -> Linux CPU 5
			-> [core 1] -> [thread 0] -> Linux CPU 6
			-> [thread 1] -> Linux CPU 7

			Alternative enumeration:

			[package 0] -> [core 0] -> [thread 0] -> Linux CPU 0
			-> [thread 1] -> Linux CPU 4
			-> [core 1] -> [thread 0] -> Linux CPU 1
			-> [thread 1] -> Linux CPU 5

			[package 1] -> [core 0] -> [thread 0] -> Linux CPU 2
			-> [thread 1] -> Linux CPU 6
			-> [core 1] -> [thread 0] -> Linux CPU 3
			-> [thread 1] -> Linux CPU 7

			AMD nomenclature for CMT systems:

			[node 0] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 0
			-> [Compute Unit Core 1] -> Linux CPU 1
			-> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 2
			-> [Compute Unit Core 1] -> Linux CPU 3

			[node 1] -> [Compute Unit 0] -> [Compute Unit Core 0] -> Linux CPU 4
			-> [Compute Unit Core 1] -> Linux CPU 5
			-> [Compute Unit 1] -> [Compute Unit Core 0] -> Linux CPU 6
			-> [Compute Unit Core 1] -> Linux CPU 7

arch/x86/boot/compressed/Makefile

+13 −1

Original line number	Original line	Diff line number	Diff line
	@@ -26,7 +26,7 @@ targets := vmlinux vmlinux.bin vmlinux.bin.gz vmlinux.bin.bz2 vmlinux.bin.lzma \
	vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4		vmlinux.bin.xz vmlinux.bin.lzo vmlinux.bin.lz4

	KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2		KBUILD_CFLAGS := -m$(BITS) -D__KERNEL__ $(LINUX_INCLUDE) -O2
	KBUILD_CFLAGS += -fno-strict-aliasing -fPIC		KBUILD_CFLAGS += -fno-strict-aliasing $(call cc-option, -fPIE, -fPIC)
	KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING		KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
	cflags-$(CONFIG_X86_32) := -march=i386		cflags-$(CONFIG_X86_32) := -march=i386
	cflags-$(CONFIG_X86_64) := -mcmodel=small		cflags-$(CONFIG_X86_64) := -mcmodel=small
	@@ -40,6 +40,18 @@ GCOV_PROFILE := n
	UBSAN_SANITIZE :=n		UBSAN_SANITIZE :=n

	LDFLAGS := -m elf_$(UTS_MACHINE)		LDFLAGS := -m elf_$(UTS_MACHINE)
			ifeq ($(CONFIG_RELOCATABLE),y)
			# If kernel is relocatable, build compressed kernel as PIE.
			ifeq ($(CONFIG_X86_32),y)
			LDFLAGS += $(call ld-option, -pie) $(call ld-option, --no-dynamic-linker)
			else
			# To build 64-bit compressed kernel as PIE, we disable relocation
			# overflow check to avoid relocation overflow error with a new linker
			# command-line option, -z noreloc-overflow.
			LDFLAGS += $(shell $(LD) --help 2>&1 \| grep -q "\-z noreloc-overflow" \
			&& echo "-z noreloc-overflow -pie --no-dynamic-linker")
			endif
			endif
	LDFLAGS_vmlinux := -T		LDFLAGS_vmlinux := -T

	hostprogs-y := mkpiggy		hostprogs-y := mkpiggy

arch/x86/boot/compressed/head_32.S

+28 −0

Original line number	Original line	Diff line number	Diff line
	@@ -31,6 +31,34 @@
	#include <asm/asm-offsets.h>		#include <asm/asm-offsets.h>
	#include <asm/bootparam.h>		#include <asm/bootparam.h>

			/*
			* The 32-bit x86 assembler in binutils 2.26 will generate R_386_GOT32X
			* relocation to get the symbol address in PIC. When the compressed x86
			* kernel isn't built as PIC, the linker optimizes R_386_GOT32X
			* relocations to their fixed symbol addresses. However, when the
			* compressed x86 kernel is loaded at a different address, it leads
			* to the following load failure:
			*
			* Failed to allocate space for phdrs
			*
			* during the decompression stage.
			*
			* If the compressed x86 kernel is relocatable at run-time, it should be
			* compiled with -fPIE, instead of -fPIC, if possible and should be built as
			* Position Independent Executable (PIE) so that linker won't optimize
			* R_386_GOT32X relocation to its fixed symbol address. Older
			* linkers generate R_386_32 relocations against locally defined symbols,
			* _bss, _ebss, _got and _egot, in PIE. It isn't wrong, just less
			* optimal than R_386_RELATIVE. But the x86 kernel fails to properly handle
			* R_386_32 relocations when relocating the kernel. To generate
			* R_386_RELATIVE relocations, we mark _bss, _ebss, _got and _egot as
			* hidden:
			*/
			.hidden _bss
			.hidden _ebss
			.hidden _got
			.hidden _egot

	__HEAD		__HEAD
	ENTRY(startup_32)		ENTRY(startup_32)
	#ifdef CONFIG_EFI_STUB		#ifdef CONFIG_EFI_STUB

arch/x86/boot/compressed/head_64.S

+8 −0

Original line number	Original line	Diff line number	Diff line
	@@ -33,6 +33,14 @@
	#include <asm/asm-offsets.h>		#include <asm/asm-offsets.h>
	#include <asm/bootparam.h>		#include <asm/bootparam.h>

			/*
			* Locally defined symbols should be marked hidden:
			*/
			.hidden _bss
			.hidden _ebss
			.hidden _got
			.hidden _egot

	__HEAD		__HEAD
	.code32		.code32
	ENTRY(startup_32)		ENTRY(startup_32)