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

Commit 4064e0ea authored by H. Peter Anvin's avatar H. Peter Anvin
Browse files

Merge commit 'f4bcd8cc' into x86/build 



Bring in upstream merge of x86/kaslr for future patches.

Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
parents 9b3965f7 f4bcd8cc

Documentation/ABI/testing/sysfs-firmware-efi

0 → 100644
+20 −0
Original line number Diff line number Diff line 
What:		/sys/firmware/efi/fw_vendor

Date:		December 2013

Contact:	Dave Young <dyoung@redhat.com>

Description:	It shows the physical address of firmware vendor field in the

		EFI system table.

Users:		Kexec



What:		/sys/firmware/efi/runtime

Date:		December 2013

Contact:	Dave Young <dyoung@redhat.com>

Description:	It shows the physical address of runtime service table entry in

		the EFI system table.

Users:		Kexec



What:		/sys/firmware/efi/config_table

Date:		December 2013

Contact:	Dave Young <dyoung@redhat.com>

Description:	It shows the physical address of config table entry in the EFI

		system table.

Users:		Kexec

Documentation/ABI/testing/sysfs-firmware-efi-runtime-map

0 → 100644
+34 −0
Original line number Diff line number Diff line 
What:		/sys/firmware/efi/runtime-map/

Date:		December 2013

Contact:	Dave Young <dyoung@redhat.com>

Description:	Switching efi runtime services to virtual mode requires

		that all efi memory ranges which have the runtime attribute

		bit set to be mapped to virtual addresses.



		The efi runtime services can only be switched to virtual

		mode once without rebooting. The kexec kernel must maintain

		the same physical to virtual address mappings as the first

		kernel. The mappings are exported to sysfs so userspace tools

		can reassemble them and pass them into the kexec kernel.



		/sys/firmware/efi/runtime-map/ is the directory the kernel

		exports that information in.



		subdirectories are named with the number of the memory range:



			/sys/firmware/efi/runtime-map/0

			/sys/firmware/efi/runtime-map/1

			/sys/firmware/efi/runtime-map/2

			/sys/firmware/efi/runtime-map/3

			...



		Each subdirectory contains five files:



		attribute : The attributes of the memory range.

		num_pages : The size of the memory range in pages.

		phys_addr : The physical address of the memory range.

		type      : The type of the memory range.

		virt_addr : The virtual address of the memory range.



		Above values are all hexadecimal numbers with the '0x' prefix.

Users:		Kexec

Documentation/ABI/testing/sysfs-kernel-boot_params

0 → 100644
+38 −0
Original line number Diff line number Diff line 
What:		/sys/kernel/boot_params

Date:		December 2013

Contact:	Dave Young <dyoung@redhat.com>

Description:	The /sys/kernel/boot_params directory contains two

		files: "data" and "version" and one subdirectory "setup_data".

		It is used to export the kernel boot parameters of an x86

		platform to userspace for kexec and debugging purpose.



		If there's no setup_data in boot_params the subdirectory will

		not be created.



		"data" file is the binary representation of struct boot_params.



		"version" file is the string representation of boot

		protocol version.



		"setup_data" subdirectory contains the setup_data data

		structure in boot_params. setup_data is maintained in kernel

		as a link list. In "setup_data" subdirectory there's one

		subdirectory for each link list node named with the number

		of the list nodes. The list node subdirectory contains two

		files "type" and "data". "type" file is the string

		representation of setup_data type. "data" file is the binary

		representation of setup_data payload.



		The whole boot_params directory structure is like below:

		/sys/kernel/boot_params

		|__ data

		|__ setup_data

		|   |__ 0

		|   |   |__ data

		|   |   |__ type

		|   |__ 1

		|       |__ data

		|       |__ type

		|__ version



Users:		Kexec

Documentation/RCU/trace.txt

+13 −9
Original line number Diff line number Diff line
@@ -396,14 +396,14 @@ o Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node 


The output of "cat rcu/rcu_sched/rcu_pending" looks as follows:



  0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903

  1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113

  2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889

  3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469

  4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042

  5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422

  6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699

  7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147

  0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903 ndw=0

  1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113 ndw=0

  2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889 ndw=0

  3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469 ndw=0

  4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042 ndw=0

  5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422 ndw=0

  6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699 ndw=0

  7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147 ndw=0



The fields are as follows:
@@ -432,6 +432,10 @@ o "gpc" is the number of times that an old grace period had 
o	"gps" is the number of times that a new grace period had started,

	but this CPU was not yet aware of it.



o	"ndw" is the number of times that a wakeup of an rcuo

	callback-offload kthread had to be deferred in order to avoid

	deadlock.



o	"nn" is the number of times that this CPU needed nothing.
@@ -443,7 +447,7 @@ The output of "cat rcu/rcuboost" looks as follows: 
    balk: nt=0 egt=6541 bt=0 nb=0 ny=126 nos=0



This information is output only for rcu_preempt.  Each two-line entry

corresponds to a leaf rcu_node strcuture.  The fields are as follows:

corresponds to a leaf rcu_node structure.  The fields are as follows:



o	"n:m" is the CPU-number range for the corresponding two-line

	entry.  In the sample output above, the first entry covers

Documentation/acpi/apei/einj.txt

+18 −1
Original line number Diff line number Diff line
@@ -45,11 +45,22 @@ directory apei/einj. The following files are provided. 
  injection. Before this, please specify all necessary error

  parameters.



- flags

  Present for kernel version 3.13 and above. Used to specify which

  of param{1..4} are valid and should be used by BIOS during injection.

  Value is a bitmask as specified in ACPI5.0 spec for the

  SET_ERROR_TYPE_WITH_ADDRESS data structure:

	Bit 0 - Processor APIC field valid (see param3 below)

	Bit 1 - Memory address and mask valid (param1 and param2)

	Bit 2 - PCIe (seg,bus,dev,fn) valid (param4 below)

  If set to zero, legacy behaviour is used where the type of injection

  specifies just one bit set, and param1 is multiplexed.



- param1

  This file is used to set the first error parameter value. Effect of

  parameter depends on error_type specified. For example, if error

  type is memory related type, the param1 should be a valid physical

  memory address.

  memory address. [Unless "flag" is set - see above]



- param2

  This file is used to set the second error parameter value. Effect of
@@ -58,6 +69,12 @@ directory apei/einj. The following files are provided. 
  address mask. Linux requires page or narrower granularity, say,

  0xfffffffffffff000.



- param3

  Used when the 0x1 bit is set in "flag" to specify the APIC id



- param4

  Used when the 0x4 bit is set in "flag" to specify target PCIe device



- notrigger

  The EINJ mechanism is a two step process. First inject the error, then

  perform some actions to trigger it. Setting "notrigger" to 1 skips the