Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit f4d5b8ad authored by Ingo Molnar's avatar Ingo Molnar
Browse files

Merge tag 'efi-urgent' of... 

Merge tag 'efi-urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi

 into efi/urgent

Pull EFI/arm64 fix from Matt Fleming:

" * Fix a boot crash on arm64 caused by a recent commit to mark the EFI
    memory map as 'MEMBLOCK_NOMAP' which causes the regions to be
    omitted from the kernel direct mapping - Ard Biesheuvel "

Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
parents c05c2ec9 7cc8cbcf

Documentation/x86/protection-keys.txt

0 → 100644
+27 −0
Original line number 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 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/events/amd/core.c

+18 −3
Original line number Diff line number Diff line
@@ -369,7 +369,7 @@ static int amd_pmu_cpu_prepare(int cpu) 


	WARN_ON_ONCE(cpuc->amd_nb);



	if (boot_cpu_data.x86_max_cores < 2)

	if (!x86_pmu.amd_nb_constraints)

		return NOTIFY_OK;



	cpuc->amd_nb = amd_alloc_nb(cpu);
@@ -388,7 +388,7 @@ static void amd_pmu_cpu_starting(int cpu) 


	cpuc->perf_ctr_virt_mask = AMD64_EVENTSEL_HOSTONLY;



	if (boot_cpu_data.x86_max_cores < 2)

	if (!x86_pmu.amd_nb_constraints)

		return;



	nb_id = amd_get_nb_id(cpu);
@@ -414,7 +414,7 @@ static void amd_pmu_cpu_dead(int cpu) 
{

	struct cpu_hw_events *cpuhw;



	if (boot_cpu_data.x86_max_cores < 2)

	if (!x86_pmu.amd_nb_constraints)

		return;



	cpuhw = &per_cpu(cpu_hw_events, cpu);
@@ -648,6 +648,8 @@ static __initconst const struct x86_pmu amd_pmu = { 
	.cpu_prepare		= amd_pmu_cpu_prepare,

	.cpu_starting		= amd_pmu_cpu_starting,

	.cpu_dead		= amd_pmu_cpu_dead,



	.amd_nb_constraints	= 1,

};



static int __init amd_core_pmu_init(void)
@@ -674,6 +676,11 @@ static int __init amd_core_pmu_init(void) 
	x86_pmu.eventsel	= MSR_F15H_PERF_CTL;

	x86_pmu.perfctr		= MSR_F15H_PERF_CTR;

	x86_pmu.num_counters	= AMD64_NUM_COUNTERS_CORE;

	/*

	 * AMD Core perfctr has separate MSRs for the NB events, see

	 * the amd/uncore.c driver.

	 */

	x86_pmu.amd_nb_constraints = 0;



	pr_cont("core perfctr, ");

	return 0;
@@ -693,6 +700,14 @@ __init int amd_pmu_init(void) 
	if (ret)

		return ret;



	if (num_possible_cpus() == 1) {

		/*

		 * No point in allocating data structures to serialize

		 * against other CPUs, when there is only the one CPU.

		 */

		x86_pmu.amd_nb_constraints = 0;

	}



	/* Events are common for all AMDs */

	memcpy(hw_cache_event_ids, amd_hw_cache_event_ids,

	       sizeof(hw_cache_event_ids));

arch/x86/events/perf_event.h

+5 −0
Original line number Diff line number Diff line
@@ -607,6 +607,11 @@ struct x86_pmu { 
	 */

	atomic_t	lbr_exclusive[x86_lbr_exclusive_max];



	/*

	 * AMD bits

	 */

	unsigned int	amd_nb_constraints : 1;



	/*

	 * Extra registers for events

	 */

arch/x86/include/asm/msr-index.h

+1 −7
Original line number Diff line number Diff line
@@ -190,6 +190,7 @@ 
#define MSR_PP1_ENERGY_STATUS		0x00000641

#define MSR_PP1_POLICY			0x00000642



/* Config TDP MSRs */

#define MSR_CONFIG_TDP_NOMINAL		0x00000648

#define MSR_CONFIG_TDP_LEVEL_1		0x00000649

#define MSR_CONFIG_TDP_LEVEL_2		0x0000064A
@@ -210,13 +211,6 @@ 
#define MSR_GFX_PERF_LIMIT_REASONS	0x000006B0

#define MSR_RING_PERF_LIMIT_REASONS	0x000006B1



/* Config TDP MSRs */

#define MSR_CONFIG_TDP_NOMINAL		0x00000648

#define MSR_CONFIG_TDP_LEVEL1		0x00000649

#define MSR_CONFIG_TDP_LEVEL2		0x0000064A

#define MSR_CONFIG_TDP_CONTROL		0x0000064B

#define MSR_TURBO_ACTIVATION_RATIO	0x0000064C



/* Hardware P state interface */

#define MSR_PPERF			0x0000064e

#define MSR_PERF_LIMIT_REASONS		0x0000064f