Merge branch 'perm-fix' into omap-for-v4.19/fixes-v2
Tony Lindgren
commit
ea4d65f14f
|
|
@ -382,7 +382,7 @@ IncludeIsMainRegex: '(Test)?$'
|
|||
IndentCaseLabels: false
|
||||
#IndentPPDirectives: None # Unknown to clang-format-5.0
|
||||
IndentWidth: 8
|
||||
IndentWrappedFunctionNames: true
|
||||
IndentWrappedFunctionNames: false
|
||||
JavaScriptQuotes: Leave
|
||||
JavaScriptWrapImports: true
|
||||
KeepEmptyLinesAtTheStartOfBlocks: false
|
||||
|
|
|
|||
6
.mailmap
6
.mailmap
|
|
@ -31,6 +31,8 @@ Arnaud Patard <arnaud.patard@rtp-net.org>
|
|||
Arnd Bergmann <arnd@arndb.de>
|
||||
Axel Dyks <xl@xlsigned.net>
|
||||
Axel Lin <axel.lin@gmail.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
|
||||
Ben Gardner <bgardner@wabtec.com>
|
||||
Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Björn Steinbrink <B.Steinbrink@gmx.de>
|
||||
|
|
@ -81,6 +83,9 @@ Javi Merino <javi.merino@kernel.org> <javi.merino@arm.com>
|
|||
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
|
||||
Jean Tourrilhes <jt@hpl.hp.com>
|
||||
Jeff Garzik <jgarzik@pretzel.yyz.us>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@redhat.com>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@poochiereds.net>
|
||||
Jeff Layton <jlayton@kernel.org> <jlayton@primarydata.com>
|
||||
Jens Axboe <axboe@suse.de>
|
||||
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>
|
||||
Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||
|
|
@ -154,6 +159,7 @@ Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
|
|||
Randy Dunlap <rdunlap@infradead.org> <rdunlap@xenotime.net>
|
||||
Rémi Denis-Courmont <rdenis@simphalempin.com>
|
||||
Ricardo Ribalda Delgado <ricardo.ribalda@gmail.com>
|
||||
Ross Zwisler <zwisler@kernel.org> <ross.zwisler@linux.intel.com>
|
||||
Rudolf Marek <R.Marek@sh.cvut.cz>
|
||||
Rui Saraiva <rmps@joel.ist.utl.pt>
|
||||
Sachin P Sant <ssant@in.ibm.com>
|
||||
|
|
|
|||
5
CREDITS
5
CREDITS
|
|
@ -2571,6 +2571,11 @@ S: Helstorfer Str. 7
|
|||
S: D-30625 Hannover
|
||||
S: Germany
|
||||
|
||||
N: Ron Minnich
|
||||
E: rminnich@sandia.gov
|
||||
E: rminnich@gmail.com
|
||||
D: 9p filesystem development
|
||||
|
||||
N: Corey Minyard
|
||||
E: minyard@wf-rch.cirr.com
|
||||
E: minyard@mvista.com
|
||||
|
|
|
|||
|
|
@ -0,0 +1,48 @@
|
|||
These files are deprecated and will be removed. The same files are available
|
||||
under /sys/bus/typec (see Documentation/ABI/testing/sysfs-bus-typec).
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/svid
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The SVID (Standard or Vendor ID) assigned by USB-IF for this
|
||||
alternate mode.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Every supported mode will have its own directory. The name of
|
||||
a mode will be "mode<index>" (for example mode1), where <index>
|
||||
is the actual index to the mode VDO returned by Discover Modes
|
||||
USB power delivery command.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/description
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows description of the mode. The description is optional for
|
||||
the drivers, just like with the Billboard Devices.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/vdo
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows the VDO in hexadecimal returned by Discover Modes command
|
||||
for this mode.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/active
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows if the mode is active or not. The attribute can be used
|
||||
for entering/exiting the mode with partners and cable plugs, and
|
||||
with the port alternate modes it can be used for disabling
|
||||
support for specific alternate modes. Entering/exiting modes is
|
||||
supported as synchronous operation so write(2) to the attribute
|
||||
does not return until the enter/exit mode operation has
|
||||
finished. The attribute is notified when the mode is
|
||||
entered/exited so poll(2) on the attribute wakes up.
|
||||
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
|
||||
|
||||
Valid values: yes, no
|
||||
|
|
@ -42,6 +42,13 @@ Contact: K. Y. Srinivasan <kys@microsoft.com>
|
|||
Description: The 16 bit vendor ID of the device
|
||||
Users: tools/hv/lsvmbus and user level RDMA libraries
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/numa_node
|
||||
Date: Jul 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Stephen Hemminger <sthemmin@microsoft.com>
|
||||
Description: This NUMA node to which the VMBUS device is
|
||||
attached, or -1 if the node is unknown.
|
||||
|
||||
What: /sys/bus/vmbus/devices/<UUID>/channels/<N>
|
||||
Date: September. 2017
|
||||
KernelVersion: 4.14
|
||||
|
|
|
|||
|
|
@ -11,7 +11,7 @@ KernelVersion: v2.6.22
|
|||
Contact: linux-wireless@vger.kernel.org,
|
||||
Description: The rfkill class subsystem folder.
|
||||
Each registered rfkill driver is represented by an rfkillX
|
||||
subfolder (X being an integer > 0).
|
||||
subfolder (X being an integer >= 0).
|
||||
|
||||
|
||||
What: /sys/class/rfkill/rfkill[0-9]+/name
|
||||
|
|
@ -48,8 +48,8 @@ Contact: linux-wireless@vger.kernel.org
|
|||
Description: Current state of the transmitter.
|
||||
This file was scheduled to be removed in 2014, but due to its
|
||||
large number of users it will be sticking around for a bit
|
||||
longer. Despite it being marked as stabe, the newer "hard" and
|
||||
"soft" interfaces should be preffered, since it is not possible
|
||||
longer. Despite it being marked as stable, the newer "hard" and
|
||||
"soft" interfaces should be preferred, since it is not possible
|
||||
to express the 'soft and hard block' state of the rfkill driver
|
||||
through this interface. There will likely be another attempt to
|
||||
remove it in the future.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,78 @@
|
|||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
||||
asic_health
|
||||
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file shows ASIC health status. The possible values are:
|
||||
0 - health failed, 2 - health OK, 3 - ASIC in booting state.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
||||
cpld1_version
|
||||
cpld2_version
|
||||
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show with which CPLD versions have been burned
|
||||
on carrier and switch boards.
|
||||
|
||||
The files are read only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/select_iio
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: This file allows iio devices selection.
|
||||
|
||||
Attribute select_iio can be written with 0 or with 1. It
|
||||
selects which one of iio devices can be accessed.
|
||||
|
||||
The file is read/write.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu1_on
|
||||
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/psu2_on
|
||||
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_cycle
|
||||
/sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/pwr_down
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files allow asserting system power cycling, switching
|
||||
power supply units on and off and system's main power domain
|
||||
shutdown.
|
||||
Expected behavior:
|
||||
When pwr_cycle is written 1: auxiliary power domain will go
|
||||
down and after short period (about 1 second) up.
|
||||
When psu1_on or psu2_on is written 1, related unit will be
|
||||
disconnected from the power source, when written 0 - connected.
|
||||
If both are written 1 - power supplies main power domain will
|
||||
go down.
|
||||
When pwr_down is written 1, system's main power domain will go
|
||||
down.
|
||||
|
||||
The files are write only.
|
||||
|
||||
What: /sys/devices/platform/mlxplat/mlxreg-io/hwmon/hwmon*/
|
||||
reset_aux_pwr_or_ref
|
||||
reset_asic_thermal
|
||||
reset_hotswap_or_halt
|
||||
reset_hotswap_or_wd
|
||||
reset_fw_reset
|
||||
reset_long_pb
|
||||
reset_main_pwr_fail
|
||||
reset_short_pb
|
||||
reset_sw_reset
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Vadim Pasternak <vadimpmellanox.com>
|
||||
Description: These files show the system reset cause, as following: power
|
||||
auxiliary outage or power refresh, ASIC thermal shutdown, halt,
|
||||
hotswap, watchdog, firmware reset, long press power button,
|
||||
short press power button, software reset. Value 1 in file means
|
||||
this is reset cause, 0 - otherwise. Only one of the above
|
||||
causes could be 1 at the same time, representing only last
|
||||
reset cause.
|
||||
|
||||
The files are read only.
|
||||
|
|
@ -263,3 +263,8 @@ Description: Specific streaming header descriptors
|
|||
is connected
|
||||
bmInfo - capabilities of this video streaming
|
||||
interface
|
||||
|
||||
What: /sys/class/udc/udc.name/device/gadget/video4linux/video.name/function_name
|
||||
Date: May 2018
|
||||
KernelVersion: 4.19
|
||||
Description: UVC configfs function instance name
|
||||
|
|
|
|||
|
|
@ -13,10 +13,11 @@ Contact: linuxppc-dev@lists.ozlabs.org
|
|||
Description: Write an integer containing the size in bytes of the memory
|
||||
you want removed from each NUMA node to this file - it must be
|
||||
aligned to the memblock size. This amount of RAM will be removed
|
||||
from the kernel mappings and the following debugfs files will be
|
||||
created. This can only be successfully done once per boot. Once
|
||||
memory is successfully removed from each node, the following
|
||||
files are created.
|
||||
from each NUMA node in the kernel mappings and the following
|
||||
debugfs files will be created. Once memory is successfully
|
||||
removed from each node, the following files are created. To
|
||||
re-add memory to the kernel, echo 0 into this file (it will be
|
||||
automatically onlined).
|
||||
|
||||
What: /sys/kernel/debug/powerpc/memtrace/<node-id>
|
||||
Date: Aug 2017
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@ Description:
|
|||
The /proc/diskstats file displays the I/O statistics
|
||||
of block devices. Each line contains the following 14
|
||||
fields:
|
||||
|
||||
1 - major number
|
||||
2 - minor mumber
|
||||
3 - device name
|
||||
|
|
@ -19,4 +20,13 @@ Description:
|
|||
12 - I/Os currently in progress
|
||||
13 - time spent doing I/Os (ms)
|
||||
14 - weighted time spent doing I/Os (ms)
|
||||
|
||||
Kernel 4.18+ appends four more fields for discard
|
||||
tracking putting the total at 18:
|
||||
|
||||
15 - discards completed successfully
|
||||
16 - discards merged
|
||||
17 - sectors discarded
|
||||
18 - time spent discarding
|
||||
|
||||
For more details refer to Documentation/iostats.txt
|
||||
|
|
|
|||
|
|
@ -83,3 +83,11 @@ KernelVersion: 4.7
|
|||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
Description: (R) Indicates the capabilities of the Coresight TMC.
|
||||
The value is read directly from the DEVID register, 0xFC8,
|
||||
|
||||
What: /sys/bus/coresight/devices/<memory_map>.tmc/buffer_size
|
||||
Date: December 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
Description: (RW) Size of the trace buffer for TMC-ETR when used in SYSFS
|
||||
mode. Writable only for TMC-ETR configurations. The value
|
||||
should be aligned to the kernel pagesize.
|
||||
|
|
|
|||
|
|
@ -197,6 +197,18 @@ Description:
|
|||
Angle of rotation. Units after application of scale and offset
|
||||
are radians.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_positionrelative_y_raw
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Relative position in direction x or y on a pad (may be
|
||||
arbitrarily assigned but should match other such assignments on
|
||||
device).
|
||||
Units after application of scale and offset are milli percents
|
||||
from the pad's size in both directions. Should be calibrated by
|
||||
the consumer.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_raw
|
||||
|
|
@ -1295,13 +1307,16 @@ What: /sys/.../iio:deviceX/in_intensityY_raw
|
|||
What: /sys/.../iio:deviceX/in_intensityY_ir_raw
|
||||
What: /sys/.../iio:deviceX/in_intensityY_both_raw
|
||||
What: /sys/.../iio:deviceX/in_intensityY_uv_raw
|
||||
What: /sys/.../iio:deviceX/in_intensityY_duv_raw
|
||||
KernelVersion: 3.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Unit-less light intensity. Modifiers both and ir indicate
|
||||
that measurements contain visible and infrared light
|
||||
components or just infrared light, respectively. Modifier uv indicates
|
||||
that measurements contain ultraviolet light components.
|
||||
components or just infrared light, respectively. Modifier
|
||||
uv indicates that measurements contain ultraviolet light
|
||||
components. Modifier duv indicates that measurements
|
||||
contain deep ultraviolet light components.
|
||||
|
||||
What: /sys/.../iio:deviceX/in_uvindex_input
|
||||
KernelVersion: 4.6
|
||||
|
|
@ -1663,3 +1678,10 @@ KernelVersion: 4.12
|
|||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw counter device counters direction for channel Y.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_phaseY_raw
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Raw (unscaled) phase difference reading from channel Y
|
||||
that can be processed to radians.
|
||||
|
|
@ -0,0 +1,47 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_agc_gain
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_agc_gain_bias
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This sensor has an automatic gain control (agc) loop
|
||||
which sets the analog signal levels at an optimum
|
||||
level by controlling programmable gain amplifiers. The
|
||||
criteria for optimal gain is determined by the sensor.
|
||||
|
||||
Return the actual gain value as an integer in [0; 65536]
|
||||
range when read from.
|
||||
|
||||
The agc gain read when measuring crosstalk shall be
|
||||
written into in_proximity0_agc_gain_bias.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_temp_a
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_temp_b
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_light_a
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calib_phase_light_b
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
The sensor is able to perform correction of distance
|
||||
measurements due to changing temperature and ambient
|
||||
light conditions. It can be programmed to correct for
|
||||
a second order error polynomial.
|
||||
|
||||
Phase data has to be collected when temperature and
|
||||
ambient light are modulated independently.
|
||||
|
||||
Then a least squares curve fit to a second order
|
||||
polynomial has to be generated from the data. The
|
||||
resultant curves have the form ax^2 + bx + c.
|
||||
|
||||
From those two curves, a and b coefficients shall be
|
||||
stored in in_proximity0_calib_phase_temp_a and
|
||||
in_proximity0_calib_phase_temp_b for temperature and
|
||||
in in_proximity0_calib_phase_light_a and
|
||||
in_proximity0_calib_phase_light_b for ambient light.
|
||||
|
||||
Those values must be integer in [0; 8355840] range.
|
||||
|
||||
Finally, the c constant is set by the sensor
|
||||
internally.
|
||||
|
||||
The value stored in sensor is displayed when read from.
|
||||
|
|
@ -0,0 +1,22 @@
|
|||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ir_small_raw
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Unit-less infrared intensity. The intensity is measured from 1
|
||||
dark photodiode. "small" indicate the surface area capturing
|
||||
infrared.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ir_large_raw
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Unit-less infrared intensity. The intensity is measured from 4
|
||||
dark photodiodes. "large" indicate the surface area capturing
|
||||
infrared.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_large_raw
|
||||
KernelVersion: 4.18
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Unit-less light intensity with more diodes.
|
||||
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
==========================
|
||||
PCIe Device AER statistics
|
||||
==========================
|
||||
These attributes show up under all the devices that are AER capable. These
|
||||
statistical counters indicate the errors "as seen/reported by the device".
|
||||
Note that this may mean that if an endpoint is causing problems, the AER
|
||||
counters may increment at its link partner (e.g. root port) because the
|
||||
errors may be "seen" / reported by the link partner and not the
|
||||
problematic endpoint itself (which may report all counters as 0 as it never
|
||||
saw any problems).
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_dev_correctable
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: List of correctable errors seen and reported by this
|
||||
PCI device using ERR_COR. Note that since multiple errors may
|
||||
be reported using a single ERR_COR message, thus
|
||||
TOTAL_ERR_COR at the end of the file may not match the actual
|
||||
total of all the errors in the file. Sample output:
|
||||
-------------------------------------------------------------------------
|
||||
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_correctable
|
||||
Receiver Error 2
|
||||
Bad TLP 0
|
||||
Bad DLLP 0
|
||||
RELAY_NUM Rollover 0
|
||||
Replay Timer Timeout 0
|
||||
Advisory Non-Fatal 0
|
||||
Corrected Internal Error 0
|
||||
Header Log Overflow 0
|
||||
TOTAL_ERR_COR 2
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_dev_fatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: List of uncorrectable fatal errors seen and reported by this
|
||||
PCI device using ERR_FATAL. Note that since multiple errors may
|
||||
be reported using a single ERR_FATAL message, thus
|
||||
TOTAL_ERR_FATAL at the end of the file may not match the actual
|
||||
total of all the errors in the file. Sample output:
|
||||
-------------------------------------------------------------------------
|
||||
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_fatal
|
||||
Undefined 0
|
||||
Data Link Protocol 0
|
||||
Surprise Down Error 0
|
||||
Poisoned TLP 0
|
||||
Flow Control Protocol 0
|
||||
Completion Timeout 0
|
||||
Completer Abort 0
|
||||
Unexpected Completion 0
|
||||
Receiver Overflow 0
|
||||
Malformed TLP 0
|
||||
ECRC 0
|
||||
Unsupported Request 0
|
||||
ACS Violation 0
|
||||
Uncorrectable Internal Error 0
|
||||
MC Blocked TLP 0
|
||||
AtomicOp Egress Blocked 0
|
||||
TLP Prefix Blocked Error 0
|
||||
TOTAL_ERR_FATAL 0
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_dev_nonfatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: List of uncorrectable nonfatal errors seen and reported by this
|
||||
PCI device using ERR_NONFATAL. Note that since multiple errors
|
||||
may be reported using a single ERR_FATAL message, thus
|
||||
TOTAL_ERR_NONFATAL at the end of the file may not match the
|
||||
actual total of all the errors in the file. Sample output:
|
||||
-------------------------------------------------------------------------
|
||||
localhost /sys/devices/pci0000:00/0000:00:1c.0 # cat aer_dev_nonfatal
|
||||
Undefined 0
|
||||
Data Link Protocol 0
|
||||
Surprise Down Error 0
|
||||
Poisoned TLP 0
|
||||
Flow Control Protocol 0
|
||||
Completion Timeout 0
|
||||
Completer Abort 0
|
||||
Unexpected Completion 0
|
||||
Receiver Overflow 0
|
||||
Malformed TLP 0
|
||||
ECRC 0
|
||||
Unsupported Request 0
|
||||
ACS Violation 0
|
||||
Uncorrectable Internal Error 0
|
||||
MC Blocked TLP 0
|
||||
AtomicOp Egress Blocked 0
|
||||
TLP Prefix Blocked Error 0
|
||||
TOTAL_ERR_NONFATAL 0
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
============================
|
||||
PCIe Rootport AER statistics
|
||||
============================
|
||||
These attributes show up under only the rootports (or root complex event
|
||||
collectors) that are AER capable. These indicate the number of error messages as
|
||||
"reported to" the rootport. Please note that the rootports also transmit
|
||||
(internally) the ERR_* messages for errors seen by the internal rootport PCI
|
||||
device, so these counters include them and are thus cumulative of all the error
|
||||
messages on the PCI hierarchy originating at that root port.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_cor
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: Total number of ERR_COR messages reported to rootport.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_fatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: Total number of ERR_FATAL messages reported to rootport.
|
||||
|
||||
Where: /sys/bus/pci/devices/<dev>/aer_stats/aer_rootport_total_err_nonfatal
|
||||
Date: July 2018
|
||||
Kernel Version: 4.19.0
|
||||
Contact: linux-pci@vger.kernel.org, rajatja@google.com
|
||||
Description: Total number of ERR_NONFATAL messages reported to rootport.
|
||||
|
|
@ -0,0 +1,51 @@
|
|||
What: /sys/bus/typec/devices/.../active
|
||||
Date: July 2018
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows if the mode is active or not. The attribute can be used
|
||||
for entering/exiting the mode. Entering/exiting modes is
|
||||
supported as synchronous operation so write(2) to the attribute
|
||||
does not return until the enter/exit mode operation has
|
||||
finished. The attribute is notified when the mode is
|
||||
entered/exited so poll(2) on the attribute wakes up.
|
||||
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
|
||||
|
||||
Valid values are boolean.
|
||||
|
||||
What: /sys/bus/typec/devices/.../description
|
||||
Date: July 2018
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows description of the mode. The description is optional for
|
||||
the drivers, just like with the Billboard Devices.
|
||||
|
||||
What: /sys/bus/typec/devices/.../mode
|
||||
Date: July 2018
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The index number of the mode returned by Discover Modes USB
|
||||
Power Delivery command. Depending on the alternate mode, the
|
||||
mode index may be significant.
|
||||
|
||||
With some alternate modes (SVIDs), the mode index is assigned
|
||||
for specific functionality in the specification for that
|
||||
alternate mode.
|
||||
|
||||
With other alternate modes, the mode index values are not
|
||||
assigned, and can not be therefore used for identification. When
|
||||
the mode index is not assigned, identifying the alternate mode
|
||||
must be done with either mode VDO or the description.
|
||||
|
||||
What: /sys/bus/typec/devices/.../svid
|
||||
Date: July 2018
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The Standard or Vendor ID (SVID) assigned by USB-IF for this
|
||||
alternate mode.
|
||||
|
||||
What: /sys/bus/typec/devices/.../vdo
|
||||
Date: July 2018
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows the VDO in hexadecimal returned by Discover Modes command
|
||||
for this mode.
|
||||
|
|
@ -35,3 +35,27 @@ Description: Read fpga manager state as a string.
|
|||
* write complete = Doing post programming steps
|
||||
* write complete error = Error while doing post programming
|
||||
* operating = FPGA is programmed and operating
|
||||
|
||||
What: /sys/class/fpga_manager/<fpga>/status
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Wu Hao <hao.wu@intel.com>
|
||||
Description: Read fpga manager status as a string.
|
||||
If FPGA programming operation fails, it could be caused by crc
|
||||
error or incompatible bitstream image. The intent of this
|
||||
interface is to provide more detailed information for FPGA
|
||||
programming errors to userspace. This is a list of strings for
|
||||
the supported status.
|
||||
|
||||
* reconfig operation error - invalid operations detected by
|
||||
reconfiguration hardware.
|
||||
e.g. start reconfiguration
|
||||
with errors not cleared
|
||||
* reconfig CRC error - CRC error detected by
|
||||
reconfiguration hardware.
|
||||
* reconfig incompatible image - reconfiguration image is
|
||||
incompatible with hardware
|
||||
* reconfig IP protocol error - protocol errors detected by
|
||||
reconfiguration hardware
|
||||
* reconfig fifo overflow error - FIFO overflow detected by
|
||||
reconfiguration hardware
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
What: /sys/class/fpga_region/<region>/compat_id
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Wu Hao <hao.wu@intel.com>
|
||||
Description: FPGA region id for compatibility check, e.g. compatibility
|
||||
of the FPGA reconfiguration hardware and image. This value
|
||||
is defined or calculated by the layer that is creating the
|
||||
FPGA region. This interface returns the compat_id value or
|
||||
just error code -ENOENT in case compat_id is not used.
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
What: /sys/class/gnss/gnssN/type
|
||||
Date: May 2018
|
||||
KernelVersion: 4.18
|
||||
Contact: Johan Hovold <johan@kernel.org>
|
||||
Description:
|
||||
The GNSS receiver type. The currently identified types reflect
|
||||
the protocol(s) supported by the receiver:
|
||||
|
||||
"NMEA" NMEA 0183
|
||||
"SiRF" SiRF Binary
|
||||
"UBX" UBX
|
||||
|
||||
Note that also non-"NMEA" type receivers typically support a
|
||||
subset of NMEA 0183 with vendor extensions (e.g. to allow
|
||||
switching to a vendor protocol).
|
||||
|
|
@ -54,3 +54,14 @@ Description: Configure tx queue limit
|
|||
|
||||
Set maximal number of pending writes
|
||||
per opened session.
|
||||
|
||||
What: /sys/class/mei/meiN/fw_ver
|
||||
Date: May 2018
|
||||
KernelVersion: 4.18
|
||||
Contact: Tomas Winkler <tomas.winkler@intel.com>
|
||||
Description: Display the ME firmware version.
|
||||
|
||||
The version of the platform ME firmware is in format:
|
||||
<platform>:<major>.<minor>.<milestone>.<build_no>.
|
||||
There can be up to three such blocks for different
|
||||
FW components.
|
||||
|
|
|
|||
|
|
@ -42,6 +42,17 @@ Description:
|
|||
network device transmit queue. Possible vaules depend on the
|
||||
number of available CPU(s) in the system.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/xps_rxqs
|
||||
Date: June 2018
|
||||
KernelVersion: 4.18.0
|
||||
Contact: netdev@vger.kernel.org
|
||||
Description:
|
||||
Mask of the receive queue(s) currently enabled to participate
|
||||
into the Transmit Packet Steering packet processing flow for this
|
||||
network device transmit queue. Possible values depend on the
|
||||
number of available receive queue(s) in the network device.
|
||||
Default is disabled.
|
||||
|
||||
What: /sys/class/<iface>/queues/tx-<queue>/byte_queue_limits/hold_time
|
||||
Date: November 2011
|
||||
KernelVersion: 3.3
|
||||
|
|
|
|||
|
|
@ -222,70 +222,12 @@ Description:
|
|||
available. The value can be polled.
|
||||
|
||||
|
||||
Alternate Mode devices.
|
||||
USB Type-C port alternate mode devices.
|
||||
|
||||
The alternate modes will have Standard or Vendor ID (SVID) assigned by USB-IF.
|
||||
The ports, partners and cable plugs can have alternate modes. A supported SVID
|
||||
will consist of a set of modes. Every SVID a port/partner/plug supports will
|
||||
have a device created for it, and every supported mode for a supported SVID will
|
||||
have its own directory under that device. Below <dev> refers to the device for
|
||||
the alternate mode.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/svid
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The SVID (Standard or Vendor ID) assigned by USB-IF for this
|
||||
alternate mode.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Every supported mode will have its own directory. The name of
|
||||
a mode will be "mode<index>" (for example mode1), where <index>
|
||||
is the actual index to the mode VDO returned by Discover Modes
|
||||
USB power delivery command.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/description
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows description of the mode. The description is optional for
|
||||
the drivers, just like with the Billboard Devices.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/vdo
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows the VDO in hexadecimal returned by Discover Modes command
|
||||
for this mode.
|
||||
|
||||
What: /sys/class/typec/<port|partner|cable>/<dev>/mode<index>/active
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows if the mode is active or not. The attribute can be used
|
||||
for entering/exiting the mode with partners and cable plugs, and
|
||||
with the port alternate modes it can be used for disabling
|
||||
support for specific alternate modes. Entering/exiting modes is
|
||||
supported as synchronous operation so write(2) to the attribute
|
||||
does not return until the enter/exit mode operation has
|
||||
finished. The attribute is notified when the mode is
|
||||
entered/exited so poll(2) on the attribute wakes up.
|
||||
Entering/exiting a mode will also generate uevent KOBJ_CHANGE.
|
||||
|
||||
Valid values: yes, no
|
||||
|
||||
What: /sys/class/typec/<port>/<dev>/mode<index>/supported_roles
|
||||
What: /sys/class/typec/<port>/<alt mode>/supported_roles
|
||||
Date: April 2017
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Space separated list of the supported roles.
|
||||
|
||||
This attribute is available for the devices describing the
|
||||
alternate modes a port supports, and it will not be exposed with
|
||||
the devices presenting the alternate modes the partners or cable
|
||||
plugs support.
|
||||
|
||||
Valid values: source, sink
|
||||
|
|
|
|||
|
|
@ -476,6 +476,7 @@ What: /sys/devices/system/cpu/vulnerabilities
|
|||
/sys/devices/system/cpu/vulnerabilities/spectre_v1
|
||||
/sys/devices/system/cpu/vulnerabilities/spectre_v2
|
||||
/sys/devices/system/cpu/vulnerabilities/spec_store_bypass
|
||||
/sys/devices/system/cpu/vulnerabilities/l1tf
|
||||
Date: January 2018
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Information about CPU vulnerabilities
|
||||
|
|
@ -487,3 +488,26 @@ Description: Information about CPU vulnerabilities
|
|||
"Not affected" CPU is not affected by the vulnerability
|
||||
"Vulnerable" CPU is affected and no mitigation in effect
|
||||
"Mitigation: $M" CPU is affected and mitigation $M is in effect
|
||||
|
||||
Details about the l1tf file can be found in
|
||||
Documentation/admin-guide/l1tf.rst
|
||||
|
||||
What: /sys/devices/system/cpu/smt
|
||||
/sys/devices/system/cpu/smt/active
|
||||
/sys/devices/system/cpu/smt/control
|
||||
Date: June 2018
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Control Symetric Multi Threading (SMT)
|
||||
|
||||
active: Tells whether SMT is active (enabled and siblings online)
|
||||
|
||||
control: Read/write interface to control SMT. Possible
|
||||
values:
|
||||
|
||||
"on" SMT is enabled
|
||||
"off" SMT is disabled
|
||||
"forceoff" SMT is force disabled. Cannot be changed.
|
||||
"notsupported" SMT is not supported by the CPU
|
||||
|
||||
If control status is "forceoff" or "notsupported" writes
|
||||
are rejected.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,27 @@
|
|||
What: /sys/bus/i2c/devices/.../bd9571mwv-regulator.*.auto/backup_mode
|
||||
Date: Jul 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Geert Uytterhoeven <geert+renesas@glider.be>
|
||||
Description: Read/write the current state of DDR Backup Mode, which controls
|
||||
if DDR power rails will be kept powered during system suspend.
|
||||
("on"/"1" = enabled, "off"/"0" = disabled).
|
||||
Two types of power switches (or control signals) can be used:
|
||||
A. With a momentary power switch (or pulse signal), DDR
|
||||
Backup Mode is enabled by default when available, as the
|
||||
PMIC will be configured only during system suspend.
|
||||
B. With a toggle power switch (or level signal), the
|
||||
following steps must be followed exactly:
|
||||
1. Configure PMIC for backup mode, to change the role of
|
||||
the accessory power switch from a power switch to a
|
||||
wake-up switch,
|
||||
2. Switch accessory power switch off, to prepare for
|
||||
system suspend, which is a manual step not controlled
|
||||
by software,
|
||||
3. Suspend system,
|
||||
4. Switch accessory power switch on, to resume the
|
||||
system.
|
||||
DDR Backup Mode must be explicitly enabled by the user,
|
||||
to invoke step 1.
|
||||
See also Documentation/devicetree/bindings/mfd/bd9571mwv.txt.
|
||||
Users: User space applications for embedded boards equipped with a
|
||||
BD9571MWV PMIC.
|
||||
|
|
@ -0,0 +1,49 @@
|
|||
What: /sys/bus/typec/devices/.../displayport/configuration
|
||||
Date: July 2018
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Shows the current DisplayPort configuration for the connector.
|
||||
Valid values are USB, source and sink. Source means DisplayPort
|
||||
source, and sink means DisplayPort sink.
|
||||
|
||||
All supported configurations are listed as space separated list
|
||||
with the active one wrapped in square brackets.
|
||||
|
||||
Source example:
|
||||
|
||||
USB [source] sink
|
||||
|
||||
The configuration can be changed by writing to the file
|
||||
|
||||
Note. USB configuration does not equal to Exit Mode. It is
|
||||
separate configuration defined in VESA DisplayPort Alt Mode on
|
||||
USB Type-C Standard. Functionally it equals to the situation
|
||||
where the mode has been exited (to exit the mode, see
|
||||
Documentation/ABI/testing/sysfs-bus-typec, and use file
|
||||
/sys/bus/typec/devices/.../active).
|
||||
|
||||
What: /sys/bus/typec/devices/.../displayport/pin_assignment
|
||||
Date: July 2018
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
VESA DisplayPort Alt Mode on USB Type-C Standard defines six
|
||||
different pin assignments for USB Type-C connector that are
|
||||
labeled A, B, C, D, E, and F. The supported pin assignments are
|
||||
listed as space separated list with the active one wrapped in
|
||||
square brackets.
|
||||
|
||||
Example:
|
||||
|
||||
C [D]
|
||||
|
||||
Pin assignment can be changed by writing to the file. It is
|
||||
possible to set pin assignment before configuration has been
|
||||
set, but the assignment will not be active before the
|
||||
connector is actually configured.
|
||||
|
||||
Note. As of VESA DisplayPort Alt Mode on USB Type-C Standard
|
||||
version 1.0b, pin assignments A, B, and F are deprecated. Only
|
||||
pin assignment D can now carry simultaneously one channel of
|
||||
USB SuperSpeed protocol. From user perspective pin assignments C
|
||||
and E are equal, where all channels on the connector are used
|
||||
for carrying DisplayPort protocol (allowing higher resolutions).
|
||||
|
|
@ -51,6 +51,14 @@ Description:
|
|||
Controls the dirty page count condition for the in-place-update
|
||||
policies.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/min_seq_blocks
|
||||
Date: August 2018
|
||||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
Description:
|
||||
Controls the dirty page count condition for batched sequential
|
||||
writes in ->writepages.
|
||||
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/min_hot_blocks
|
||||
Date: March 2017
|
||||
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
What: /sys/bus/platform/devices/dfl-fme.0/ports_num
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Wu Hao <hao.wu@intel.com>
|
||||
Description: Read-only. One DFL FPGA device may have more than 1
|
||||
port/Accelerator Function Unit (AFU). It returns the
|
||||
number of ports on the FPGA device when read it.
|
||||
|
||||
What: /sys/bus/platform/devices/dfl-fme.0/bitstream_id
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Wu Hao <hao.wu@intel.com>
|
||||
Description: Read-only. It returns Bitstream (static FPGA region)
|
||||
identifier number, which includes the detailed version
|
||||
and other information of this static FPGA region.
|
||||
|
||||
What: /sys/bus/platform/devices/dfl-fme.0/bitstream_metadata
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Wu Hao <hao.wu@intel.com>
|
||||
Description: Read-only. It returns Bitstream (static FPGA region) meta
|
||||
data, which includes the synthesis date, seed and other
|
||||
information of this static FPGA region.
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
What: /sys/bus/platform/devices/dfl-port.0/id
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Wu Hao <hao.wu@intel.com>
|
||||
Description: Read-only. It returns id of this port. One DFL FPGA device
|
||||
may have more than one port. Userspace could use this id to
|
||||
distinguish different ports under same FPGA device.
|
||||
|
||||
What: /sys/bus/platform/devices/dfl-port.0/afu_id
|
||||
Date: June 2018
|
||||
KernelVersion: 4.19
|
||||
Contact: Wu Hao <hao.wu@intel.com>
|
||||
Description: Read-only. User can program different PR bitstreams to FPGA
|
||||
Accelerator Function Unit (AFU) for different functions. It
|
||||
returns uuid which could be used to identify which PR bitstream
|
||||
is programmed in this AFU.
|
||||
|
|
@ -1,5 +1,7 @@
|
|||
00-INDEX
|
||||
- this file
|
||||
acpi-info.txt
|
||||
- info on how PCI host bridges are represented in ACPI
|
||||
MSI-HOWTO.txt
|
||||
- the Message Signaled Interrupts (MSI) Driver Guide HOWTO and FAQ.
|
||||
PCIEBUS-HOWTO.txt
|
||||
|
|
|
|||
|
|
@ -0,0 +1,187 @@
|
|||
ACPI considerations for PCI host bridges
|
||||
|
||||
The general rule is that the ACPI namespace should describe everything the
|
||||
OS might use unless there's another way for the OS to find it [1, 2].
|
||||
|
||||
For example, there's no standard hardware mechanism for enumerating PCI
|
||||
host bridges, so the ACPI namespace must describe each host bridge, the
|
||||
method for accessing PCI config space below it, the address space windows
|
||||
the host bridge forwards to PCI (using _CRS), and the routing of legacy
|
||||
INTx interrupts (using _PRT).
|
||||
|
||||
PCI devices, which are below the host bridge, generally do not need to be
|
||||
described via ACPI. The OS can discover them via the standard PCI
|
||||
enumeration mechanism, using config accesses to discover and identify
|
||||
devices and read and size their BARs. However, ACPI may describe PCI
|
||||
devices if it provides power management or hotplug functionality for them
|
||||
or if the device has INTx interrupts connected by platform interrupt
|
||||
controllers and a _PRT is needed to describe those connections.
|
||||
|
||||
ACPI resource description is done via _CRS objects of devices in the ACPI
|
||||
namespace [2]. The _CRS is like a generalized PCI BAR: the OS can read
|
||||
_CRS and figure out what resource is being consumed even if it doesn't have
|
||||
a driver for the device [3]. That's important because it means an old OS
|
||||
can work correctly even on a system with new devices unknown to the OS.
|
||||
The new devices might not do anything, but the OS can at least make sure no
|
||||
resources conflict with them.
|
||||
|
||||
Static tables like MCFG, HPET, ECDT, etc., are *not* mechanisms for
|
||||
reserving address space. The static tables are for things the OS needs to
|
||||
know early in boot, before it can parse the ACPI namespace. If a new table
|
||||
is defined, an old OS needs to operate correctly even though it ignores the
|
||||
table. _CRS allows that because it is generic and understood by the old
|
||||
OS; a static table does not.
|
||||
|
||||
If the OS is expected to manage a non-discoverable device described via
|
||||
ACPI, that device will have a specific _HID/_CID that tells the OS what
|
||||
driver to bind to it, and the _CRS tells the OS and the driver where the
|
||||
device's registers are.
|
||||
|
||||
PCI host bridges are PNP0A03 or PNP0A08 devices. Their _CRS should
|
||||
describe all the address space they consume. This includes all the windows
|
||||
they forward down to the PCI bus, as well as registers of the host bridge
|
||||
itself that are not forwarded to PCI. The host bridge registers include
|
||||
things like secondary/subordinate bus registers that determine the bus
|
||||
range below the bridge, window registers that describe the apertures, etc.
|
||||
These are all device-specific, non-architected things, so the only way a
|
||||
PNP0A03/PNP0A08 driver can manage them is via _PRS/_CRS/_SRS, which contain
|
||||
the device-specific details. The host bridge registers also include ECAM
|
||||
space, since it is consumed by the host bridge.
|
||||
|
||||
ACPI defines a Consumer/Producer bit to distinguish the bridge registers
|
||||
("Consumer") from the bridge apertures ("Producer") [4, 5], but early
|
||||
BIOSes didn't use that bit correctly. The result is that the current ACPI
|
||||
spec defines Consumer/Producer only for the Extended Address Space
|
||||
descriptors; the bit should be ignored in the older QWord/DWord/Word
|
||||
Address Space descriptors. Consequently, OSes have to assume all
|
||||
QWord/DWord/Word descriptors are windows.
|
||||
|
||||
Prior to the addition of Extended Address Space descriptors, the failure of
|
||||
Consumer/Producer meant there was no way to describe bridge registers in
|
||||
the PNP0A03/PNP0A08 device itself. The workaround was to describe the
|
||||
bridge registers (including ECAM space) in PNP0C02 catch-all devices [6].
|
||||
With the exception of ECAM, the bridge register space is device-specific
|
||||
anyway, so the generic PNP0A03/PNP0A08 driver (pci_root.c) has no need to
|
||||
know about it.
|
||||
|
||||
New architectures should be able to use "Consumer" Extended Address Space
|
||||
descriptors in the PNP0A03 device for bridge registers, including ECAM,
|
||||
although a strict interpretation of [6] might prohibit this. Old x86 and
|
||||
ia64 kernels assume all address space descriptors, including "Consumer"
|
||||
Extended Address Space ones, are windows, so it would not be safe to
|
||||
describe bridge registers this way on those architectures.
|
||||
|
||||
PNP0C02 "motherboard" devices are basically a catch-all. There's no
|
||||
programming model for them other than "don't use these resources for
|
||||
anything else." So a PNP0C02 _CRS should claim any address space that is
|
||||
(1) not claimed by _CRS under any other device object in the ACPI namespace
|
||||
and (2) should not be assigned by the OS to something else.
|
||||
|
||||
The PCIe spec requires the Enhanced Configuration Access Method (ECAM)
|
||||
unless there's a standard firmware interface for config access, e.g., the
|
||||
ia64 SAL interface [7]. A host bridge consumes ECAM memory address space
|
||||
and converts memory accesses into PCI configuration accesses. The spec
|
||||
defines the ECAM address space layout and functionality; only the base of
|
||||
the address space is device-specific. An ACPI OS learns the base address
|
||||
from either the static MCFG table or a _CBA method in the PNP0A03 device.
|
||||
|
||||
The MCFG table must describe the ECAM space of non-hot pluggable host
|
||||
bridges [8]. Since MCFG is a static table and can't be updated by hotplug,
|
||||
a _CBA method in the PNP0A03 device describes the ECAM space of a
|
||||
hot-pluggable host bridge [9]. Note that for both MCFG and _CBA, the base
|
||||
address always corresponds to bus 0, even if the bus range below the bridge
|
||||
(which is reported via _CRS) doesn't start at 0.
|
||||
|
||||
|
||||
[1] ACPI 6.2, sec 6.1:
|
||||
For any device that is on a non-enumerable type of bus (for example, an
|
||||
ISA bus), OSPM enumerates the devices' identifier(s) and the ACPI
|
||||
system firmware must supply an _HID object ... for each device to
|
||||
enable OSPM to do that.
|
||||
|
||||
[2] ACPI 6.2, sec 3.7:
|
||||
The OS enumerates motherboard devices simply by reading through the
|
||||
ACPI Namespace looking for devices with hardware IDs.
|
||||
|
||||
Each device enumerated by ACPI includes ACPI-defined objects in the
|
||||
ACPI Namespace that report the hardware resources the device could
|
||||
occupy [_PRS], an object that reports the resources that are currently
|
||||
used by the device [_CRS], and objects for configuring those resources
|
||||
[_SRS]. The information is used by the Plug and Play OS (OSPM) to
|
||||
configure the devices.
|
||||
|
||||
[3] ACPI 6.2, sec 6.2:
|
||||
OSPM uses device configuration objects to configure hardware resources
|
||||
for devices enumerated via ACPI. Device configuration objects provide
|
||||
information about current and possible resource requirements, the
|
||||
relationship between shared resources, and methods for configuring
|
||||
hardware resources.
|
||||
|
||||
When OSPM enumerates a device, it calls _PRS to determine the resource
|
||||
requirements of the device. It may also call _CRS to find the current
|
||||
resource settings for the device. Using this information, the Plug and
|
||||
Play system determines what resources the device should consume and
|
||||
sets those resources by calling the device’s _SRS control method.
|
||||
|
||||
In ACPI, devices can consume resources (for example, legacy keyboards),
|
||||
provide resources (for example, a proprietary PCI bridge), or do both.
|
||||
Unless otherwise specified, resources for a device are assumed to be
|
||||
taken from the nearest matching resource above the device in the device
|
||||
hierarchy.
|
||||
|
||||
[4] ACPI 6.2, sec 6.4.3.5.1, 2, 3, 4:
|
||||
QWord/DWord/Word Address Space Descriptor (.1, .2, .3)
|
||||
General Flags: Bit [0] Ignored
|
||||
|
||||
Extended Address Space Descriptor (.4)
|
||||
General Flags: Bit [0] Consumer/Producer:
|
||||
1–This device consumes this resource
|
||||
0–This device produces and consumes this resource
|
||||
|
||||
[5] ACPI 6.2, sec 19.6.43:
|
||||
ResourceUsage specifies whether the Memory range is consumed by
|
||||
this device (ResourceConsumer) or passed on to child devices
|
||||
(ResourceProducer). If nothing is specified, then
|
||||
ResourceConsumer is assumed.
|
||||
|
||||
[6] PCI Firmware 3.2, sec 4.1.2:
|
||||
If the operating system does not natively comprehend reserving the
|
||||
MMCFG region, the MMCFG region must be reserved by firmware. The
|
||||
address range reported in the MCFG table or by _CBA method (see Section
|
||||
4.1.3) must be reserved by declaring a motherboard resource. For most
|
||||
systems, the motherboard resource would appear at the root of the ACPI
|
||||
namespace (under \_SB) in a node with a _HID of EISAID (PNP0C02), and
|
||||
the resources in this case should not be claimed in the root PCI bus’s
|
||||
_CRS. The resources can optionally be returned in Int15 E820 or
|
||||
EFIGetMemoryMap as reserved memory but must always be reported through
|
||||
ACPI as a motherboard resource.
|
||||
|
||||
[7] PCI Express 4.0, sec 7.2.2:
|
||||
For systems that are PC-compatible, or that do not implement a
|
||||
processor-architecture-specific firmware interface standard that allows
|
||||
access to the Configuration Space, the ECAM is required as defined in
|
||||
this section.
|
||||
|
||||
[8] PCI Firmware 3.2, sec 4.1.2:
|
||||
The MCFG table is an ACPI table that is used to communicate the base
|
||||
addresses corresponding to the non-hot removable PCI Segment Groups
|
||||
range within a PCI Segment Group available to the operating system at
|
||||
boot. This is required for the PC-compatible systems.
|
||||
|
||||
The MCFG table is only used to communicate the base addresses
|
||||
corresponding to the PCI Segment Groups available to the system at
|
||||
boot.
|
||||
|
||||
[9] PCI Firmware 3.2, sec 4.1.3:
|
||||
The _CBA (Memory mapped Configuration Base Address) control method is
|
||||
an optional ACPI object that returns the 64-bit memory mapped
|
||||
configuration base address for the hot plug capable host bridge. The
|
||||
base address returned by _CBA is processor-relative address. The _CBA
|
||||
control method evaluates to an Integer.
|
||||
|
||||
This control method appears under a host bridge object. When the _CBA
|
||||
method appears under an active host bridge object, the operating system
|
||||
evaluates this structure to identify the memory mapped configuration
|
||||
base address corresponding to the PCI Segment Group for the bus number
|
||||
range specified in _CRS method. An ACPI name space object that contains
|
||||
the _CBA method must also contain a corresponding _SEG method.
|
||||
|
|
@ -15,3 +15,5 @@ subsys_id : don't care
|
|||
interrupt_pin : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
|
||||
msi_interrupts : Should be 1 to 32 depending on the number of MSI interrupts
|
||||
to test
|
||||
msix_interrupts : Should be 1 to 2048 depending on the number of MSI-X
|
||||
interrupts to test
|
||||
|
|
|
|||
|
|
@ -44,7 +44,7 @@ by the PCI controller driver.
|
|||
* clear_bar: ops to reset the BAR
|
||||
* alloc_addr_space: ops to allocate in PCI controller address space
|
||||
* free_addr_space: ops to free the allocated address space
|
||||
* raise_irq: ops to raise a legacy or MSI interrupt
|
||||
* raise_irq: ops to raise a legacy, MSI or MSI-X interrupt
|
||||
* start: ops to start the PCI link
|
||||
* stop: ops to stop the PCI link
|
||||
|
||||
|
|
@ -96,7 +96,7 @@ by the PCI endpoint function driver.
|
|||
*) pci_epc_raise_irq()
|
||||
|
||||
The PCI endpoint function driver should use pci_epc_raise_irq() to raise
|
||||
Legacy Interrupt or MSI Interrupt.
|
||||
Legacy Interrupt, MSI or MSI-X Interrupt.
|
||||
|
||||
*) pci_epc_mem_alloc_addr()
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ The PCI endpoint test device has the following registers:
|
|||
5) PCI_ENDPOINT_TEST_DST_ADDR
|
||||
6) PCI_ENDPOINT_TEST_SIZE
|
||||
7) PCI_ENDPOINT_TEST_CHECKSUM
|
||||
8) PCI_ENDPOINT_TEST_IRQ_TYPE
|
||||
9) PCI_ENDPOINT_TEST_IRQ_NUMBER
|
||||
|
||||
*) PCI_ENDPOINT_TEST_MAGIC
|
||||
|
||||
|
|
@ -34,10 +36,10 @@ that the endpoint device must perform.
|
|||
Bitfield Description:
|
||||
Bit 0 : raise legacy IRQ
|
||||
Bit 1 : raise MSI IRQ
|
||||
Bit 2 - 7 : MSI interrupt number
|
||||
Bit 8 : read command (read data from RC buffer)
|
||||
Bit 9 : write command (write data to RC buffer)
|
||||
Bit 10 : copy command (copy data from one RC buffer to another
|
||||
Bit 2 : raise MSI-X IRQ
|
||||
Bit 3 : read command (read data from RC buffer)
|
||||
Bit 4 : write command (write data to RC buffer)
|
||||
Bit 5 : copy command (copy data from one RC buffer to another
|
||||
RC buffer)
|
||||
|
||||
*) PCI_ENDPOINT_TEST_STATUS
|
||||
|
|
@ -64,3 +66,22 @@ COPY/READ command.
|
|||
|
||||
This register contains the destination address (RC buffer address) for
|
||||
the COPY/WRITE command.
|
||||
|
||||
*) PCI_ENDPOINT_TEST_IRQ_TYPE
|
||||
|
||||
This register contains the interrupt type (Legacy/MSI) triggered
|
||||
for the READ/WRITE/COPY and raise IRQ (Legacy/MSI) commands.
|
||||
|
||||
Possible types:
|
||||
- Legacy : 0
|
||||
- MSI : 1
|
||||
- MSI-X : 2
|
||||
|
||||
*) PCI_ENDPOINT_TEST_IRQ_NUMBER
|
||||
|
||||
This register contains the triggered ID interrupt.
|
||||
|
||||
Admissible values:
|
||||
- Legacy : 0
|
||||
- MSI : [1 .. 32]
|
||||
- MSI-X : [1 .. 2048]
|
||||
|
|
|
|||
|
|
@ -45,9 +45,9 @@ The PCI endpoint framework populates the directory with the following
|
|||
configurable fields.
|
||||
|
||||
# ls functions/pci_epf_test/func1
|
||||
baseclass_code interrupt_pin revid subsys_vendor_id
|
||||
cache_line_size msi_interrupts subclass_code vendorid
|
||||
deviceid progif_code subsys_id
|
||||
baseclass_code interrupt_pin progif_code subsys_id
|
||||
cache_line_size msi_interrupts revid subsys_vendorid
|
||||
deviceid msix_interrupts subclass_code vendorid
|
||||
|
||||
The PCI endpoint function driver populates these entries with default values
|
||||
when the device is bound to the driver. The pci-epf-test driver populates
|
||||
|
|
@ -67,6 +67,7 @@ device, the following commands can be used.
|
|||
# echo 0x104c > functions/pci_epf_test/func1/vendorid
|
||||
# echo 0xb500 > functions/pci_epf_test/func1/deviceid
|
||||
# echo 16 > functions/pci_epf_test/func1/msi_interrupts
|
||||
# echo 8 > functions/pci_epf_test/func1/msix_interrupts
|
||||
|
||||
1.5 Binding pci-epf-test Device to EP Controller
|
||||
|
||||
|
|
@ -120,7 +121,9 @@ following commands.
|
|||
|
||||
Interrupt tests
|
||||
|
||||
SET IRQ TYPE TO LEGACY: OKAY
|
||||
LEGACY IRQ: NOT OKAY
|
||||
SET IRQ TYPE TO MSI: OKAY
|
||||
MSI1: OKAY
|
||||
MSI2: OKAY
|
||||
MSI3: OKAY
|
||||
|
|
@ -153,9 +156,30 @@ following commands.
|
|||
MSI30: NOT OKAY
|
||||
MSI31: NOT OKAY
|
||||
MSI32: NOT OKAY
|
||||
SET IRQ TYPE TO MSI-X: OKAY
|
||||
MSI-X1: OKAY
|
||||
MSI-X2: OKAY
|
||||
MSI-X3: OKAY
|
||||
MSI-X4: OKAY
|
||||
MSI-X5: OKAY
|
||||
MSI-X6: OKAY
|
||||
MSI-X7: OKAY
|
||||
MSI-X8: OKAY
|
||||
MSI-X9: NOT OKAY
|
||||
MSI-X10: NOT OKAY
|
||||
MSI-X11: NOT OKAY
|
||||
MSI-X12: NOT OKAY
|
||||
MSI-X13: NOT OKAY
|
||||
MSI-X14: NOT OKAY
|
||||
MSI-X15: NOT OKAY
|
||||
MSI-X16: NOT OKAY
|
||||
[...]
|
||||
MSI-X2047: NOT OKAY
|
||||
MSI-X2048: NOT OKAY
|
||||
|
||||
Read Tests
|
||||
|
||||
SET IRQ TYPE TO MSI: OKAY
|
||||
READ ( 1 bytes): OKAY
|
||||
READ ( 1024 bytes): OKAY
|
||||
READ ( 1025 bytes): OKAY
|
||||
|
|
|
|||
|
|
@ -73,6 +73,11 @@ In the example, 'Requester ID' means the ID of the device who sends
|
|||
the error message to root port. Pls. refer to pci express specs for
|
||||
other fields.
|
||||
|
||||
2.4 AER Statistics / Counters
|
||||
|
||||
When PCIe AER errors are captured, the counters / statistics are also exposed
|
||||
in the form of sysfs attributes which are documented at
|
||||
Documentation/ABI/testing/sysfs-bus-pci-devices-aer_stats
|
||||
|
||||
3. Developer Guide
|
||||
|
||||
|
|
|
|||
|
|
@ -380,31 +380,26 @@ and therefore need no protection.
|
|||
as follows:
|
||||
|
||||
<pre>
|
||||
1 unsigned long gpnum;
|
||||
2 unsigned long completed;
|
||||
1 unsigned long gp_seq;
|
||||
</pre>
|
||||
|
||||
<p>RCU grace periods are numbered, and
|
||||
the <tt>->gpnum</tt> field contains the number of the grace
|
||||
period that started most recently.
|
||||
The <tt>->completed</tt> field contains the number of the
|
||||
grace period that completed most recently.
|
||||
If the two fields are equal, the RCU grace period that most recently
|
||||
started has already completed, and therefore the corresponding
|
||||
flavor of RCU is idle.
|
||||
If <tt>->gpnum</tt> is one greater than <tt>->completed</tt>,
|
||||
then <tt>->gpnum</tt> gives the number of the current RCU
|
||||
grace period, which has not yet completed.
|
||||
Any other combination of values indicates that something is broken.
|
||||
These two fields are protected by the root <tt>rcu_node</tt>'s
|
||||
the <tt>->gp_seq</tt> field contains the current grace-period
|
||||
sequence number.
|
||||
The bottom two bits are the state of the current grace period,
|
||||
which can be zero for not yet started or one for in progress.
|
||||
In other words, if the bottom two bits of <tt>->gp_seq</tt> are
|
||||
zero, the corresponding flavor of RCU is idle.
|
||||
Any other value in the bottom two bits indicates that something is broken.
|
||||
This field is protected by the root <tt>rcu_node</tt> structure's
|
||||
<tt>->lock</tt> field.
|
||||
|
||||
</p><p>There are <tt>->gpnum</tt> and <tt>->completed</tt> fields
|
||||
</p><p>There are <tt>->gp_seq</tt> fields
|
||||
in the <tt>rcu_node</tt> and <tt>rcu_data</tt> structures
|
||||
as well.
|
||||
The fields in the <tt>rcu_state</tt> structure represent the
|
||||
most current values, and those of the other structures are compared
|
||||
in order to detect the start of a new grace period in a distributed
|
||||
most current value, and those of the other structures are compared
|
||||
in order to detect the beginnings and ends of grace periods in a distributed
|
||||
fashion.
|
||||
The values flow from <tt>rcu_state</tt> to <tt>rcu_node</tt>
|
||||
(down the tree from the root to the leaves) to <tt>rcu_data</tt>.
|
||||
|
|
@ -512,27 +507,47 @@ than to be heisenbugged out of existence.
|
|||
as follows:
|
||||
|
||||
<pre>
|
||||
1 unsigned long gpnum;
|
||||
2 unsigned long completed;
|
||||
1 unsigned long gp_seq;
|
||||
2 unsigned long gp_seq_needed;
|
||||
</pre>
|
||||
|
||||
<p>These fields are the counterparts of the fields of the same name in
|
||||
the <tt>rcu_state</tt> structure.
|
||||
They each may lag up to one behind their <tt>rcu_state</tt>
|
||||
counterparts.
|
||||
If a given <tt>rcu_node</tt> structure's <tt>->gpnum</tt> and
|
||||
<tt>->complete</tt> fields are equal, then this <tt>rcu_node</tt>
|
||||
<p>The <tt>rcu_node</tt> structures' <tt>->gp_seq</tt> fields are
|
||||
the counterparts of the field of the same name in the <tt>rcu_state</tt>
|
||||
structure.
|
||||
They each may lag up to one step behind their <tt>rcu_state</tt>
|
||||
counterpart.
|
||||
If the bottom two bits of a given <tt>rcu_node</tt> structure's
|
||||
<tt>->gp_seq</tt> field is zero, then this <tt>rcu_node</tt>
|
||||
structure believes that RCU is idle.
|
||||
Otherwise, as with the <tt>rcu_state</tt> structure,
|
||||
the <tt>->gpnum</tt> field will be one greater than the
|
||||
<tt>->complete</tt> fields, with <tt>->gpnum</tt>
|
||||
indicating which grace period this <tt>rcu_node</tt> believes
|
||||
is still being waited for.
|
||||
</p><p>The <tt>>gp_seq</tt> field of each <tt>rcu_node</tt>
|
||||
structure is updated at the beginning and the end
|
||||
of each grace period.
|
||||
|
||||
</p><p>The <tt>>gpnum</tt> field of each <tt>rcu_node</tt>
|
||||
structure is updated at the beginning
|
||||
of each grace period, and the <tt>->completed</tt> fields are
|
||||
updated at the end of each grace period.
|
||||
<p>The <tt>->gp_seq_needed</tt> fields record the
|
||||
furthest-in-the-future grace period request seen by the corresponding
|
||||
<tt>rcu_node</tt> structure. The request is considered fulfilled when
|
||||
the value of the <tt>->gp_seq</tt> field equals or exceeds that of
|
||||
the <tt>->gp_seq_needed</tt> field.
|
||||
|
||||
<table>
|
||||
<tr><th> </th></tr>
|
||||
<tr><th align="left">Quick Quiz:</th></tr>
|
||||
<tr><td>
|
||||
Suppose that this <tt>rcu_node</tt> structure doesn't see
|
||||
a request for a very long time.
|
||||
Won't wrapping of the <tt>->gp_seq</tt> field cause
|
||||
problems?
|
||||
</td></tr>
|
||||
<tr><th align="left">Answer:</th></tr>
|
||||
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
||||
No, because if the <tt>->gp_seq_needed</tt> field lags behind the
|
||||
<tt>->gp_seq</tt> field, the <tt>->gp_seq_needed</tt> field
|
||||
will be updated at the end of the grace period.
|
||||
Modulo-arithmetic comparisons therefore will always get the
|
||||
correct answer, even with wrapping.
|
||||
</font></td></tr>
|
||||
<tr><td> </td></tr>
|
||||
</table>
|
||||
|
||||
<h5>Quiescent-State Tracking</h5>
|
||||
|
||||
|
|
@ -626,9 +641,8 @@ normal and expedited grace periods, respectively.
|
|||
</ol>
|
||||
|
||||
<p><font color="ffffff">So the locking is absolutely required in
|
||||
order to coordinate
|
||||
clearing of the bits with the grace-period numbers in
|
||||
<tt>->gpnum</tt> and <tt>->completed</tt>.
|
||||
order to coordinate clearing of the bits with updating of the
|
||||
grace-period sequence number in <tt>->gp_seq</tt>.
|
||||
</font></td></tr>
|
||||
<tr><td> </td></tr>
|
||||
</table>
|
||||
|
|
@ -1038,15 +1052,15 @@ out any <tt>rcu_data</tt> structure for which this flag is not set.
|
|||
as follows:
|
||||
|
||||
<pre>
|
||||
1 unsigned long completed;
|
||||
2 unsigned long gpnum;
|
||||
1 unsigned long gp_seq;
|
||||
2 unsigned long gp_seq_needed;
|
||||
3 bool cpu_no_qs;
|
||||
4 bool core_needs_qs;
|
||||
5 bool gpwrap;
|
||||
6 unsigned long rcu_qs_ctr_snap;
|
||||
</pre>
|
||||
|
||||
<p>The <tt>completed</tt> and <tt>gpnum</tt>
|
||||
<p>The <tt>->gp_seq</tt> and <tt>->gp_seq_needed</tt>
|
||||
fields are the counterparts of the fields of the same name
|
||||
in the <tt>rcu_state</tt> and <tt>rcu_node</tt> structures.
|
||||
They may each lag up to one behind their <tt>rcu_node</tt>
|
||||
|
|
@ -1054,15 +1068,9 @@ counterparts, but in <tt>CONFIG_NO_HZ_IDLE</tt> and
|
|||
<tt>CONFIG_NO_HZ_FULL</tt> kernels can lag
|
||||
arbitrarily far behind for CPUs in dyntick-idle mode (but these counters
|
||||
will catch up upon exit from dyntick-idle mode).
|
||||
If a given <tt>rcu_data</tt> structure's <tt>->gpnum</tt> and
|
||||
<tt>->complete</tt> fields are equal, then this <tt>rcu_data</tt>
|
||||
If the lower two bits of a given <tt>rcu_data</tt> structure's
|
||||
<tt>->gp_seq</tt> are zero, then this <tt>rcu_data</tt>
|
||||
structure believes that RCU is idle.
|
||||
Otherwise, as with the <tt>rcu_state</tt> and <tt>rcu_node</tt>
|
||||
structure,
|
||||
the <tt>->gpnum</tt> field will be one greater than the
|
||||
<tt>->complete</tt> fields, with <tt>->gpnum</tt>
|
||||
indicating which grace period this <tt>rcu_data</tt> believes
|
||||
is still being waited for.
|
||||
|
||||
<table>
|
||||
<tr><th> </th></tr>
|
||||
|
|
@ -1070,13 +1078,13 @@ is still being waited for.
|
|||
<tr><td>
|
||||
All this replication of the grace period numbers can only cause
|
||||
massive confusion.
|
||||
Why not just keep a global pair of counters and be done with it???
|
||||
Why not just keep a global sequence number and be done with it???
|
||||
</td></tr>
|
||||
<tr><th align="left">Answer:</th></tr>
|
||||
<tr><td bgcolor="#ffffff"><font color="ffffff">
|
||||
Because if there was only a single global pair of grace-period
|
||||
Because if there was only a single global sequence
|
||||
numbers, there would need to be a single global lock to allow
|
||||
safely accessing and updating them.
|
||||
safely accessing and updating it.
|
||||
And if we are not going to have a single global lock, we need
|
||||
to carefully manage the numbers on a per-node basis.
|
||||
Recall from the answer to a previous Quick Quiz that the consequences
|
||||
|
|
@ -1091,8 +1099,8 @@ CPU has not yet passed through a quiescent state,
|
|||
while the <tt>->core_needs_qs</tt> flag indicates that the
|
||||
RCU core needs a quiescent state from the corresponding CPU.
|
||||
The <tt>->gpwrap</tt> field indicates that the corresponding
|
||||
CPU has remained idle for so long that the <tt>completed</tt>
|
||||
and <tt>gpnum</tt> counters are in danger of overflow, which
|
||||
CPU has remained idle for so long that the
|
||||
<tt>gp_seq</tt> counter is in danger of overflow, which
|
||||
will cause the CPU to disregard the values of its counters on
|
||||
its next exit from idle.
|
||||
Finally, the <tt>rcu_qs_ctr_snap</tt> field is used to detect
|
||||
|
|
@ -1130,10 +1138,10 @@ The CPU advances the callbacks in its <tt>rcu_data</tt> structure
|
|||
whenever it notices that another RCU grace period has completed.
|
||||
The CPU detects the completion of an RCU grace period by noticing
|
||||
that the value of its <tt>rcu_data</tt> structure's
|
||||
<tt>->completed</tt> field differs from that of its leaf
|
||||
<tt>->gp_seq</tt> field differs from that of its leaf
|
||||
<tt>rcu_node</tt> structure.
|
||||
Recall that each <tt>rcu_node</tt> structure's
|
||||
<tt>->completed</tt> field is updated at the end of each
|
||||
<tt>->gp_seq</tt> field is updated at the beginnings and ends of each
|
||||
grace period.
|
||||
|
||||
<p>
|
||||
|
|
|
|||
|
|
@ -357,7 +357,7 @@ parts, starting in this section with the various phases of
|
|||
grace-period initialization.
|
||||
|
||||
<p>The first ordering-related grace-period initialization action is to
|
||||
increment the <tt>rcu_state</tt> structure's <tt>->gpnum</tt>
|
||||
advance the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt>
|
||||
grace-period-number counter, as shown below:
|
||||
|
||||
</p><p><img src="TreeRCU-gp-init-1.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
||||
|
|
@ -388,7 +388,7 @@ its last CPU and if the next <tt>rcu_node</tt> structure has no online CPUs).
|
|||
|
||||
<p>The final <tt>rcu_gp_init()</tt> pass through the <tt>rcu_node</tt>
|
||||
tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
|
||||
<tt>->gpnum</tt> field to the newly incremented value from the
|
||||
<tt>->gp_seq</tt> field to the newly advanced value from the
|
||||
<tt>rcu_state</tt> structure, as shown in the following diagram.
|
||||
|
||||
</p><p><img src="TreeRCU-gp-init-3.svg" alt="TreeRCU-gp-init-1.svg" width="75%">
|
||||
|
|
@ -398,9 +398,9 @@ tree traverses breadth-first, setting each <tt>rcu_node</tt> structure's
|
|||
to notice that a new grace period has started, as described in the next
|
||||
section.
|
||||
But because the grace-period kthread started the grace period at the
|
||||
root (with the increment of the <tt>rcu_state</tt> structure's
|
||||
<tt>->gpnum</tt> field) before setting each leaf <tt>rcu_node</tt>
|
||||
structure's <tt>->gpnum</tt> field, each CPU's observation of
|
||||
root (with the advancing of the <tt>rcu_state</tt> structure's
|
||||
<tt>->gp_seq</tt> field) before setting each leaf <tt>rcu_node</tt>
|
||||
structure's <tt>->gp_seq</tt> field, each CPU's observation of
|
||||
the start of the grace period will happen after the actual start
|
||||
of the grace period.
|
||||
|
||||
|
|
@ -466,7 +466,7 @@ section that the grace period must wait on.
|
|||
<tr><td>
|
||||
But a RCU read-side critical section might have started
|
||||
after the beginning of the grace period
|
||||
(the <tt>->gpnum++</tt> from earlier), so why should
|
||||
(the advancing of <tt>->gp_seq</tt> from earlier), so why should
|
||||
the grace period wait on such a critical section?
|
||||
</td></tr>
|
||||
<tr><th align="left">Answer:</th></tr>
|
||||
|
|
@ -609,10 +609,8 @@ states outstanding from other CPUs.
|
|||
<h4><a name="Grace-Period Cleanup">Grace-Period Cleanup</a></h4>
|
||||
|
||||
<p>Grace-period cleanup first scans the <tt>rcu_node</tt> tree
|
||||
breadth-first setting all the <tt>->completed</tt> fields equal
|
||||
to the number of the newly completed grace period, then it sets
|
||||
the <tt>rcu_state</tt> structure's <tt>->completed</tt> field,
|
||||
again to the number of the newly completed grace period.
|
||||
breadth-first advancing all the <tt>->gp_seq</tt> fields, then it
|
||||
advances the <tt>rcu_state</tt> structure's <tt>->gp_seq</tt> field.
|
||||
The ordering effects are shown below:
|
||||
|
||||
</p><p><img src="TreeRCU-gp-cleanup.svg" alt="TreeRCU-gp-cleanup.svg" width="75%">
|
||||
|
|
@ -634,7 +632,7 @@ grace-period cleanup is complete, the next grace period can begin.
|
|||
CPU has reported its quiescent state, but it may be some
|
||||
milliseconds before RCU becomes aware of this.
|
||||
The latest reasonable candidate is once the <tt>rcu_state</tt>
|
||||
structure's <tt>->completed</tt> field has been updated,
|
||||
structure's <tt>->gp_seq</tt> field has been updated,
|
||||
but it is quite possible that some CPUs have already completed
|
||||
phase two of their updates by that time.
|
||||
In short, if you are going to work with RCU, you need to
|
||||
|
|
@ -647,7 +645,7 @@ grace-period cleanup is complete, the next grace period can begin.
|
|||
<h4><a name="Callback Invocation">Callback Invocation</a></h4>
|
||||
|
||||
<p>Once a given CPU's leaf <tt>rcu_node</tt> structure's
|
||||
<tt>->completed</tt> field has been updated, that CPU can begin
|
||||
<tt>->gp_seq</tt> field has been updated, that CPU can begin
|
||||
invoking its RCU callbacks that were waiting for this grace period
|
||||
to end.
|
||||
These callbacks are identified by <tt>rcu_advance_cbs()</tt>,
|
||||
|
|
|
|||
|
|
@ -384,11 +384,11 @@
|
|||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.70710678"
|
||||
inkscape:cx="617.89017"
|
||||
inkscape:cy="542.52419"
|
||||
inkscape:window-x="86"
|
||||
inkscape:window-y="28"
|
||||
inkscape:zoom="0.78716603"
|
||||
inkscape:cx="513.06403"
|
||||
inkscape:cy="623.1214"
|
||||
inkscape:window-x="102"
|
||||
inkscape:window-y="38"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="g3188-3"
|
||||
fit-margin-top="5"
|
||||
|
|
@ -417,13 +417,15 @@
|
|||
id="g3188">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3199.1516"
|
||||
x="3145.9592"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->completed = ->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3143">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
<g
|
||||
id="g3107"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
|
@ -502,13 +504,15 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5324.5371"
|
||||
y="15414.598"
|
||||
x="5264.4731"
|
||||
y="15428.84"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-753"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-7"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-5">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
|
|
@ -547,15 +551,6 @@
|
|||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7479.5796"
|
||||
y="17699.943"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-9"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
<path
|
||||
sodipodi:nodetypes="cc"
|
||||
inkscape:connector-curvature="0"
|
||||
|
|
@ -566,15 +561,6 @@
|
|||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(-737.93887,7732.6672)"
|
||||
id="g3188-3">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3225.7478"
|
||||
y="13175.802"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-60"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->completed =</text>
|
||||
<g
|
||||
id="g3107-62"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
|
@ -607,15 +593,6 @@
|
|||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-7">Root</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3225.7478"
|
||||
y="13390.038"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-60-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"> rnp->completed</text>
|
||||
<flowRoot
|
||||
xml:space="preserve"
|
||||
id="flowRoot3356"
|
||||
|
|
@ -627,7 +604,18 @@
|
|||
height="63.63961"
|
||||
x="332.34018"
|
||||
y="681.87292" /></flowRegion><flowPara
|
||||
id="flowPara3362" /></flowRoot> </g>
|
||||
id="flowPara3362" /></flowRoot> <text
|
||||
xml:space="preserve"
|
||||
x="3156.6121"
|
||||
y="13317.754"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-0">rcu_seq_end(&rsp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(-858.40227,7769.0342)"
|
||||
|
|
@ -859,6 +847,17 @@
|
|||
id="path3414-8-3-6-6"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7418.769"
|
||||
y="17646.104"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-70"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-93">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-1642.5377,-11611.245)"
|
||||
|
|
@ -887,13 +886,15 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5327.3057"
|
||||
x="5274.1133"
|
||||
y="15428.84"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-151.71746,-11647.612)"
|
||||
|
|
@ -972,13 +973,15 @@
|
|||
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7486.4907"
|
||||
y="17670.119"
|
||||
x="7408.5918"
|
||||
y="17619.504"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-9">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-6817.1997,-11647.612)"
|
||||
|
|
@ -1019,13 +1022,15 @@
|
|||
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7474.1382"
|
||||
y="17688.926"
|
||||
x="7416.8003"
|
||||
y="17619.504"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-5"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-56">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||
|
|
@ -1059,15 +1064,6 @@
|
|||
id="path3414-8-3-6"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7318.9653"
|
||||
y="6031.6353"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
id="g4504-3-9"
|
||||
|
|
@ -1123,4 +1119,15 @@
|
|||
id="path3134-9-0-3-5"
|
||||
d="m 6875.6003,15833.906 1595.7755,0"
|
||||
style="fill:none;stroke:#969696;stroke-width:53.19251633;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send-36)" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7275.2612"
|
||||
y="5971.8916"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-2">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</svg>
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 42 KiB After Width: | Height: | Size: 42 KiB |
|
|
@ -272,13 +272,13 @@
|
|||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.70710678"
|
||||
inkscape:cx="617.89019"
|
||||
inkscape:cy="636.57143"
|
||||
inkscape:window-x="697"
|
||||
inkscape:zoom="2.6330492"
|
||||
inkscape:cx="524.82797"
|
||||
inkscape:cy="519.31194"
|
||||
inkscape:window-x="79"
|
||||
inkscape:window-y="28"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="svg2"
|
||||
inkscape:current-layer="g3188"
|
||||
fit-margin-top="5"
|
||||
fit-margin-right="5"
|
||||
fit-margin-left="5"
|
||||
|
|
@ -305,13 +305,15 @@
|
|||
id="g3188">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3305.5364"
|
||||
x="3119.363"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->gpnum++</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3071">rcu_seq_start(rsp->gp_seq)</tspan></text>
|
||||
<g
|
||||
id="g3107"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 23 KiB After Width: | Height: | Size: 24 KiB |
|
|
@ -19,7 +19,7 @@
|
|||
id="svg2"
|
||||
version="1.1"
|
||||
inkscape:version="0.48.4 r9939"
|
||||
sodipodi:docname="TreeRCU-gp-init-2.svg">
|
||||
sodipodi:docname="TreeRCU-gp-init-3.svg">
|
||||
<metadata
|
||||
id="metadata212">
|
||||
<rdf:RDF>
|
||||
|
|
@ -257,18 +257,22 @@
|
|||
inkscape:window-width="1087"
|
||||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="false"
|
||||
inkscape:zoom="0.70710678"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.68224756"
|
||||
inkscape:cx="617.89019"
|
||||
inkscape:cy="625.84293"
|
||||
inkscape:window-x="697"
|
||||
inkscape:window-x="54"
|
||||
inkscape:window-y="28"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="svg2"
|
||||
inkscape:current-layer="g3153"
|
||||
fit-margin-top="5"
|
||||
fit-margin-right="5"
|
||||
fit-margin-left="5"
|
||||
fit-margin-bottom="5" />
|
||||
fit-margin-bottom="5">
|
||||
<inkscape:grid
|
||||
type="xygrid"
|
||||
id="grid3090" />
|
||||
</sodipodi:namedview>
|
||||
<path
|
||||
sodipodi:nodetypes="cccccccccccccccccccccccc"
|
||||
inkscape:connector-curvature="0"
|
||||
|
|
@ -281,13 +285,13 @@
|
|||
id="g3188">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3305.5364"
|
||||
x="3145.9592"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
<g
|
||||
id="g3107"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
|
@ -366,13 +370,13 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5392.3345"
|
||||
y="15407.104"
|
||||
x="5253.6904"
|
||||
y="15407.032"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
|
|
@ -413,13 +417,13 @@
|
|||
id="tspan3104-6-5-6-0">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7536.4883"
|
||||
y="17640.934"
|
||||
x="7415.4365"
|
||||
y="17670.572"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-9"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-1642.5375,-11610.962)"
|
||||
|
|
@ -448,13 +452,13 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5378.4146"
|
||||
y="15436.927"
|
||||
x="5258.0688"
|
||||
y="15412.313"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-151.71726,-11647.329)"
|
||||
|
|
@ -533,13 +537,13 @@
|
|||
id="tspan3104-6-5-6-0-92">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7520.1294"
|
||||
y="17673.639"
|
||||
x="7405.2607"
|
||||
y="17670.572"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-35"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-6817.1998,-11647.329)"
|
||||
|
|
@ -580,13 +584,13 @@
|
|||
id="tspan3104-6-5-6-0-1">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7521.4663"
|
||||
y="17666.062"
|
||||
x="7413.4688"
|
||||
y="17670.566"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-75"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:13.29812908px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||
|
|
@ -622,11 +626,11 @@
|
|||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7370.856"
|
||||
y="5997.5972"
|
||||
x="7271.9297"
|
||||
y="6023.2412"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-62"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</svg>
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 22 KiB After Width: | Height: | Size: 23 KiB |
|
|
@ -1070,13 +1070,13 @@
|
|||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.6004608"
|
||||
inkscape:cx="826.65969"
|
||||
inkscape:cy="483.3047"
|
||||
inkscape:window-x="66"
|
||||
inkscape:window-y="28"
|
||||
inkscape:zoom="0.81932583"
|
||||
inkscape:cx="840.45848"
|
||||
inkscape:cy="5052.4242"
|
||||
inkscape:window-x="787"
|
||||
inkscape:window-y="24"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="svg2"
|
||||
inkscape:current-layer="g4"
|
||||
fit-margin-top="5"
|
||||
fit-margin-right="5"
|
||||
fit-margin-left="5"
|
||||
|
|
@ -1543,15 +1543,6 @@
|
|||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(1749.0282,658.72243)"
|
||||
id="g3188">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3305.5364"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-5"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">rsp->gpnum++</text>
|
||||
<g
|
||||
id="g3107-62"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
|
@ -1584,6 +1575,17 @@
|
|||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-7">Root</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3137.9988"
|
||||
y="13271.316"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-626"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3071">rcu_seq_start(rsp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<rect
|
||||
ry="0"
|
||||
|
|
@ -2318,15 +2320,6 @@
|
|||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(1739.0986,17188.625)"
|
||||
id="g3188-6">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3305.5364"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
<g
|
||||
id="g3107-5"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
|
@ -2359,6 +2352,15 @@
|
|||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-1">Root</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3147.9268"
|
||||
y="13240.524"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
|
|
@ -2387,13 +2389,13 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5392.3345"
|
||||
y="15407.104"
|
||||
x="5263.1094"
|
||||
y="15411.646"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6-7"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
id="text202-92"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
|
|
@ -2434,13 +2436,13 @@
|
|||
id="tspan3104-6-5-6-0-94">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7536.4883"
|
||||
y="17640.934"
|
||||
x="7417.4053"
|
||||
y="17655.502"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-9"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
id="text202-759"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-2353.8462,17224.992)"
|
||||
|
|
@ -2469,13 +2471,13 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5378.4146"
|
||||
y="15436.927"
|
||||
x="5246.1548"
|
||||
y="15411.648"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
id="text202-87"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-863.02613,17188.625)"
|
||||
|
|
@ -2554,13 +2556,13 @@
|
|||
id="tspan3104-6-5-6-0-92-6">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7520.1294"
|
||||
y="17673.639"
|
||||
x="7433.8257"
|
||||
y="17682.098"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-35"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
id="text202-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-7528.5085,17188.625)"
|
||||
|
|
@ -2601,13 +2603,13 @@
|
|||
id="tspan3104-6-5-6-0-1-8">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7521.4663"
|
||||
y="17666.062"
|
||||
x="7415.4404"
|
||||
y="17682.098"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-75-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
id="text202-0"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:13.29812813px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||
|
|
@ -2641,15 +2643,6 @@
|
|||
id="path3414-8-3-6-4"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="6659.5469"
|
||||
y="34833.551"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-62"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gpnum = rsp->gpnum</text>
|
||||
<path
|
||||
sodipodi:nodetypes="ccc"
|
||||
inkscape:connector-curvature="0"
|
||||
|
|
@ -3844,7 +3837,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6-6-5"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gp_seq</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5035.4155"
|
||||
|
|
@ -4284,15 +4277,6 @@
|
|||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(1874.038,53203.538)"
|
||||
id="g3188-7">
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3199.1516"
|
||||
y="13255.592"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-82"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;font-family:Courier">->completed = ->gpnum</text>
|
||||
<g
|
||||
id="g3107-53"
|
||||
transform="translate(947.90548,11584.029)">
|
||||
|
|
@ -4325,6 +4309,17 @@
|
|||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-19">Root</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="3175.896"
|
||||
y="13240.11"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<rect
|
||||
ry="0"
|
||||
|
|
@ -4371,13 +4366,15 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5324.5371"
|
||||
y="15414.598"
|
||||
x="5264.4829"
|
||||
y="15411.231"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-753"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-7"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-5">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
|
|
@ -4412,30 +4409,12 @@
|
|||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-6-0-4">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="10084.225"
|
||||
y="70903.312"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-9-0"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
<path
|
||||
sodipodi:nodetypes="ccc"
|
||||
inkscape:connector-curvature="0"
|
||||
id="path3134-9-0-3-9"
|
||||
d="m 6315.6122,72629.054 -20.9533,8108.684 1648.968,0"
|
||||
style="fill:none;stroke:#969696;stroke-width:53.19251251;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:4;stroke-opacity:1;stroke-dasharray:none;marker-end:url(#Arrow1Send)" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5092.4683"
|
||||
y="74111.672"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-60"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rsp->completed =</text>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
id="g3107-62-6"
|
||||
|
|
@ -4469,15 +4448,6 @@
|
|||
sodipodi:linespacing="125%"><tspan
|
||||
style="font-size:159.57754517px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;text-align:start;line-height:125%;writing-mode:lr-tb;text-anchor:start;font-family:Liberation Sans;-inkscape-font-specification:Liberation Sans"
|
||||
id="tspan3104-6-5-7-7">Root</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5092.4683"
|
||||
y="74325.906"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-60-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"> rnp->completed</text>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
transform="translate(1746.2528,60972.572)"
|
||||
|
|
@ -4736,13 +4706,15 @@
|
|||
</g>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5327.3057"
|
||||
y="15428.84"
|
||||
x="5274.1216"
|
||||
y="15411.231"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-6">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-728.08545,53203.538)"
|
||||
|
|
@ -4821,13 +4793,15 @@
|
|||
id="tspan3104-6-5-6-0-92-5">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7486.4907"
|
||||
y="17670.119"
|
||||
x="7435.1987"
|
||||
y="17708.281"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-9"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-1">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<g
|
||||
transform="translate(-7393.5687,53203.538)"
|
||||
|
|
@ -4868,13 +4842,15 @@
|
|||
id="tspan3104-6-5-6-0-1-5">Leaf</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="7474.1382"
|
||||
y="17688.926"
|
||||
x="7416.8125"
|
||||
y="17708.281"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-5-1"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
id="text202-36-35"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-62">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
</g>
|
||||
<path
|
||||
style="fill:none;stroke:#000000;stroke-width:13.29812813px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1;marker-end:url(#Arrow2Lend)"
|
||||
|
|
@ -4908,15 +4884,6 @@
|
|||
id="path3414-8-3-6-67"
|
||||
inkscape:connector-curvature="0"
|
||||
sodipodi:nodetypes="cc" />
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="6742.6001"
|
||||
y="70882.617"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->completed = ->gpnum</text>
|
||||
<g
|
||||
style="fill:none;stroke-width:0.025in"
|
||||
id="g4504-3-9-6"
|
||||
|
|
@ -5131,5 +5098,47 @@
|
|||
font-size="192"
|
||||
id="text202-7-9-6-6-7"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_do_batch()</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="6698.9019"
|
||||
y="70885.211"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-2"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-7">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="10023.457"
|
||||
y="70885.234"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-0"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-9">rcu_seq_end(&rnp->gp_seq)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5023.3389"
|
||||
y="74209.773"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-36-36"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier"><tspan
|
||||
style="font-size:172.87567139px"
|
||||
id="tspan3166-0">rcu_seq_end(&rsp->gp_seq)</tspan></text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="6562.5884"
|
||||
y="34870.727"
|
||||
font-style="normal"
|
||||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-3"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">->gp_seq = rsp->gp_seq</text>
|
||||
</g>
|
||||
</svg>
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 208 KiB After Width: | Height: | Size: 209 KiB |
|
|
@ -300,13 +300,13 @@
|
|||
inkscape:window-height="1144"
|
||||
id="namedview208"
|
||||
showgrid="true"
|
||||
inkscape:zoom="0.70710678"
|
||||
inkscape:cx="616.47598"
|
||||
inkscape:cy="595.41964"
|
||||
inkscape:window-x="813"
|
||||
inkscape:zoom="0.96484375"
|
||||
inkscape:cx="507.0191"
|
||||
inkscape:cy="885.62207"
|
||||
inkscape:window-x="47"
|
||||
inkscape:window-y="28"
|
||||
inkscape:window-maximized="0"
|
||||
inkscape:current-layer="g4405"
|
||||
inkscape:current-layer="g3115"
|
||||
fit-margin-top="5"
|
||||
fit-margin-right="5"
|
||||
fit-margin-left="5"
|
||||
|
|
@ -710,7 +710,7 @@
|
|||
font-weight="bold"
|
||||
font-size="192"
|
||||
id="text202-6-6"
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gpnum</text>
|
||||
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rdp->gp_seq</text>
|
||||
<text
|
||||
xml:space="preserve"
|
||||
x="5035.4155"
|
||||
|
|
|
|||
|
Before Width: | Height: | Size: 43 KiB After Width: | Height: | Size: 43 KiB |
|
|
@ -172,7 +172,7 @@ it will print a message similar to the following:
|
|||
INFO: rcu_sched detected stalls on CPUs/tasks:
|
||||
2-...: (3 GPs behind) idle=06c/0/0 softirq=1453/1455 fqs=0
|
||||
16-...: (0 ticks this GP) idle=81c/0/0 softirq=764/764 fqs=0
|
||||
(detected by 32, t=2603 jiffies, g=7073, c=7072, q=625)
|
||||
(detected by 32, t=2603 jiffies, g=7075, q=625)
|
||||
|
||||
This message indicates that CPU 32 detected that CPUs 2 and 16 were both
|
||||
causing stalls, and that the stall was affecting RCU-sched. This message
|
||||
|
|
@ -215,11 +215,10 @@ CPU since the last time that this CPU noted the beginning of a grace
|
|||
period.
|
||||
|
||||
The "detected by" line indicates which CPU detected the stall (in this
|
||||
case, CPU 32), how many jiffies have elapsed since the start of the
|
||||
grace period (in this case 2603), the number of the last grace period
|
||||
to start and to complete (7073 and 7072, respectively), and an estimate
|
||||
of the total number of RCU callbacks queued across all CPUs (625 in
|
||||
this case).
|
||||
case, CPU 32), how many jiffies have elapsed since the start of the grace
|
||||
period (in this case 2603), the grace-period sequence number (7075), and
|
||||
an estimate of the total number of RCU callbacks queued across all CPUs
|
||||
(625 in this case).
|
||||
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed
|
||||
for each CPU:
|
||||
|
|
@ -266,15 +265,16 @@ If the relevant grace-period kthread has been unable to run prior to
|
|||
the stall warning, as was the case in the "All QSes seen" line above,
|
||||
the following additional line is printed:
|
||||
|
||||
kthread starved for 23807 jiffies! g7073 c7072 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1
|
||||
kthread starved for 23807 jiffies! g7075 f0x0 RCU_GP_WAIT_FQS(3) ->state=0x1 ->cpu=5
|
||||
|
||||
Starving the grace-period kthreads of CPU time can of course result
|
||||
in RCU CPU stall warnings even when all CPUs and tasks have passed
|
||||
through the required quiescent states. The "g" and "c" numbers flag the
|
||||
number of the last grace period started and completed, respectively,
|
||||
the "f" precedes the ->gp_flags command to the grace-period kthread,
|
||||
the "RCU_GP_WAIT_FQS" indicates that the kthread is waiting for a short
|
||||
timeout, and the "state" precedes value of the task_struct ->state field.
|
||||
through the required quiescent states. The "g" number shows the current
|
||||
grace-period sequence number, the "f" precedes the ->gp_flags command
|
||||
to the grace-period kthread, the "RCU_GP_WAIT_FQS" indicates that the
|
||||
kthread is waiting for a short timeout, the "state" precedes value of the
|
||||
task_struct ->state field, and the "cpu" indicates that the grace-period
|
||||
kthread last ran on CPU 5.
|
||||
|
||||
|
||||
Multiple Warnings From One Stall
|
||||
|
|
|
|||
|
|
@ -588,6 +588,7 @@ It is extremely simple:
|
|||
void synchronize_rcu(void)
|
||||
{
|
||||
write_lock(&rcu_gp_mutex);
|
||||
smp_mb__after_spinlock();
|
||||
write_unlock(&rcu_gp_mutex);
|
||||
}
|
||||
|
||||
|
|
@ -609,12 +610,15 @@ don't forget about them when submitting patches making use of RCU!]
|
|||
|
||||
The rcu_read_lock() and rcu_read_unlock() primitive read-acquire
|
||||
and release a global reader-writer lock. The synchronize_rcu()
|
||||
primitive write-acquires this same lock, then immediately releases
|
||||
it. This means that once synchronize_rcu() exits, all RCU read-side
|
||||
critical sections that were in progress before synchronize_rcu() was
|
||||
called are guaranteed to have completed -- there is no way that
|
||||
synchronize_rcu() would have been able to write-acquire the lock
|
||||
otherwise.
|
||||
primitive write-acquires this same lock, then releases it. This means
|
||||
that once synchronize_rcu() exits, all RCU read-side critical sections
|
||||
that were in progress before synchronize_rcu() was called are guaranteed
|
||||
to have completed -- there is no way that synchronize_rcu() would have
|
||||
been able to write-acquire the lock otherwise. The smp_mb__after_spinlock()
|
||||
promotes synchronize_rcu() to a full memory barrier in compliance with
|
||||
the "Memory-Barrier Guarantees" listed in:
|
||||
|
||||
Documentation/RCU/Design/Requirements/Requirements.html.
|
||||
|
||||
It is possible to nest rcu_read_lock(), since reader-writer locks may
|
||||
be recursively acquired. Note also that rcu_read_lock() is immune
|
||||
|
|
@ -816,11 +820,13 @@ RCU list traversal:
|
|||
list_next_rcu
|
||||
list_for_each_entry_rcu
|
||||
list_for_each_entry_continue_rcu
|
||||
list_for_each_entry_from_rcu
|
||||
hlist_first_rcu
|
||||
hlist_next_rcu
|
||||
hlist_pprev_rcu
|
||||
hlist_for_each_entry_rcu
|
||||
hlist_for_each_entry_rcu_bh
|
||||
hlist_for_each_entry_from_rcu
|
||||
hlist_for_each_entry_continue_rcu
|
||||
hlist_for_each_entry_continue_rcu_bh
|
||||
hlist_nulls_first_rcu
|
||||
|
|
|
|||
|
|
@ -0,0 +1,89 @@
|
|||
Copyright (C) 2018 Intel Corporation
|
||||
Author: Sakari Ailus <sakari.ailus@linux.intel.com>
|
||||
|
||||
|
||||
Referencing hierarchical data nodes
|
||||
-----------------------------------
|
||||
|
||||
ACPI in general allows referring to device objects in the tree only.
|
||||
Hierarchical data extension nodes may not be referred to directly, hence this
|
||||
document defines a scheme to implement such references.
|
||||
|
||||
A reference consist of the device object name followed by one or more
|
||||
hierarchical data extension [1] keys. Specifically, the hierarchical data
|
||||
extension node which is referred to by the key shall lie directly under the
|
||||
parent object i.e. either the device object or another hierarchical data
|
||||
extension node.
|
||||
|
||||
The keys in the hierarchical data nodes shall consist of the name of the node,
|
||||
"@" character and the number of the node in hexadecimal notation (without pre-
|
||||
or postfixes). The same ACPI object shall include the _DSD property extension
|
||||
with a property "reg" that shall have the same numerical value as the number of
|
||||
the node.
|
||||
|
||||
In case a hierarchical data extensions node has no numerical value, then the
|
||||
"reg" property shall be omitted from the ACPI object's _DSD properties and the
|
||||
"@" character and the number shall be omitted from the hierarchical data
|
||||
extension key.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
In the ASL snippet below, the "reference" _DSD property [2] contains a
|
||||
device object reference to DEV0 and under that device object, a
|
||||
hierarchical data extension key "node@1" referring to the NOD1 object
|
||||
and lastly, a hierarchical data extension key "anothernode" referring to
|
||||
the ANOD object which is also the final target node of the reference.
|
||||
|
||||
Device (DEV0)
|
||||
{
|
||||
Name (_DSD, Package () {
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "node@0", NOD0 },
|
||||
Package () { "node@1", NOD1 },
|
||||
}
|
||||
})
|
||||
Name (NOD0, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "random-property", 3 },
|
||||
}
|
||||
})
|
||||
Name (NOD1, Package() {
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "anothernode", ANOD },
|
||||
}
|
||||
})
|
||||
Name (ANOD, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "random-property", 0 },
|
||||
}
|
||||
})
|
||||
}
|
||||
|
||||
Device (DEV1)
|
||||
{
|
||||
Name (_DSD, Package () {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "reference", ^DEV0, "node@1", "anothernode" },
|
||||
}
|
||||
})
|
||||
}
|
||||
|
||||
Please also see a graph example in graph.txt .
|
||||
|
||||
References
|
||||
----------
|
||||
|
||||
[1] Hierarchical Data Extension UUID For _DSD.
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
|
||||
referenced 2018-07-17.
|
||||
|
||||
[2] Device Properties UUID For _DSD.
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf>,
|
||||
referenced 2016-10-04.
|
||||
|
|
@ -36,29 +36,41 @@ The port and endpoint concepts are very similar to those in Devicetree
|
|||
[3]. A port represents an interface in a device, and an endpoint
|
||||
represents a connection to that interface.
|
||||
|
||||
All port nodes are located under the device's "_DSD" node in the
|
||||
hierarchical data extension tree. The property extension related to
|
||||
each port node must contain the key "port" and an integer value which
|
||||
is the number of the port. The object it refers to should be called "PRTX",
|
||||
where "X" is the number of the port.
|
||||
All port nodes are located under the device's "_DSD" node in the hierarchical
|
||||
data extension tree. The data extension related to each port node must begin
|
||||
with "port" and must be followed by the "@" character and the number of the port
|
||||
as its key. The target object it refers to should be called "PRTX", where "X" is
|
||||
the number of the port. An example of such a package would be:
|
||||
|
||||
Further on, endpoints are located under the individual port nodes. The
|
||||
first hierarchical data extension package list entry of the endpoint
|
||||
nodes must begin with "endpoint" and must be followed by the number
|
||||
of the endpoint. The object it refers to should be called "EPXY", where
|
||||
"X" is the number of the port and "Y" is the number of the endpoint.
|
||||
Package() { "port@4", PRT4 }
|
||||
|
||||
Each port node contains a property extension key "port", the value of
|
||||
which is the number of the port node. The each endpoint is similarly numbered
|
||||
with a property extension key "endpoint". Port numbers must be unique within a
|
||||
device and endpoint numbers must be unique within a port.
|
||||
Further on, endpoints are located under the port nodes. The hierarchical
|
||||
data extension key of the endpoint nodes must begin with
|
||||
"endpoint" and must be followed by the "@" character and the number of the
|
||||
endpoint. The object it refers to should be called "EPXY", where "X" is the
|
||||
number of the port and "Y" is the number of the endpoint. An example of such a
|
||||
package would be:
|
||||
|
||||
Package() { "endpoint@0", EP40 }
|
||||
|
||||
Each port node contains a property extension key "port", the value of which is
|
||||
the number of the port. Each endpoint is similarly numbered with a property
|
||||
extension key "reg", the value of which is the number of the endpoint. Port
|
||||
numbers must be unique within a device and endpoint numbers must be unique
|
||||
within a port. If a device object may only has a single port, then the number
|
||||
of that port shall be zero. Similarly, if a port may only have a single
|
||||
endpoint, the number of that endpoint shall be zero.
|
||||
|
||||
The endpoint reference uses property extension with "remote-endpoint" property
|
||||
name followed by a reference in the same package. Such references consist of the
|
||||
the remote device reference, number of the port in the device and finally the
|
||||
number of the endpoint in that port. Individual references thus appear as:
|
||||
the remote device reference, the first package entry of the port data extension
|
||||
reference under the device and finally the first package entry of the endpoint
|
||||
data extension reference under the port. Individual references thus appear as:
|
||||
|
||||
Package() { device, port_number, endpoint_number }
|
||||
Package() { device, "port@X", "endpoint@Y" }
|
||||
|
||||
In the above example, "X" is the number of the port and "Y" is the number of the
|
||||
endpoint.
|
||||
|
||||
The references to endpoints must be always done both ways, to the
|
||||
remote endpoint and back from the referred remote endpoint node.
|
||||
|
|
@ -76,24 +88,24 @@ A simple example of this is show below:
|
|||
},
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "port0", "PRT0" },
|
||||
Package () { "port@0", PRT0 },
|
||||
}
|
||||
})
|
||||
Name (PRT0, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "port", 0 },
|
||||
Package () { "reg", 0 },
|
||||
},
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "endpoint0", "EP00" },
|
||||
Package () { "endpoint@0", EP00 },
|
||||
}
|
||||
})
|
||||
Name (EP00, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "endpoint", 0 },
|
||||
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, 4, 0 } },
|
||||
Package () { "reg", 0 },
|
||||
Package () { "remote-endpoint", Package() { \_SB.PCI0.ISP, "port@4", "endpoint@0" } },
|
||||
}
|
||||
})
|
||||
}
|
||||
|
|
@ -106,26 +118,26 @@ A simple example of this is show below:
|
|||
Name (_DSD, Package () {
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "port4", "PRT4" },
|
||||
Package () { "port@4", PRT4 },
|
||||
}
|
||||
})
|
||||
|
||||
Name (PRT4, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "port", 4 }, /* CSI-2 port number */
|
||||
Package () { "reg", 4 }, /* CSI-2 port number */
|
||||
},
|
||||
ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
|
||||
Package () {
|
||||
Package () { "endpoint0", "EP40" },
|
||||
Package () { "endpoint@0", EP40 },
|
||||
}
|
||||
})
|
||||
|
||||
Name (EP40, Package() {
|
||||
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
|
||||
Package () {
|
||||
Package () { "endpoint", 0 },
|
||||
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, 0, 0 } },
|
||||
Package () { "reg", 0 },
|
||||
Package () { "remote-endpoint", Package () { \_SB.PCI0.I2C2.CAM0, "port@0", "endpoint@0" } },
|
||||
}
|
||||
})
|
||||
}
|
||||
|
|
@ -151,7 +163,7 @@ References
|
|||
referenced 2016-10-04.
|
||||
|
||||
[5] Hierarchical Data Extension UUID For _DSD.
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.pdf>,
|
||||
<URL:http://www.uefi.org/sites/default/files/resources/_DSD-hierarchical-data-extension-UUID-v1.1.pdf>,
|
||||
referenced 2016-10-04.
|
||||
|
||||
[6] Advanced Configuration and Power Interface Specification.
|
||||
|
|
|
|||
|
|
@ -1,3 +1,5 @@
|
|||
.. _readme:
|
||||
|
||||
Linux kernel release 4.x <http://kernel.org/>
|
||||
=============================================
|
||||
|
||||
|
|
|
|||
|
|
@ -51,6 +51,9 @@ v1 is available under Documentation/cgroup-v1/.
|
|||
5-3. IO
|
||||
5-3-1. IO Interface Files
|
||||
5-3-2. Writeback
|
||||
5-3-3. IO Latency
|
||||
5-3-3-1. How IO Latency Throttling Works
|
||||
5-3-3-2. IO Latency Interface Files
|
||||
5-4. PID
|
||||
5-4-1. PID Interface Files
|
||||
5-5. Device
|
||||
|
|
@ -1069,6 +1072,24 @@ PAGE_SIZE multiple when read back.
|
|||
high limit is used and monitored properly, this limit's
|
||||
utility is limited to providing the final safety net.
|
||||
|
||||
memory.oom.group
|
||||
A read-write single value file which exists on non-root
|
||||
cgroups. The default value is "0".
|
||||
|
||||
Determines whether the cgroup should be treated as
|
||||
an indivisible workload by the OOM killer. If set,
|
||||
all tasks belonging to the cgroup or to its descendants
|
||||
(if the memory cgroup is not a leaf cgroup) are killed
|
||||
together or not at all. This can be used to avoid
|
||||
partial kills to guarantee workload integrity.
|
||||
|
||||
Tasks with the OOM protection (oom_score_adj set to -1000)
|
||||
are treated as an exception and are never killed.
|
||||
|
||||
If the OOM killer is invoked in a cgroup, it's not going
|
||||
to kill any tasks outside of this cgroup, regardless
|
||||
memory.oom.group values of ancestor cgroups.
|
||||
|
||||
memory.events
|
||||
A read-only flat-keyed file which exists on non-root cgroups.
|
||||
The following entries are defined. Unless specified
|
||||
|
|
@ -1314,17 +1335,19 @@ IO Interface Files
|
|||
Lines are keyed by $MAJ:$MIN device numbers and not ordered.
|
||||
The following nested keys are defined.
|
||||
|
||||
====== ===================
|
||||
====== =====================
|
||||
rbytes Bytes read
|
||||
wbytes Bytes written
|
||||
rios Number of read IOs
|
||||
wios Number of write IOs
|
||||
====== ===================
|
||||
dbytes Bytes discarded
|
||||
dios Number of discard IOs
|
||||
====== =====================
|
||||
|
||||
An example read output follows:
|
||||
|
||||
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353
|
||||
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252
|
||||
8:16 rbytes=1459200 wbytes=314773504 rios=192 wios=353 dbytes=0 dios=0
|
||||
8:0 rbytes=90430464 wbytes=299008000 rios=8950 wios=1252 dbytes=50331648 dios=3021
|
||||
|
||||
io.weight
|
||||
A read-write flat-keyed file which exists on non-root cgroups.
|
||||
|
|
@ -1446,6 +1469,85 @@ writeback as follows.
|
|||
vm.dirty[_background]_ratio.
|
||||
|
||||
|
||||
IO Latency
|
||||
~~~~~~~~~~
|
||||
|
||||
This is a cgroup v2 controller for IO workload protection. You provide a group
|
||||
with a latency target, and if the average latency exceeds that target the
|
||||
controller will throttle any peers that have a lower latency target than the
|
||||
protected workload.
|
||||
|
||||
The limits are only applied at the peer level in the hierarchy. This means that
|
||||
in the diagram below, only groups A, B, and C will influence each other, and
|
||||
groups D and F will influence each other. Group G will influence nobody.
|
||||
|
||||
[root]
|
||||
/ | \
|
||||
A B C
|
||||
/ \ |
|
||||
D F G
|
||||
|
||||
|
||||
So the ideal way to configure this is to set io.latency in groups A, B, and C.
|
||||
Generally you do not want to set a value lower than the latency your device
|
||||
supports. Experiment to find the value that works best for your workload.
|
||||
Start at higher than the expected latency for your device and watch the
|
||||
avg_lat value in io.stat for your workload group to get an idea of the
|
||||
latency you see during normal operation. Use the avg_lat value as a basis for
|
||||
your real setting, setting at 10-15% higher than the value in io.stat.
|
||||
|
||||
How IO Latency Throttling Works
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
io.latency is work conserving; so as long as everybody is meeting their latency
|
||||
target the controller doesn't do anything. Once a group starts missing its
|
||||
target it begins throttling any peer group that has a higher target than itself.
|
||||
This throttling takes 2 forms:
|
||||
|
||||
- Queue depth throttling. This is the number of outstanding IO's a group is
|
||||
allowed to have. We will clamp down relatively quickly, starting at no limit
|
||||
and going all the way down to 1 IO at a time.
|
||||
|
||||
- Artificial delay induction. There are certain types of IO that cannot be
|
||||
throttled without possibly adversely affecting higher priority groups. This
|
||||
includes swapping and metadata IO. These types of IO are allowed to occur
|
||||
normally, however they are "charged" to the originating group. If the
|
||||
originating group is being throttled you will see the use_delay and delay
|
||||
fields in io.stat increase. The delay value is how many microseconds that are
|
||||
being added to any process that runs in this group. Because this number can
|
||||
grow quite large if there is a lot of swapping or metadata IO occurring we
|
||||
limit the individual delay events to 1 second at a time.
|
||||
|
||||
Once the victimized group starts meeting its latency target again it will start
|
||||
unthrottling any peer groups that were throttled previously. If the victimized
|
||||
group simply stops doing IO the global counter will unthrottle appropriately.
|
||||
|
||||
IO Latency Interface Files
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
io.latency
|
||||
This takes a similar format as the other controllers.
|
||||
|
||||
"MAJOR:MINOR target=<target time in microseconds"
|
||||
|
||||
io.stat
|
||||
If the controller is enabled you will see extra stats in io.stat in
|
||||
addition to the normal ones.
|
||||
|
||||
depth
|
||||
This is the current queue depth for the group.
|
||||
|
||||
avg_lat
|
||||
This is an exponential moving average with a decay rate of 1/exp
|
||||
bound by the sampling interval. The decay rate interval can be
|
||||
calculated by multiplying the win value in io.stat by the
|
||||
corresponding number of samples based on the win value.
|
||||
|
||||
win
|
||||
The sampling window size in milliseconds. This is the minimum
|
||||
duration of time between evaluation events. Windows only elapse
|
||||
with IO activity. Idle periods extend the most recent window.
|
||||
|
||||
PID
|
||||
---
|
||||
|
||||
|
|
|
|||
|
|
@ -173,14 +173,18 @@
|
|||
they are redirected through the parport multiplex layer.
|
||||
|
||||
7 char Virtual console capture devices
|
||||
0 = /dev/vcs Current vc text contents
|
||||
1 = /dev/vcs1 tty1 text contents
|
||||
0 = /dev/vcs Current vc text (glyph) contents
|
||||
1 = /dev/vcs1 tty1 text (glyph) contents
|
||||
...
|
||||
63 = /dev/vcs63 tty63 text contents
|
||||
128 = /dev/vcsa Current vc text/attribute contents
|
||||
129 = /dev/vcsa1 tty1 text/attribute contents
|
||||
63 = /dev/vcs63 tty63 text (glyph) contents
|
||||
64 = /dev/vcsu Current vc text (unicode) contents
|
||||
65 = /dev/vcsu1 tty1 text (unicode) contents
|
||||
...
|
||||
191 = /dev/vcsa63 tty63 text/attribute contents
|
||||
127 = /dev/vcsu63 tty63 text (unicode) contents
|
||||
128 = /dev/vcsa Current vc text/attribute (glyph) contents
|
||||
129 = /dev/vcsa1 tty1 text/attribute (glyph) contents
|
||||
...
|
||||
191 = /dev/vcsa63 tty63 text/attribute (glyph) contents
|
||||
|
||||
NOTE: These devices permit both read and write access.
|
||||
|
||||
|
|
|
|||
|
|
@ -17,6 +17,15 @@ etc.
|
|||
kernel-parameters
|
||||
devices
|
||||
|
||||
This section describes CPU vulnerabilities and provides an overview of the
|
||||
possible mitigations along with guidance for selecting mitigations if they
|
||||
are configurable at compile, boot or run time.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
l1tf
|
||||
|
||||
Here is a set of documents aimed at users who are trying to track down
|
||||
problems and bugs in particular.
|
||||
|
||||
|
|
|
|||
|
|
@ -748,6 +748,14 @@
|
|||
|
||||
debug [KNL] Enable kernel debugging (events log level).
|
||||
|
||||
debug_boot_weak_hash
|
||||
[KNL] Enable printing [hashed] pointers early in the
|
||||
boot sequence. If enabled, we use a weak hash instead
|
||||
of siphash to hash pointers. Use this option if you are
|
||||
seeing instances of '(___ptrval___)') and need to see a
|
||||
value (hashed pointer) instead. Cryptographically
|
||||
insecure, please do not use on production kernels.
|
||||
|
||||
debug_locks_verbose=
|
||||
[KNL] verbose self-tests
|
||||
Format=<0|1>
|
||||
|
|
@ -804,6 +812,15 @@
|
|||
Defaults to the default architecture's huge page size
|
||||
if not specified.
|
||||
|
||||
deferred_probe_timeout=
|
||||
[KNL] Debugging option to set a timeout in seconds for
|
||||
deferred probe to give up waiting on dependencies to
|
||||
probe. Only specific dependencies (subsystems or
|
||||
drivers) that have opted in will be ignored. A timeout of 0
|
||||
will timeout at the end of initcalls. This option will also
|
||||
dump out devices still on the deferred probe list after
|
||||
retrying.
|
||||
|
||||
dhash_entries= [KNL]
|
||||
Set number of hash buckets for dentry cache.
|
||||
|
||||
|
|
@ -816,6 +833,17 @@
|
|||
disable= [IPV6]
|
||||
See Documentation/networking/ipv6.txt.
|
||||
|
||||
hardened_usercopy=
|
||||
[KNL] Under CONFIG_HARDENED_USERCOPY, whether
|
||||
hardening is enabled for this boot. Hardened
|
||||
usercopy checking is used to protect the kernel
|
||||
from reading or writing beyond known memory
|
||||
allocation boundaries as a proactive defense
|
||||
against bounds-checking flaws in the kernel's
|
||||
copy_to_user()/copy_from_user() interface.
|
||||
on Perform hardened usercopy checks (default).
|
||||
off Disable hardened usercopy checks.
|
||||
|
||||
disable_radix [PPC]
|
||||
Disable RADIX MMU mode on POWER9
|
||||
|
||||
|
|
@ -1716,7 +1744,8 @@
|
|||
merge
|
||||
nomerge
|
||||
soft
|
||||
pt [x86, IA-64]
|
||||
pt [x86]
|
||||
nopt [x86]
|
||||
nobypass [PPC/POWERNV]
|
||||
Disable IOMMU bypass, using IOMMU for PCI devices.
|
||||
|
||||
|
|
@ -1967,10 +1996,84 @@
|
|||
(virtualized real and unpaged mode) on capable
|
||||
Intel chips. Default is 1 (enabled)
|
||||
|
||||
kvm-intel.vmentry_l1d_flush=[KVM,Intel] Mitigation for L1 Terminal Fault
|
||||
CVE-2018-3620.
|
||||
|
||||
Valid arguments: never, cond, always
|
||||
|
||||
always: L1D cache flush on every VMENTER.
|
||||
cond: Flush L1D on VMENTER only when the code between
|
||||
VMEXIT and VMENTER can leak host memory.
|
||||
never: Disables the mitigation
|
||||
|
||||
Default is cond (do L1 cache flush in specific instances)
|
||||
|
||||
kvm-intel.vpid= [KVM,Intel] Disable Virtual Processor Identification
|
||||
feature (tagged TLBs) on capable Intel chips.
|
||||
Default is 1 (enabled)
|
||||
|
||||
l1tf= [X86] Control mitigation of the L1TF vulnerability on
|
||||
affected CPUs
|
||||
|
||||
The kernel PTE inversion protection is unconditionally
|
||||
enabled and cannot be disabled.
|
||||
|
||||
full
|
||||
Provides all available mitigations for the
|
||||
L1TF vulnerability. Disables SMT and
|
||||
enables all mitigations in the
|
||||
hypervisors, i.e. unconditional L1D flush.
|
||||
|
||||
SMT control and L1D flush control via the
|
||||
sysfs interface is still possible after
|
||||
boot. Hypervisors will issue a warning
|
||||
when the first VM is started in a
|
||||
potentially insecure configuration,
|
||||
i.e. SMT enabled or L1D flush disabled.
|
||||
|
||||
full,force
|
||||
Same as 'full', but disables SMT and L1D
|
||||
flush runtime control. Implies the
|
||||
'nosmt=force' command line option.
|
||||
(i.e. sysfs control of SMT is disabled.)
|
||||
|
||||
flush
|
||||
Leaves SMT enabled and enables the default
|
||||
hypervisor mitigation, i.e. conditional
|
||||
L1D flush.
|
||||
|
||||
SMT control and L1D flush control via the
|
||||
sysfs interface is still possible after
|
||||
boot. Hypervisors will issue a warning
|
||||
when the first VM is started in a
|
||||
potentially insecure configuration,
|
||||
i.e. SMT enabled or L1D flush disabled.
|
||||
|
||||
flush,nosmt
|
||||
|
||||
Disables SMT and enables the default
|
||||
hypervisor mitigation.
|
||||
|
||||
SMT control and L1D flush control via the
|
||||
sysfs interface is still possible after
|
||||
boot. Hypervisors will issue a warning
|
||||
when the first VM is started in a
|
||||
potentially insecure configuration,
|
||||
i.e. SMT enabled or L1D flush disabled.
|
||||
|
||||
flush,nowarn
|
||||
Same as 'flush', but hypervisors will not
|
||||
warn when a VM is started in a potentially
|
||||
insecure configuration.
|
||||
|
||||
off
|
||||
Disables hypervisor mitigations and doesn't
|
||||
emit any warnings.
|
||||
|
||||
Default is 'flush'.
|
||||
|
||||
For details see: Documentation/admin-guide/l1tf.rst
|
||||
|
||||
l2cr= [PPC]
|
||||
|
||||
l3cr= [PPC]
|
||||
|
|
@ -2687,6 +2790,14 @@
|
|||
nosmt [KNL,S390] Disable symmetric multithreading (SMT).
|
||||
Equivalent to smt=1.
|
||||
|
||||
[KNL,x86] Disable symmetric multithreading (SMT).
|
||||
nosmt=force: Force disable SMT, cannot be undone
|
||||
via the sysfs control file.
|
||||
|
||||
nospectre_v1 [PPC] Disable mitigations for Spectre Variant 1 (bounds
|
||||
check bypass). With this option data leaks are possible
|
||||
in the system.
|
||||
|
||||
nospectre_v2 [X86] Disable all mitigations for the Spectre variant 2
|
||||
(indirect branch prediction) vulnerability. System may
|
||||
allow data leaks with this option, which is equivalent
|
||||
|
|
@ -2835,8 +2946,6 @@
|
|||
|
||||
nosync [HW,M68K] Disables sync negotiation for all devices.
|
||||
|
||||
notsc [BUGS=X86-32] Disable Time Stamp Counter
|
||||
|
||||
nowatchdog [KNL] Disable both lockup detectors, i.e.
|
||||
soft-lockup and NMI watchdog (hard-lockup).
|
||||
|
||||
|
|
@ -2933,8 +3042,9 @@
|
|||
on: enable the feature
|
||||
|
||||
page_poison= [KNL] Boot-time parameter changing the state of
|
||||
poisoning on the buddy allocator.
|
||||
off: turn off poisoning
|
||||
poisoning on the buddy allocator, available with
|
||||
CONFIG_PAGE_POISONING=y.
|
||||
off: turn off poisoning (default)
|
||||
on: turn on poisoning
|
||||
|
||||
panic= [KNL] Kernel behaviour on panic: delay <timeout>
|
||||
|
|
@ -2994,8 +3104,31 @@
|
|||
See header of drivers/block/paride/pcd.c.
|
||||
See also Documentation/blockdev/paride.txt.
|
||||
|
||||
pci=option[,option...] [PCI] various PCI subsystem options:
|
||||
earlydump [X86] dump PCI config space before the kernel
|
||||
pci=option[,option...] [PCI] various PCI subsystem options.
|
||||
|
||||
Some options herein operate on a specific device
|
||||
or a set of devices (<pci_dev>). These are
|
||||
specified in one of the following formats:
|
||||
|
||||
[<domain>:]<bus>:<dev>.<func>[/<dev>.<func>]*
|
||||
pci:<vendor>:<device>[:<subvendor>:<subdevice>]
|
||||
|
||||
Note: the first format specifies a PCI
|
||||
bus/device/function address which may change
|
||||
if new hardware is inserted, if motherboard
|
||||
firmware changes, or due to changes caused
|
||||
by other kernel parameters. If the
|
||||
domain is left unspecified, it is
|
||||
taken to be zero. Optionally, a path
|
||||
to a device through multiple device/function
|
||||
addresses can be specified after the base
|
||||
address (this is more robust against
|
||||
renumbering issues). The second format
|
||||
selects devices using IDs from the
|
||||
configuration space which may match multiple
|
||||
devices in the system.
|
||||
|
||||
earlydump dump PCI config space before the kernel
|
||||
changes anything
|
||||
off [X86] don't probe for the PCI bus
|
||||
bios [X86-32] force use of PCI BIOS, don't access
|
||||
|
|
@ -3123,11 +3256,10 @@
|
|||
window. The default value is 64 megabytes.
|
||||
resource_alignment=
|
||||
Format:
|
||||
[<order of align>@][<domain>:]<bus>:<slot>.<func>[; ...]
|
||||
[<order of align>@]pci:<vendor>:<device>\
|
||||
[:<subvendor>:<subdevice>][; ...]
|
||||
[<order of align>@]<pci_dev>[; ...]
|
||||
Specifies alignment and device to reassign
|
||||
aligned memory resources.
|
||||
aligned memory resources. How to
|
||||
specify the device is described above.
|
||||
If <order of align> is not specified,
|
||||
PAGE_SIZE is used as alignment.
|
||||
PCI-PCI bridge can be specified, if resource
|
||||
|
|
@ -3170,6 +3302,15 @@
|
|||
Adding the window is slightly risky (it may
|
||||
conflict with unreported devices), so this
|
||||
taints the kernel.
|
||||
disable_acs_redir=<pci_dev>[; ...]
|
||||
Specify one or more PCI devices (in the format
|
||||
specified above) separated by semicolons.
|
||||
Each device specified will have the PCI ACS
|
||||
redirect capabilities forced off which will
|
||||
allow P2P traffic between devices through
|
||||
bridges without forcing it upstream. Note:
|
||||
this removes isolation between devices and
|
||||
may put more devices in an IOMMU group.
|
||||
|
||||
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
||||
Management.
|
||||
|
|
@ -3632,8 +3773,8 @@
|
|||
Set time (s) after boot for CPU-hotplug testing.
|
||||
|
||||
rcutorture.onoff_interval= [KNL]
|
||||
Set time (s) between CPU-hotplug operations, or
|
||||
zero to disable CPU-hotplug testing.
|
||||
Set time (jiffies) between CPU-hotplug operations,
|
||||
or zero to disable CPU-hotplug testing.
|
||||
|
||||
rcutorture.shuffle_interval= [KNL]
|
||||
Set task-shuffle interval (s). Shuffling tasks
|
||||
|
|
@ -4060,6 +4201,8 @@
|
|||
This parameter controls whether the Speculative Store
|
||||
Bypass optimization is used.
|
||||
|
||||
On x86 the options are:
|
||||
|
||||
on - Unconditionally disable Speculative Store Bypass
|
||||
off - Unconditionally enable Speculative Store Bypass
|
||||
auto - Kernel detects whether the CPU model contains an
|
||||
|
|
@ -4075,12 +4218,20 @@
|
|||
seccomp - Same as "prctl" above, but all seccomp threads
|
||||
will disable SSB unless they explicitly opt out.
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spec_store_bypass_disable=auto.
|
||||
|
||||
Default mitigations:
|
||||
X86: If CONFIG_SECCOMP=y "seccomp", otherwise "prctl"
|
||||
|
||||
On powerpc the options are:
|
||||
|
||||
on,auto - On Power8 and Power9 insert a store-forwarding
|
||||
barrier on kernel entry and exit. On Power7
|
||||
perform a software flush on kernel entry and
|
||||
exit.
|
||||
off - No action.
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spec_store_bypass_disable=auto.
|
||||
|
||||
spia_io_base= [HW,MTD]
|
||||
spia_fio_base=
|
||||
spia_pedr=
|
||||
|
|
|
|||
|
|
@ -0,0 +1,610 @@
|
|||
L1TF - L1 Terminal Fault
|
||||
========================
|
||||
|
||||
L1 Terminal Fault is a hardware vulnerability which allows unprivileged
|
||||
speculative access to data which is available in the Level 1 Data Cache
|
||||
when the page table entry controlling the virtual address, which is used
|
||||
for the access, has the Present bit cleared or other reserved bits set.
|
||||
|
||||
Affected processors
|
||||
-------------------
|
||||
|
||||
This vulnerability affects a wide range of Intel processors. The
|
||||
vulnerability is not present on:
|
||||
|
||||
- Processors from AMD, Centaur and other non Intel vendors
|
||||
|
||||
- Older processor models, where the CPU family is < 6
|
||||
|
||||
- A range of Intel ATOM processors (Cedarview, Cloverview, Lincroft,
|
||||
Penwell, Pineview, Silvermont, Airmont, Merrifield)
|
||||
|
||||
- The Intel XEON PHI family
|
||||
|
||||
- Intel processors which have the ARCH_CAP_RDCL_NO bit set in the
|
||||
IA32_ARCH_CAPABILITIES MSR. If the bit is set the CPU is not affected
|
||||
by the Meltdown vulnerability either. These CPUs should become
|
||||
available by end of 2018.
|
||||
|
||||
Whether a processor is affected or not can be read out from the L1TF
|
||||
vulnerability file in sysfs. See :ref:`l1tf_sys_info`.
|
||||
|
||||
Related CVEs
|
||||
------------
|
||||
|
||||
The following CVE entries are related to the L1TF vulnerability:
|
||||
|
||||
============= ================= ==============================
|
||||
CVE-2018-3615 L1 Terminal Fault SGX related aspects
|
||||
CVE-2018-3620 L1 Terminal Fault OS, SMM related aspects
|
||||
CVE-2018-3646 L1 Terminal Fault Virtualization related aspects
|
||||
============= ================= ==============================
|
||||
|
||||
Problem
|
||||
-------
|
||||
|
||||
If an instruction accesses a virtual address for which the relevant page
|
||||
table entry (PTE) has the Present bit cleared or other reserved bits set,
|
||||
then speculative execution ignores the invalid PTE and loads the referenced
|
||||
data if it is present in the Level 1 Data Cache, as if the page referenced
|
||||
by the address bits in the PTE was still present and accessible.
|
||||
|
||||
While this is a purely speculative mechanism and the instruction will raise
|
||||
a page fault when it is retired eventually, the pure act of loading the
|
||||
data and making it available to other speculative instructions opens up the
|
||||
opportunity for side channel attacks to unprivileged malicious code,
|
||||
similar to the Meltdown attack.
|
||||
|
||||
While Meltdown breaks the user space to kernel space protection, L1TF
|
||||
allows to attack any physical memory address in the system and the attack
|
||||
works across all protection domains. It allows an attack of SGX and also
|
||||
works from inside virtual machines because the speculation bypasses the
|
||||
extended page table (EPT) protection mechanism.
|
||||
|
||||
|
||||
Attack scenarios
|
||||
----------------
|
||||
|
||||
1. Malicious user space
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Operating Systems store arbitrary information in the address bits of a
|
||||
PTE which is marked non present. This allows a malicious user space
|
||||
application to attack the physical memory to which these PTEs resolve.
|
||||
In some cases user-space can maliciously influence the information
|
||||
encoded in the address bits of the PTE, thus making attacks more
|
||||
deterministic and more practical.
|
||||
|
||||
The Linux kernel contains a mitigation for this attack vector, PTE
|
||||
inversion, which is permanently enabled and has no performance
|
||||
impact. The kernel ensures that the address bits of PTEs, which are not
|
||||
marked present, never point to cacheable physical memory space.
|
||||
|
||||
A system with an up to date kernel is protected against attacks from
|
||||
malicious user space applications.
|
||||
|
||||
2. Malicious guest in a virtual machine
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The fact that L1TF breaks all domain protections allows malicious guest
|
||||
OSes, which can control the PTEs directly, and malicious guest user
|
||||
space applications, which run on an unprotected guest kernel lacking the
|
||||
PTE inversion mitigation for L1TF, to attack physical host memory.
|
||||
|
||||
A special aspect of L1TF in the context of virtualization is symmetric
|
||||
multi threading (SMT). The Intel implementation of SMT is called
|
||||
HyperThreading. The fact that Hyperthreads on the affected processors
|
||||
share the L1 Data Cache (L1D) is important for this. As the flaw allows
|
||||
only to attack data which is present in L1D, a malicious guest running
|
||||
on one Hyperthread can attack the data which is brought into the L1D by
|
||||
the context which runs on the sibling Hyperthread of the same physical
|
||||
core. This context can be host OS, host user space or a different guest.
|
||||
|
||||
If the processor does not support Extended Page Tables, the attack is
|
||||
only possible, when the hypervisor does not sanitize the content of the
|
||||
effective (shadow) page tables.
|
||||
|
||||
While solutions exist to mitigate these attack vectors fully, these
|
||||
mitigations are not enabled by default in the Linux kernel because they
|
||||
can affect performance significantly. The kernel provides several
|
||||
mechanisms which can be utilized to address the problem depending on the
|
||||
deployment scenario. The mitigations, their protection scope and impact
|
||||
are described in the next sections.
|
||||
|
||||
The default mitigations and the rationale for choosing them are explained
|
||||
at the end of this document. See :ref:`default_mitigations`.
|
||||
|
||||
.. _l1tf_sys_info:
|
||||
|
||||
L1TF system information
|
||||
-----------------------
|
||||
|
||||
The Linux kernel provides a sysfs interface to enumerate the current L1TF
|
||||
status of the system: whether the system is vulnerable, and which
|
||||
mitigations are active. The relevant sysfs file is:
|
||||
|
||||
/sys/devices/system/cpu/vulnerabilities/l1tf
|
||||
|
||||
The possible values in this file are:
|
||||
|
||||
=========================== ===============================
|
||||
'Not affected' The processor is not vulnerable
|
||||
'Mitigation: PTE Inversion' The host protection is active
|
||||
=========================== ===============================
|
||||
|
||||
If KVM/VMX is enabled and the processor is vulnerable then the following
|
||||
information is appended to the 'Mitigation: PTE Inversion' part:
|
||||
|
||||
- SMT status:
|
||||
|
||||
===================== ================
|
||||
'VMX: SMT vulnerable' SMT is enabled
|
||||
'VMX: SMT disabled' SMT is disabled
|
||||
===================== ================
|
||||
|
||||
- L1D Flush mode:
|
||||
|
||||
================================ ====================================
|
||||
'L1D vulnerable' L1D flushing is disabled
|
||||
|
||||
'L1D conditional cache flushes' L1D flush is conditionally enabled
|
||||
|
||||
'L1D cache flushes' L1D flush is unconditionally enabled
|
||||
================================ ====================================
|
||||
|
||||
The resulting grade of protection is discussed in the following sections.
|
||||
|
||||
|
||||
Host mitigation mechanism
|
||||
-------------------------
|
||||
|
||||
The kernel is unconditionally protected against L1TF attacks from malicious
|
||||
user space running on the host.
|
||||
|
||||
|
||||
Guest mitigation mechanisms
|
||||
---------------------------
|
||||
|
||||
.. _l1d_flush:
|
||||
|
||||
1. L1D flush on VMENTER
|
||||
^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To make sure that a guest cannot attack data which is present in the L1D
|
||||
the hypervisor flushes the L1D before entering the guest.
|
||||
|
||||
Flushing the L1D evicts not only the data which should not be accessed
|
||||
by a potentially malicious guest, it also flushes the guest
|
||||
data. Flushing the L1D has a performance impact as the processor has to
|
||||
bring the flushed guest data back into the L1D. Depending on the
|
||||
frequency of VMEXIT/VMENTER and the type of computations in the guest
|
||||
performance degradation in the range of 1% to 50% has been observed. For
|
||||
scenarios where guest VMEXIT/VMENTER are rare the performance impact is
|
||||
minimal. Virtio and mechanisms like posted interrupts are designed to
|
||||
confine the VMEXITs to a bare minimum, but specific configurations and
|
||||
application scenarios might still suffer from a high VMEXIT rate.
|
||||
|
||||
The kernel provides two L1D flush modes:
|
||||
- conditional ('cond')
|
||||
- unconditional ('always')
|
||||
|
||||
The conditional mode avoids L1D flushing after VMEXITs which execute
|
||||
only audited code paths before the corresponding VMENTER. These code
|
||||
paths have been verified that they cannot expose secrets or other
|
||||
interesting data to an attacker, but they can leak information about the
|
||||
address space layout of the hypervisor.
|
||||
|
||||
Unconditional mode flushes L1D on all VMENTER invocations and provides
|
||||
maximum protection. It has a higher overhead than the conditional
|
||||
mode. The overhead cannot be quantified correctly as it depends on the
|
||||
workload scenario and the resulting number of VMEXITs.
|
||||
|
||||
The general recommendation is to enable L1D flush on VMENTER. The kernel
|
||||
defaults to conditional mode on affected processors.
|
||||
|
||||
**Note**, that L1D flush does not prevent the SMT problem because the
|
||||
sibling thread will also bring back its data into the L1D which makes it
|
||||
attackable again.
|
||||
|
||||
L1D flush can be controlled by the administrator via the kernel command
|
||||
line and sysfs control files. See :ref:`mitigation_control_command_line`
|
||||
and :ref:`mitigation_control_kvm`.
|
||||
|
||||
.. _guest_confinement:
|
||||
|
||||
2. Guest VCPU confinement to dedicated physical cores
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
To address the SMT problem, it is possible to make a guest or a group of
|
||||
guests affine to one or more physical cores. The proper mechanism for
|
||||
that is to utilize exclusive cpusets to ensure that no other guest or
|
||||
host tasks can run on these cores.
|
||||
|
||||
If only a single guest or related guests run on sibling SMT threads on
|
||||
the same physical core then they can only attack their own memory and
|
||||
restricted parts of the host memory.
|
||||
|
||||
Host memory is attackable, when one of the sibling SMT threads runs in
|
||||
host OS (hypervisor) context and the other in guest context. The amount
|
||||
of valuable information from the host OS context depends on the context
|
||||
which the host OS executes, i.e. interrupts, soft interrupts and kernel
|
||||
threads. The amount of valuable data from these contexts cannot be
|
||||
declared as non-interesting for an attacker without deep inspection of
|
||||
the code.
|
||||
|
||||
**Note**, that assigning guests to a fixed set of physical cores affects
|
||||
the ability of the scheduler to do load balancing and might have
|
||||
negative effects on CPU utilization depending on the hosting
|
||||
scenario. Disabling SMT might be a viable alternative for particular
|
||||
scenarios.
|
||||
|
||||
For further information about confining guests to a single or to a group
|
||||
of cores consult the cpusets documentation:
|
||||
|
||||
https://www.kernel.org/doc/Documentation/cgroup-v1/cpusets.txt
|
||||
|
||||
.. _interrupt_isolation:
|
||||
|
||||
3. Interrupt affinity
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Interrupts can be made affine to logical CPUs. This is not universally
|
||||
true because there are types of interrupts which are truly per CPU
|
||||
interrupts, e.g. the local timer interrupt. Aside of that multi queue
|
||||
devices affine their interrupts to single CPUs or groups of CPUs per
|
||||
queue without allowing the administrator to control the affinities.
|
||||
|
||||
Moving the interrupts, which can be affinity controlled, away from CPUs
|
||||
which run untrusted guests, reduces the attack vector space.
|
||||
|
||||
Whether the interrupts with are affine to CPUs, which run untrusted
|
||||
guests, provide interesting data for an attacker depends on the system
|
||||
configuration and the scenarios which run on the system. While for some
|
||||
of the interrupts it can be assumed that they won't expose interesting
|
||||
information beyond exposing hints about the host OS memory layout, there
|
||||
is no way to make general assumptions.
|
||||
|
||||
Interrupt affinity can be controlled by the administrator via the
|
||||
/proc/irq/$NR/smp_affinity[_list] files. Limited documentation is
|
||||
available at:
|
||||
|
||||
https://www.kernel.org/doc/Documentation/IRQ-affinity.txt
|
||||
|
||||
.. _smt_control:
|
||||
|
||||
4. SMT control
|
||||
^^^^^^^^^^^^^^
|
||||
|
||||
To prevent the SMT issues of L1TF it might be necessary to disable SMT
|
||||
completely. Disabling SMT can have a significant performance impact, but
|
||||
the impact depends on the hosting scenario and the type of workloads.
|
||||
The impact of disabling SMT needs also to be weighted against the impact
|
||||
of other mitigation solutions like confining guests to dedicated cores.
|
||||
|
||||
The kernel provides a sysfs interface to retrieve the status of SMT and
|
||||
to control it. It also provides a kernel command line interface to
|
||||
control SMT.
|
||||
|
||||
The kernel command line interface consists of the following options:
|
||||
|
||||
=========== ==========================================================
|
||||
nosmt Affects the bring up of the secondary CPUs during boot. The
|
||||
kernel tries to bring all present CPUs online during the
|
||||
boot process. "nosmt" makes sure that from each physical
|
||||
core only one - the so called primary (hyper) thread is
|
||||
activated. Due to a design flaw of Intel processors related
|
||||
to Machine Check Exceptions the non primary siblings have
|
||||
to be brought up at least partially and are then shut down
|
||||
again. "nosmt" can be undone via the sysfs interface.
|
||||
|
||||
nosmt=force Has the same effect as "nosmt" but it does not allow to
|
||||
undo the SMT disable via the sysfs interface.
|
||||
=========== ==========================================================
|
||||
|
||||
The sysfs interface provides two files:
|
||||
|
||||
- /sys/devices/system/cpu/smt/control
|
||||
- /sys/devices/system/cpu/smt/active
|
||||
|
||||
/sys/devices/system/cpu/smt/control:
|
||||
|
||||
This file allows to read out the SMT control state and provides the
|
||||
ability to disable or (re)enable SMT. The possible states are:
|
||||
|
||||
============== ===================================================
|
||||
on SMT is supported by the CPU and enabled. All
|
||||
logical CPUs can be onlined and offlined without
|
||||
restrictions.
|
||||
|
||||
off SMT is supported by the CPU and disabled. Only
|
||||
the so called primary SMT threads can be onlined
|
||||
and offlined without restrictions. An attempt to
|
||||
online a non-primary sibling is rejected
|
||||
|
||||
forceoff Same as 'off' but the state cannot be controlled.
|
||||
Attempts to write to the control file are rejected.
|
||||
|
||||
notsupported The processor does not support SMT. It's therefore
|
||||
not affected by the SMT implications of L1TF.
|
||||
Attempts to write to the control file are rejected.
|
||||
============== ===================================================
|
||||
|
||||
The possible states which can be written into this file to control SMT
|
||||
state are:
|
||||
|
||||
- on
|
||||
- off
|
||||
- forceoff
|
||||
|
||||
/sys/devices/system/cpu/smt/active:
|
||||
|
||||
This file reports whether SMT is enabled and active, i.e. if on any
|
||||
physical core two or more sibling threads are online.
|
||||
|
||||
SMT control is also possible at boot time via the l1tf kernel command
|
||||
line parameter in combination with L1D flush control. See
|
||||
:ref:`mitigation_control_command_line`.
|
||||
|
||||
5. Disabling EPT
|
||||
^^^^^^^^^^^^^^^^
|
||||
|
||||
Disabling EPT for virtual machines provides full mitigation for L1TF even
|
||||
with SMT enabled, because the effective page tables for guests are
|
||||
managed and sanitized by the hypervisor. Though disabling EPT has a
|
||||
significant performance impact especially when the Meltdown mitigation
|
||||
KPTI is enabled.
|
||||
|
||||
EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
|
||||
|
||||
There is ongoing research and development for new mitigation mechanisms to
|
||||
address the performance impact of disabling SMT or EPT.
|
||||
|
||||
.. _mitigation_control_command_line:
|
||||
|
||||
Mitigation control on the kernel command line
|
||||
---------------------------------------------
|
||||
|
||||
The kernel command line allows to control the L1TF mitigations at boot
|
||||
time with the option "l1tf=". The valid arguments for this option are:
|
||||
|
||||
============ =============================================================
|
||||
full Provides all available mitigations for the L1TF
|
||||
vulnerability. Disables SMT and enables all mitigations in
|
||||
the hypervisors, i.e. unconditional L1D flushing
|
||||
|
||||
SMT control and L1D flush control via the sysfs interface
|
||||
is still possible after boot. Hypervisors will issue a
|
||||
warning when the first VM is started in a potentially
|
||||
insecure configuration, i.e. SMT enabled or L1D flush
|
||||
disabled.
|
||||
|
||||
full,force Same as 'full', but disables SMT and L1D flush runtime
|
||||
control. Implies the 'nosmt=force' command line option.
|
||||
(i.e. sysfs control of SMT is disabled.)
|
||||
|
||||
flush Leaves SMT enabled and enables the default hypervisor
|
||||
mitigation, i.e. conditional L1D flushing
|
||||
|
||||
SMT control and L1D flush control via the sysfs interface
|
||||
is still possible after boot. Hypervisors will issue a
|
||||
warning when the first VM is started in a potentially
|
||||
insecure configuration, i.e. SMT enabled or L1D flush
|
||||
disabled.
|
||||
|
||||
flush,nosmt Disables SMT and enables the default hypervisor mitigation,
|
||||
i.e. conditional L1D flushing.
|
||||
|
||||
SMT control and L1D flush control via the sysfs interface
|
||||
is still possible after boot. Hypervisors will issue a
|
||||
warning when the first VM is started in a potentially
|
||||
insecure configuration, i.e. SMT enabled or L1D flush
|
||||
disabled.
|
||||
|
||||
flush,nowarn Same as 'flush', but hypervisors will not warn when a VM is
|
||||
started in a potentially insecure configuration.
|
||||
|
||||
off Disables hypervisor mitigations and doesn't emit any
|
||||
warnings.
|
||||
============ =============================================================
|
||||
|
||||
The default is 'flush'. For details about L1D flushing see :ref:`l1d_flush`.
|
||||
|
||||
|
||||
.. _mitigation_control_kvm:
|
||||
|
||||
Mitigation control for KVM - module parameter
|
||||
-------------------------------------------------------------
|
||||
|
||||
The KVM hypervisor mitigation mechanism, flushing the L1D cache when
|
||||
entering a guest, can be controlled with a module parameter.
|
||||
|
||||
The option/parameter is "kvm-intel.vmentry_l1d_flush=". It takes the
|
||||
following arguments:
|
||||
|
||||
============ ==============================================================
|
||||
always L1D cache flush on every VMENTER.
|
||||
|
||||
cond Flush L1D on VMENTER only when the code between VMEXIT and
|
||||
VMENTER can leak host memory which is considered
|
||||
interesting for an attacker. This still can leak host memory
|
||||
which allows e.g. to determine the hosts address space layout.
|
||||
|
||||
never Disables the mitigation
|
||||
============ ==============================================================
|
||||
|
||||
The parameter can be provided on the kernel command line, as a module
|
||||
parameter when loading the modules and at runtime modified via the sysfs
|
||||
file:
|
||||
|
||||
/sys/module/kvm_intel/parameters/vmentry_l1d_flush
|
||||
|
||||
The default is 'cond'. If 'l1tf=full,force' is given on the kernel command
|
||||
line, then 'always' is enforced and the kvm-intel.vmentry_l1d_flush
|
||||
module parameter is ignored and writes to the sysfs file are rejected.
|
||||
|
||||
|
||||
Mitigation selection guide
|
||||
--------------------------
|
||||
|
||||
1. No virtualization in use
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
The system is protected by the kernel unconditionally and no further
|
||||
action is required.
|
||||
|
||||
2. Virtualization with trusted guests
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If the guest comes from a trusted source and the guest OS kernel is
|
||||
guaranteed to have the L1TF mitigations in place the system is fully
|
||||
protected against L1TF and no further action is required.
|
||||
|
||||
To avoid the overhead of the default L1D flushing on VMENTER the
|
||||
administrator can disable the flushing via the kernel command line and
|
||||
sysfs control files. See :ref:`mitigation_control_command_line` and
|
||||
:ref:`mitigation_control_kvm`.
|
||||
|
||||
|
||||
3. Virtualization with untrusted guests
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
3.1. SMT not supported or disabled
|
||||
""""""""""""""""""""""""""""""""""
|
||||
|
||||
If SMT is not supported by the processor or disabled in the BIOS or by
|
||||
the kernel, it's only required to enforce L1D flushing on VMENTER.
|
||||
|
||||
Conditional L1D flushing is the default behaviour and can be tuned. See
|
||||
:ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
|
||||
|
||||
3.2. EPT not supported or disabled
|
||||
""""""""""""""""""""""""""""""""""
|
||||
|
||||
If EPT is not supported by the processor or disabled in the hypervisor,
|
||||
the system is fully protected. SMT can stay enabled and L1D flushing on
|
||||
VMENTER is not required.
|
||||
|
||||
EPT can be disabled in the hypervisor via the 'kvm-intel.ept' parameter.
|
||||
|
||||
3.3. SMT and EPT supported and active
|
||||
"""""""""""""""""""""""""""""""""""""
|
||||
|
||||
If SMT and EPT are supported and active then various degrees of
|
||||
mitigations can be employed:
|
||||
|
||||
- L1D flushing on VMENTER:
|
||||
|
||||
L1D flushing on VMENTER is the minimal protection requirement, but it
|
||||
is only potent in combination with other mitigation methods.
|
||||
|
||||
Conditional L1D flushing is the default behaviour and can be tuned. See
|
||||
:ref:`mitigation_control_command_line` and :ref:`mitigation_control_kvm`.
|
||||
|
||||
- Guest confinement:
|
||||
|
||||
Confinement of guests to a single or a group of physical cores which
|
||||
are not running any other processes, can reduce the attack surface
|
||||
significantly, but interrupts, soft interrupts and kernel threads can
|
||||
still expose valuable data to a potential attacker. See
|
||||
:ref:`guest_confinement`.
|
||||
|
||||
- Interrupt isolation:
|
||||
|
||||
Isolating the guest CPUs from interrupts can reduce the attack surface
|
||||
further, but still allows a malicious guest to explore a limited amount
|
||||
of host physical memory. This can at least be used to gain knowledge
|
||||
about the host address space layout. The interrupts which have a fixed
|
||||
affinity to the CPUs which run the untrusted guests can depending on
|
||||
the scenario still trigger soft interrupts and schedule kernel threads
|
||||
which might expose valuable information. See
|
||||
:ref:`interrupt_isolation`.
|
||||
|
||||
The above three mitigation methods combined can provide protection to a
|
||||
certain degree, but the risk of the remaining attack surface has to be
|
||||
carefully analyzed. For full protection the following methods are
|
||||
available:
|
||||
|
||||
- Disabling SMT:
|
||||
|
||||
Disabling SMT and enforcing the L1D flushing provides the maximum
|
||||
amount of protection. This mitigation is not depending on any of the
|
||||
above mitigation methods.
|
||||
|
||||
SMT control and L1D flushing can be tuned by the command line
|
||||
parameters 'nosmt', 'l1tf', 'kvm-intel.vmentry_l1d_flush' and at run
|
||||
time with the matching sysfs control files. See :ref:`smt_control`,
|
||||
:ref:`mitigation_control_command_line` and
|
||||
:ref:`mitigation_control_kvm`.
|
||||
|
||||
- Disabling EPT:
|
||||
|
||||
Disabling EPT provides the maximum amount of protection as well. It is
|
||||
not depending on any of the above mitigation methods. SMT can stay
|
||||
enabled and L1D flushing is not required, but the performance impact is
|
||||
significant.
|
||||
|
||||
EPT can be disabled in the hypervisor via the 'kvm-intel.ept'
|
||||
parameter.
|
||||
|
||||
3.4. Nested virtual machines
|
||||
""""""""""""""""""""""""""""
|
||||
|
||||
When nested virtualization is in use, three operating systems are involved:
|
||||
the bare metal hypervisor, the nested hypervisor and the nested virtual
|
||||
machine. VMENTER operations from the nested hypervisor into the nested
|
||||
guest will always be processed by the bare metal hypervisor. If KVM is the
|
||||
bare metal hypervisor it wiil:
|
||||
|
||||
- Flush the L1D cache on every switch from the nested hypervisor to the
|
||||
nested virtual machine, so that the nested hypervisor's secrets are not
|
||||
exposed to the nested virtual machine;
|
||||
|
||||
- Flush the L1D cache on every switch from the nested virtual machine to
|
||||
the nested hypervisor; this is a complex operation, and flushing the L1D
|
||||
cache avoids that the bare metal hypervisor's secrets are exposed to the
|
||||
nested virtual machine;
|
||||
|
||||
- Instruct the nested hypervisor to not perform any L1D cache flush. This
|
||||
is an optimization to avoid double L1D flushing.
|
||||
|
||||
|
||||
.. _default_mitigations:
|
||||
|
||||
Default mitigations
|
||||
-------------------
|
||||
|
||||
The kernel default mitigations for vulnerable processors are:
|
||||
|
||||
- PTE inversion to protect against malicious user space. This is done
|
||||
unconditionally and cannot be controlled.
|
||||
|
||||
- L1D conditional flushing on VMENTER when EPT is enabled for
|
||||
a guest.
|
||||
|
||||
The kernel does not by default enforce the disabling of SMT, which leaves
|
||||
SMT systems vulnerable when running untrusted guests with EPT enabled.
|
||||
|
||||
The rationale for this choice is:
|
||||
|
||||
- Force disabling SMT can break existing setups, especially with
|
||||
unattended updates.
|
||||
|
||||
- If regular users run untrusted guests on their machine, then L1TF is
|
||||
just an add on to other malware which might be embedded in an untrusted
|
||||
guest, e.g. spam-bots or attacks on the local network.
|
||||
|
||||
There is no technical way to prevent a user from running untrusted code
|
||||
on their machines blindly.
|
||||
|
||||
- It's technically extremely unlikely and from today's knowledge even
|
||||
impossible that L1TF can be exploited via the most popular attack
|
||||
mechanisms like JavaScript because these mechanisms have no way to
|
||||
control PTEs. If this would be possible and not other mitigation would
|
||||
be possible, then the default might be different.
|
||||
|
||||
- The administrators of cloud and hosting setups have to carefully
|
||||
analyze the risk for their scenarios and make the appropriate
|
||||
mitigation choices, which might even vary across their deployed
|
||||
machines and also result in other changes of their overall setup.
|
||||
There is no way for the kernel to provide a sensible default for this
|
||||
kind of scenarios.
|
||||
|
|
@ -65,6 +65,11 @@ workload one should:
|
|||
are not reclaimable, he or she can filter them out using
|
||||
``/proc/kpageflags``.
|
||||
|
||||
The page-types tool in the tools/vm directory can be used to assist in this.
|
||||
If the tool is run initially with the appropriate option, it will mark all the
|
||||
queried pages as idle. Subsequent runs of the tool can then show which pages have
|
||||
their idle flag cleared in the interim.
|
||||
|
||||
See :ref:`Documentation/admin-guide/mm/pagemap.rst <pagemap>` for more
|
||||
information about ``/proc/pid/pagemap``, ``/proc/kpageflags``, and
|
||||
``/proc/kpagecgroup``.
|
||||
|
|
|
|||
|
|
@ -44,6 +44,9 @@ There are four components to pagemap:
|
|||
* ``/proc/kpagecount``. This file contains a 64-bit count of the number of
|
||||
times each page is mapped, indexed by PFN.
|
||||
|
||||
The page-types tool in the tools/vm directory can be used to query the
|
||||
number of times a page is mapped.
|
||||
|
||||
* ``/proc/kpageflags``. This file contains a 64-bit set of flags for each
|
||||
page, indexed by PFN.
|
||||
|
||||
|
|
|
|||
|
|
@ -85,3 +85,10 @@ shared_tags=[0/1]: Default: 0
|
|||
0: Tag set is not shared.
|
||||
1: Tag set shared between devices for blk-mq. Only makes sense with
|
||||
nr_devices > 1, otherwise there's no tag set to share.
|
||||
|
||||
zoned=[0/1]: Default: 0
|
||||
0: Block device is exposed as a random-access block device.
|
||||
1: Block device is exposed as a host-managed zoned block device.
|
||||
|
||||
zone_size=[MB]: Default: 256
|
||||
Per zone size when exposed as a zoned block device. Must be a power of two.
|
||||
|
|
|
|||
|
|
@ -31,28 +31,32 @@ write ticks milliseconds total wait time for write requests
|
|||
in_flight requests number of I/Os currently in flight
|
||||
io_ticks milliseconds total time this block device has been active
|
||||
time_in_queue milliseconds total wait time for all requests
|
||||
discard I/Os requests number of discard I/Os processed
|
||||
discard merges requests number of discard I/Os merged with in-queue I/O
|
||||
discard sectors sectors number of sectors discarded
|
||||
discard ticks milliseconds total wait time for discard requests
|
||||
|
||||
read I/Os, write I/Os
|
||||
=====================
|
||||
read I/Os, write I/Os, discard I/0s
|
||||
===================================
|
||||
|
||||
These values increment when an I/O request completes.
|
||||
|
||||
read merges, write merges
|
||||
=========================
|
||||
read merges, write merges, discard merges
|
||||
=========================================
|
||||
|
||||
These values increment when an I/O request is merged with an
|
||||
already-queued I/O request.
|
||||
|
||||
read sectors, write sectors
|
||||
===========================
|
||||
read sectors, write sectors, discard_sectors
|
||||
============================================
|
||||
|
||||
These values count the number of sectors read from or written to this
|
||||
block device. The "sectors" in question are the standard UNIX 512-byte
|
||||
sectors, not any device- or filesystem-specific block size. The
|
||||
counters are incremented when the I/O completes.
|
||||
These values count the number of sectors read from, written to, or
|
||||
discarded from this block device. The "sectors" in question are the
|
||||
standard UNIX 512-byte sectors, not any device- or filesystem-specific
|
||||
block size. The counters are incremented when the I/O completes.
|
||||
|
||||
read ticks, write ticks
|
||||
=======================
|
||||
read ticks, write ticks, discard ticks
|
||||
======================================
|
||||
|
||||
These values count the number of milliseconds that I/O requests have
|
||||
waited on this block device. If there are multiple I/O requests waiting,
|
||||
|
|
|
|||
|
|
@ -106,9 +106,9 @@ into the bpf-next tree will make their way into net-next tree. net and
|
|||
net-next are both run by David S. Miller. From there, they will go
|
||||
into the kernel mainline tree run by Linus Torvalds. To read up on the
|
||||
process of net and net-next being merged into the mainline tree, see
|
||||
the `netdev FAQ`_ under:
|
||||
the :ref:`netdev-FAQ`
|
||||
|
||||
|
||||
`Documentation/networking/netdev-FAQ.txt`_
|
||||
|
||||
Occasionally, to prevent merge conflicts, we might send pull requests
|
||||
to other trees (e.g. tracing) with a small subset of the patches, but
|
||||
|
|
@ -125,8 +125,8 @@ request)::
|
|||
Q: How do I indicate which tree (bpf vs. bpf-next) my patch should be applied to?
|
||||
---------------------------------------------------------------------------------
|
||||
|
||||
A: The process is the very same as described in the `netdev FAQ`_, so
|
||||
please read up on it. The subject line must indicate whether the
|
||||
A: The process is the very same as described in the :ref:`netdev-FAQ`,
|
||||
so please read up on it. The subject line must indicate whether the
|
||||
patch is a fix or rather "next-like" content in order to let the
|
||||
maintainers know whether it is targeted at bpf or bpf-next.
|
||||
|
||||
|
|
@ -184,7 +184,7 @@ ii) run extensive BPF test suite and
|
|||
Once the BPF pull request was accepted by David S. Miller, then
|
||||
the patches end up in net or net-next tree, respectively, and
|
||||
make their way from there further into mainline. Again, see the
|
||||
`netdev FAQ`_ for additional information e.g. on how often they are
|
||||
:ref:`netdev-FAQ` for additional information e.g. on how often they are
|
||||
merged to mainline.
|
||||
|
||||
Q: How long do I need to wait for feedback on my BPF patches?
|
||||
|
|
@ -208,7 +208,7 @@ Q: Are patches applied to bpf-next when the merge window is open?
|
|||
-----------------------------------------------------------------
|
||||
A: For the time when the merge window is open, bpf-next will not be
|
||||
processed. This is roughly analogous to net-next patch processing,
|
||||
so feel free to read up on the `netdev FAQ`_ about further details.
|
||||
so feel free to read up on the :ref:`netdev-FAQ` about further details.
|
||||
|
||||
During those two weeks of merge window, we might ask you to resend
|
||||
your patch series once bpf-next is open again. Once Linus released
|
||||
|
|
@ -372,7 +372,7 @@ netdev kernel mailing list in Cc and ask for the fix to be queued up:
|
|||
netdev@vger.kernel.org
|
||||
|
||||
The process in general is the same as on netdev itself, see also the
|
||||
`netdev FAQ`_ document.
|
||||
:ref:`netdev-FAQ`.
|
||||
|
||||
Q: Do you also backport to kernels not currently maintained as stable?
|
||||
----------------------------------------------------------------------
|
||||
|
|
@ -388,9 +388,7 @@ Q: The BPF patch I am about to submit needs to go to stable as well
|
|||
What should I do?
|
||||
|
||||
A: The same rules apply as with netdev patch submissions in general, see
|
||||
`netdev FAQ`_ under:
|
||||
|
||||
`Documentation/networking/netdev-FAQ.txt`_
|
||||
the :ref:`netdev-FAQ`.
|
||||
|
||||
Never add "``Cc: stable@vger.kernel.org``" to the patch description, but
|
||||
ask the BPF maintainers to queue the patches instead. This can be done
|
||||
|
|
@ -630,8 +628,7 @@ when:
|
|||
.. Links
|
||||
.. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/
|
||||
.. _MAINTAINERS: ../../MAINTAINERS
|
||||
.. _Documentation/networking/netdev-FAQ.txt: ../networking/netdev-FAQ.txt
|
||||
.. _netdev FAQ: ../networking/netdev-FAQ.txt
|
||||
.. _netdev-FAQ: ../networking/netdev-FAQ.rst
|
||||
.. _samples/bpf/: ../../samples/bpf/
|
||||
.. _selftests: ../../tools/testing/selftests/bpf/
|
||||
.. _Documentation/dev-tools/kselftest.rst:
|
||||
|
|
|
|||
|
|
@ -1,5 +1,5 @@
|
|||
=================
|
||||
BPF documentation
|
||||
BPF Documentation
|
||||
=================
|
||||
|
||||
This directory contains documentation for the BPF (Berkeley Packet
|
||||
|
|
@ -22,14 +22,14 @@ Frequently asked questions (FAQ)
|
|||
|
||||
Two sets of Questions and Answers (Q&A) are maintained.
|
||||
|
||||
* QA for common questions about BPF see: bpf_design_QA_
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
* QA for developers interacting with BPF subsystem: bpf_devel_QA_
|
||||
bpf_design_QA
|
||||
bpf_devel_QA
|
||||
|
||||
|
||||
.. Links:
|
||||
.. _bpf_design_QA: bpf_design_QA.rst
|
||||
.. _bpf_devel_QA: bpf_devel_QA.rst
|
||||
.. _Documentation/networking/filter.txt: ../networking/filter.txt
|
||||
.. _man-pages: https://www.kernel.org/doc/man-pages/
|
||||
.. _bpf(2): http://man7.org/linux/man-pages/man2/bpf.2.html
|
||||
|
|
@ -34,7 +34,7 @@ needs_sphinx = '1.3'
|
|||
# Add any Sphinx extension module names here, as strings. They can be
|
||||
# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
|
||||
# ones.
|
||||
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure']
|
||||
extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 'kfigure', 'sphinx.ext.ifconfig']
|
||||
|
||||
# The name of the math extension changed on Sphinx 1.4
|
||||
if major == 1 and minor > 3:
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Console Drivers
|
||||
===============
|
||||
|
||||
The linux kernel has 2 general types of console drivers. The first type is
|
||||
The Linux kernel has 2 general types of console drivers. The first type is
|
||||
assigned by the kernel to all the virtual consoles during the boot process.
|
||||
This type will be called 'system driver', and only one system driver is allowed
|
||||
to exist. The system driver is persistent and it can never be unloaded, though
|
||||
|
|
@ -17,10 +17,11 @@ of driver occupying the consoles.) They can only take over the console that is
|
|||
occupied by the system driver. In the same token, if the modular driver is
|
||||
released by the console, the system driver will take over.
|
||||
|
||||
Modular drivers, from the programmer's point of view, has to call:
|
||||
Modular drivers, from the programmer's point of view, have to call:
|
||||
|
||||
do_take_over_console() - load and bind driver to console layer
|
||||
give_up_console() - unload driver, it will only work if driver is fully unbond
|
||||
give_up_console() - unload driver; it will only work if driver
|
||||
is fully unbound
|
||||
|
||||
In newer kernels, the following are also available:
|
||||
|
||||
|
|
@ -56,7 +57,7 @@ What do these files signify?
|
|||
cat /sys/class/vtconsole/vtcon0/name
|
||||
(S) VGA+
|
||||
|
||||
'(S)' stands for a (S)ystem driver, ie, it cannot be directly
|
||||
'(S)' stands for a (S)ystem driver, i.e., it cannot be directly
|
||||
commanded to bind or unbind
|
||||
|
||||
'VGA+' is the name of the driver
|
||||
|
|
@ -89,7 +90,7 @@ driver, make changes, recompile, reload and rebind the driver without any need
|
|||
for rebooting the kernel. For regular users who may want to switch from
|
||||
framebuffer console to VGA console and vice versa, this feature also makes
|
||||
this possible. (NOTE NOTE NOTE: Please read fbcon.txt under Documentation/fb
|
||||
for more details).
|
||||
for more details.)
|
||||
|
||||
Notes for developers:
|
||||
=====================
|
||||
|
|
@ -110,8 +111,8 @@ In order for binding to and unbinding from the console to properly work,
|
|||
console drivers must follow these guidelines:
|
||||
|
||||
1. All drivers, except system drivers, must call either do_register_con_driver()
|
||||
or do_take_over_console(). do_register_con_driver() will just add the driver to
|
||||
the console's internal list. It won't take over the
|
||||
or do_take_over_console(). do_register_con_driver() will just add the driver
|
||||
to the console's internal list. It won't take over the
|
||||
console. do_take_over_console(), as it name implies, will also take over (or
|
||||
bind to) the console.
|
||||
|
||||
|
|
|
|||
|
|
@ -29,7 +29,7 @@ updated by one CPU, local_t is probably more appropriate. Please see
|
|||
local_t.
|
||||
|
||||
The first operations to implement for atomic_t's are the initializers and
|
||||
plain reads. ::
|
||||
plain writes. ::
|
||||
|
||||
#define ATOMIC_INIT(i) { (i) }
|
||||
#define atomic_set(v, i) ((v)->counter = (i))
|
||||
|
|
|
|||
|
|
@ -0,0 +1,92 @@
|
|||
===========================
|
||||
Boot time memory management
|
||||
===========================
|
||||
|
||||
Early system initialization cannot use "normal" memory management
|
||||
simply because it is not set up yet. But there is still need to
|
||||
allocate memory for various data structures, for instance for the
|
||||
physical page allocator. To address this, a specialized allocator
|
||||
called the :ref:`Boot Memory Allocator <bootmem>`, or bootmem, was
|
||||
introduced. Several years later PowerPC developers added a "Logical
|
||||
Memory Blocks" allocator, which was later adopted by other
|
||||
architectures and renamed to :ref:`memblock <memblock>`. There is also
|
||||
a compatibility layer called `nobootmem` that translates bootmem
|
||||
allocation interfaces to memblock calls.
|
||||
|
||||
The selection of the early allocator is done using
|
||||
``CONFIG_NO_BOOTMEM`` and ``CONFIG_HAVE_MEMBLOCK`` kernel
|
||||
configuration options. These options are enabled or disabled
|
||||
statically by the architectures' Kconfig files.
|
||||
|
||||
* Architectures that rely only on bootmem select
|
||||
``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=n``.
|
||||
* The users of memblock with the nobootmem compatibility layer set
|
||||
``CONFIG_NO_BOOTMEM=y && CONFIG_HAVE_MEMBLOCK=y``.
|
||||
* And for those that use both memblock and bootmem the configuration
|
||||
includes ``CONFIG_NO_BOOTMEM=n && CONFIG_HAVE_MEMBLOCK=y``.
|
||||
|
||||
Whichever allocator is used, it is the responsibility of the
|
||||
architecture specific initialization to set it up in
|
||||
:c:func:`setup_arch` and tear it down in :c:func:`mem_init` functions.
|
||||
|
||||
Once the early memory management is available it offers a variety of
|
||||
functions and macros for memory allocations. The allocation request
|
||||
may be directed to the first (and probably the only) node or to a
|
||||
particular node in a NUMA system. There are API variants that panic
|
||||
when an allocation fails and those that don't. And more recent and
|
||||
advanced memblock even allows controlling its own behaviour.
|
||||
|
||||
.. _bootmem:
|
||||
|
||||
Bootmem
|
||||
=======
|
||||
|
||||
(mostly stolen from Mel Gorman's "Understanding the Linux Virtual
|
||||
Memory Manager" `book`_)
|
||||
|
||||
.. _book: https://www.kernel.org/doc/gorman/
|
||||
|
||||
.. kernel-doc:: mm/bootmem.c
|
||||
:doc: bootmem overview
|
||||
|
||||
.. _memblock:
|
||||
|
||||
Memblock
|
||||
========
|
||||
|
||||
.. kernel-doc:: mm/memblock.c
|
||||
:doc: memblock overview
|
||||
|
||||
|
||||
Functions and structures
|
||||
========================
|
||||
|
||||
Common API
|
||||
----------
|
||||
|
||||
The functions that are described in this section are available
|
||||
regardless of what early memory manager is enabled.
|
||||
|
||||
.. kernel-doc:: mm/nobootmem.c
|
||||
|
||||
Bootmem specific API
|
||||
--------------------
|
||||
|
||||
These interfaces available only with bootmem, i.e when ``CONFIG_NO_BOOTMEM=n``
|
||||
|
||||
.. kernel-doc:: include/linux/bootmem.h
|
||||
.. kernel-doc:: mm/bootmem.c
|
||||
:nodocs:
|
||||
|
||||
Memblock specific API
|
||||
---------------------
|
||||
|
||||
Here is the description of memblock data structures, functions and
|
||||
macros. Some of them are actually internal, but since they are
|
||||
documented it would be silly to omit them. Besides, reading the
|
||||
descriptions for the internal functions can help to understand what
|
||||
really happens under the hood.
|
||||
|
||||
.. kernel-doc:: include/linux/memblock.h
|
||||
.. kernel-doc:: mm/memblock.c
|
||||
:nodocs:
|
||||
|
|
@ -76,4 +76,6 @@ Functions and structures
|
|||
========================
|
||||
|
||||
.. kernel-doc:: include/linux/idr.h
|
||||
:functions:
|
||||
.. kernel-doc:: lib/idr.c
|
||||
:functions:
|
||||
|
|
|
|||
|
|
@ -27,7 +27,10 @@ Core utilities
|
|||
errseq
|
||||
printk-formats
|
||||
circular-buffers
|
||||
mm-api
|
||||
gfp_mask-from-fs-io
|
||||
timekeeping
|
||||
boot-time-mm
|
||||
|
||||
Interfaces for kernel debugging
|
||||
===============================
|
||||
|
|
|
|||
|
|
@ -39,6 +39,10 @@ String Manipulation
|
|||
.. kernel-doc:: lib/string.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/util.c
|
||||
:functions: kstrdup kstrdup_const kstrndup kmemdup kmemdup_nul memdup_user
|
||||
vmemdup_user strndup_user memdup_user_nul
|
||||
|
||||
Basic Kernel Library Functions
|
||||
==============================
|
||||
|
||||
|
|
@ -155,60 +159,6 @@ UUID/GUID
|
|||
.. kernel-doc:: lib/uuid.c
|
||||
:export:
|
||||
|
||||
Memory Management in Linux
|
||||
==========================
|
||||
|
||||
The Slab Cache
|
||||
--------------
|
||||
|
||||
.. kernel-doc:: include/linux/slab.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: mm/slab.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/util.c
|
||||
:export:
|
||||
|
||||
User Space Memory Access
|
||||
------------------------
|
||||
|
||||
.. kernel-doc:: arch/x86/include/asm/uaccess.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: arch/x86/lib/usercopy_32.c
|
||||
:export:
|
||||
|
||||
More Memory Management Functions
|
||||
--------------------------------
|
||||
|
||||
.. kernel-doc:: mm/readahead.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/filemap.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/memory.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/vmalloc.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/page_alloc.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: mm/mempool.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/dmapool.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/page-writeback.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/truncate.c
|
||||
:export:
|
||||
|
||||
Kernel IPC facilities
|
||||
=====================
|
||||
|
||||
|
|
@ -437,4 +387,3 @@ Read-Copy Update (RCU)
|
|||
.. kernel-doc:: include/linux/rcu_sync.h
|
||||
|
||||
.. kernel-doc:: kernel/rcu/sync.c
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,78 @@
|
|||
======================
|
||||
Memory Management APIs
|
||||
======================
|
||||
|
||||
User Space Memory Access
|
||||
========================
|
||||
|
||||
.. kernel-doc:: arch/x86/include/asm/uaccess.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: arch/x86/lib/usercopy_32.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/util.c
|
||||
:functions: get_user_pages_fast
|
||||
|
||||
Memory Allocation Controls
|
||||
==========================
|
||||
|
||||
Functions which need to allocate memory often use GFP flags to express
|
||||
how that memory should be allocated. The GFP acronym stands for "get
|
||||
free pages", the underlying memory allocation function. Not every GFP
|
||||
flag is allowed to every function which may allocate memory. Most
|
||||
users will want to use a plain ``GFP_KERNEL``.
|
||||
|
||||
.. kernel-doc:: include/linux/gfp.h
|
||||
:doc: Page mobility and placement hints
|
||||
|
||||
.. kernel-doc:: include/linux/gfp.h
|
||||
:doc: Watermark modifiers
|
||||
|
||||
.. kernel-doc:: include/linux/gfp.h
|
||||
:doc: Reclaim modifiers
|
||||
|
||||
.. kernel-doc:: include/linux/gfp.h
|
||||
:doc: Common combinations
|
||||
|
||||
The Slab Cache
|
||||
==============
|
||||
|
||||
.. kernel-doc:: include/linux/slab.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: mm/slab.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/util.c
|
||||
:functions: kfree_const kvmalloc_node kvfree
|
||||
|
||||
More Memory Management Functions
|
||||
================================
|
||||
|
||||
.. kernel-doc:: mm/readahead.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/filemap.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/memory.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/vmalloc.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/page_alloc.c
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: mm/mempool.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/dmapool.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/page-writeback.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: mm/truncate.c
|
||||
:export:
|
||||
|
|
@ -0,0 +1,185 @@
|
|||
ktime accessors
|
||||
===============
|
||||
|
||||
Device drivers can read the current time using ktime_get() and the many
|
||||
related functions declared in linux/timekeeping.h. As a rule of thumb,
|
||||
using an accessor with a shorter name is preferred over one with a longer
|
||||
name if both are equally fit for a particular use case.
|
||||
|
||||
Basic ktime_t based interfaces
|
||||
------------------------------
|
||||
|
||||
The recommended simplest form returns an opaque ktime_t, with variants
|
||||
that return time for different clock references:
|
||||
|
||||
|
||||
.. c:function:: ktime_t ktime_get( void )
|
||||
|
||||
CLOCK_MONOTONIC
|
||||
|
||||
Useful for reliable timestamps and measuring short time intervals
|
||||
accurately. Starts at system boot time but stops during suspend.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_boottime( void )
|
||||
|
||||
CLOCK_BOOTTIME
|
||||
|
||||
Like ktime_get(), but does not stop when suspended. This can be
|
||||
used e.g. for key expiration times that need to be synchronized
|
||||
with other machines across a suspend operation.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_real( void )
|
||||
|
||||
CLOCK_REALTIME
|
||||
|
||||
Returns the time in relative to the UNIX epoch starting in 1970
|
||||
using the Coordinated Universal Time (UTC), same as gettimeofday()
|
||||
user space. This is used for all timestamps that need to
|
||||
persist across a reboot, like inode times, but should be avoided
|
||||
for internal uses, since it can jump backwards due to a leap
|
||||
second update, NTP adjustment settimeofday() operation from user
|
||||
space.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_clocktai( void )
|
||||
|
||||
CLOCK_TAI
|
||||
|
||||
Like ktime_get_real(), but uses the International Atomic Time (TAI)
|
||||
reference instead of UTC to avoid jumping on leap second updates.
|
||||
This is rarely useful in the kernel.
|
||||
|
||||
.. c:function:: ktime_t ktime_get_raw( void )
|
||||
|
||||
CLOCK_MONOTONIC_RAW
|
||||
|
||||
Like ktime_get(), but runs at the same rate as the hardware
|
||||
clocksource without (NTP) adjustments for clock drift. This is
|
||||
also rarely needed in the kernel.
|
||||
|
||||
nanosecond, timespec64, and second output
|
||||
-----------------------------------------
|
||||
|
||||
For all of the above, there are variants that return the time in a
|
||||
different format depending on what is required by the user:
|
||||
|
||||
.. c:function:: u64 ktime_get_ns( void )
|
||||
u64 ktime_get_boottime_ns( void )
|
||||
u64 ktime_get_real_ns( void )
|
||||
u64 ktime_get_tai_ns( void )
|
||||
u64 ktime_get_raw_ns( void )
|
||||
|
||||
Same as the plain ktime_get functions, but returning a u64 number
|
||||
of nanoseconds in the respective time reference, which may be
|
||||
more convenient for some callers.
|
||||
|
||||
.. c:function:: void ktime_get_ts64( struct timespec64 * )
|
||||
void ktime_get_boottime_ts64( struct timespec64 * )
|
||||
void ktime_get_real_ts64( struct timespec64 * )
|
||||
void ktime_get_clocktai_ts64( struct timespec64 * )
|
||||
void ktime_get_raw_ts64( struct timespec64 * )
|
||||
|
||||
Same above, but returns the time in a 'struct timespec64', split
|
||||
into seconds and nanoseconds. This can avoid an extra division
|
||||
when printing the time, or when passing it into an external
|
||||
interface that expects a 'timespec' or 'timeval' structure.
|
||||
|
||||
.. c:function:: time64_t ktime_get_seconds( void )
|
||||
time64_t ktime_get_boottime_seconds( void )
|
||||
time64_t ktime_get_real_seconds( void )
|
||||
time64_t ktime_get_clocktai_seconds( void )
|
||||
time64_t ktime_get_raw_seconds( void )
|
||||
|
||||
Return a coarse-grained version of the time as a scalar
|
||||
time64_t. This avoids accessing the clock hardware and rounds
|
||||
down the seconds to the full seconds of the last timer tick
|
||||
using the respective reference.
|
||||
|
||||
Coarse and fast_ns access
|
||||
-------------------------
|
||||
|
||||
Some additional variants exist for more specialized cases:
|
||||
|
||||
.. c:function:: ktime_t ktime_get_coarse_boottime( void )
|
||||
ktime_t ktime_get_coarse_real( void )
|
||||
ktime_t ktime_get_coarse_clocktai( void )
|
||||
ktime_t ktime_get_coarse_raw( void )
|
||||
|
||||
.. c:function:: void ktime_get_coarse_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_boottime_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_real_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_clocktai_ts64( struct timespec64 * )
|
||||
void ktime_get_coarse_raw_ts64( struct timespec64 * )
|
||||
|
||||
These are quicker than the non-coarse versions, but less accurate,
|
||||
corresponding to CLOCK_MONONOTNIC_COARSE and CLOCK_REALTIME_COARSE
|
||||
in user space, along with the equivalent boottime/tai/raw
|
||||
timebase not available in user space.
|
||||
|
||||
The time returned here corresponds to the last timer tick, which
|
||||
may be as much as 10ms in the past (for CONFIG_HZ=100), same as
|
||||
reading the 'jiffies' variable. These are only useful when called
|
||||
in a fast path and one still expects better than second accuracy,
|
||||
but can't easily use 'jiffies', e.g. for inode timestamps.
|
||||
Skipping the hardware clock access saves around 100 CPU cycles
|
||||
on most modern machines with a reliable cycle counter, but
|
||||
up to several microseconds on older hardware with an external
|
||||
clocksource.
|
||||
|
||||
.. c:function:: u64 ktime_get_mono_fast_ns( void )
|
||||
u64 ktime_get_raw_fast_ns( void )
|
||||
u64 ktime_get_boot_fast_ns( void )
|
||||
u64 ktime_get_real_fast_ns( void )
|
||||
|
||||
These variants are safe to call from any context, including from
|
||||
a non-maskable interrupt (NMI) during a timekeeper update, and
|
||||
while we are entering suspend with the clocksource powered down.
|
||||
This is useful in some tracing or debugging code as well as
|
||||
machine check reporting, but most drivers should never call them,
|
||||
since the time is allowed to jump under certain conditions.
|
||||
|
||||
Deprecated time interfaces
|
||||
--------------------------
|
||||
|
||||
Older kernels used some other interfaces that are now being phased out
|
||||
but may appear in third-party drivers being ported here. In particular,
|
||||
all interfaces returning a 'struct timeval' or 'struct timespec' have
|
||||
been replaced because the tv_sec member overflows in year 2038 on 32-bit
|
||||
architectures. These are the recommended replacements:
|
||||
|
||||
.. c:function:: void ktime_get_ts( struct timespec * )
|
||||
|
||||
Use ktime_get() or ktime_get_ts64() instead.
|
||||
|
||||
.. c:function:: struct timeval do_gettimeofday( void )
|
||||
struct timespec getnstimeofday( void )
|
||||
struct timespec64 getnstimeofday64( void )
|
||||
void ktime_get_real_ts( struct timespec * )
|
||||
|
||||
ktime_get_real_ts64() is a direct replacement, but consider using
|
||||
monotonic time (ktime_get_ts64()) and/or a ktime_t based interface
|
||||
(ktime_get()/ktime_get_real()).
|
||||
|
||||
.. c:function:: struct timespec current_kernel_time( void )
|
||||
struct timespec64 current_kernel_time64( void )
|
||||
struct timespec get_monotonic_coarse( void )
|
||||
struct timespec64 get_monotonic_coarse64( void )
|
||||
|
||||
These are replaced by ktime_get_coarse_real_ts64() and
|
||||
ktime_get_coarse_ts64(). However, A lot of code that wants
|
||||
coarse-grained times can use the simple 'jiffies' instead, while
|
||||
some drivers may actually want the higher resolution accessors
|
||||
these days.
|
||||
|
||||
.. c:function:: struct timespec getrawmonotonic( void )
|
||||
struct timespec64 getrawmonotonic64( void )
|
||||
struct timespec timekeeping_clocktai( void )
|
||||
struct timespec64 timekeeping_clocktai64( void )
|
||||
struct timespec get_monotonic_boottime( void )
|
||||
struct timespec64 get_monotonic_boottime64( void )
|
||||
|
||||
These are replaced by ktime_get_raw()/ktime_get_raw_ts64(),
|
||||
ktime_get_clocktai()/ktime_get_clocktai_ts64() as well
|
||||
as ktime_get_boottime()/ktime_get_boottime_ts64().
|
||||
However, if the particular choice of clock source is not
|
||||
important for the user, consider converting to
|
||||
ktime_get()/ktime_get_ts64() instead for consistency.
|
||||
|
|
@ -162,7 +162,7 @@ Code Example For Use of Operational State Memory With SHASH
|
|||
char *hash_alg_name = "sha1-padlock-nano";
|
||||
int ret;
|
||||
|
||||
alg = crypto_alloc_shash(hash_alg_name, CRYPTO_ALG_TYPE_SHASH, 0);
|
||||
alg = crypto_alloc_shash(hash_alg_name, 0, 0);
|
||||
if (IS_ERR(alg)) {
|
||||
pr_info("can't alloc alg %s\n", hash_alg_name);
|
||||
return PTR_ERR(alg);
|
||||
|
|
|
|||
|
|
@ -156,6 +156,11 @@ Contributing new tests (details)
|
|||
installed by the distro on the system should be the primary focus to be able
|
||||
to find regressions.
|
||||
|
||||
* If a test needs specific kernel config options enabled, add a config file in
|
||||
the test directory to enable them.
|
||||
|
||||
e.g: tools/testing/selftests/android/ion/config
|
||||
|
||||
Test Harness
|
||||
============
|
||||
|
||||
|
|
|
|||
|
|
@ -5,7 +5,8 @@ Device-Mapper's "delay" target delays reads and/or writes
|
|||
and maps them to different devices.
|
||||
|
||||
Parameters:
|
||||
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>]
|
||||
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>
|
||||
[<flush_device> <flush_offset> <flush_delay>]]
|
||||
|
||||
With separate write parameters, the first set is only used for reads.
|
||||
Offsets are specified in sectors.
|
||||
|
|
|
|||
|
|
@ -113,6 +113,10 @@ internal_hash:algorithm(:key) (the key is optional)
|
|||
from an upper layer target, such as dm-crypt. The upper layer
|
||||
target should check the validity of the integrity tags.
|
||||
|
||||
recalculate
|
||||
Recalculate the integrity tags automatically. It is only valid
|
||||
when using internal hash.
|
||||
|
||||
journal_crypt:algorithm(:key) (the key is optional)
|
||||
Encrypt the journal using given algorithm to make sure that the
|
||||
attacker can't read the journal. You can use a block cipher here
|
||||
|
|
|
|||
|
|
@ -28,17 +28,18 @@ administrator some freedom, for example to:
|
|||
Status
|
||||
======
|
||||
|
||||
These targets are very much still in the EXPERIMENTAL state. Please
|
||||
do not yet rely on them in production. But do experiment and offer us
|
||||
feedback. Different use cases will have different performance
|
||||
characteristics, for example due to fragmentation of the data volume.
|
||||
These targets are considered safe for production use. But different use
|
||||
cases will have different performance characteristics, for example due
|
||||
to fragmentation of the data volume.
|
||||
|
||||
If you find this software is not performing as expected please mail
|
||||
dm-devel@redhat.com with details and we'll try our best to improve
|
||||
things for you.
|
||||
|
||||
Userspace tools for checking and repairing the metadata are under
|
||||
development.
|
||||
Userspace tools for checking and repairing the metadata have been fully
|
||||
developed and are available as 'thin_check' and 'thin_repair'. The name
|
||||
of the package that provides these utilities varies by distribution (on
|
||||
a Red Hat distribution it is named 'device-mapper-persistent-data').
|
||||
|
||||
Cookbook
|
||||
========
|
||||
|
|
@ -280,7 +281,7 @@ ii) Status
|
|||
<transaction id> <used metadata blocks>/<total metadata blocks>
|
||||
<used data blocks>/<total data blocks> <held metadata root>
|
||||
ro|rw|out_of_data_space [no_]discard_passdown [error|queue]_if_no_space
|
||||
needs_check|-
|
||||
needs_check|- metadata_low_watermark
|
||||
|
||||
transaction id:
|
||||
A 64-bit number used by userspace to help synchronise with metadata
|
||||
|
|
@ -327,6 +328,11 @@ ii) Status
|
|||
thin-pool can be made fully operational again. '-' indicates
|
||||
needs_check is not set.
|
||||
|
||||
metadata_low_watermark:
|
||||
Value of metadata low watermark in blocks. The kernel sets this
|
||||
value internally but userspace needs to know this value to
|
||||
determine if an event was caused by crossing this threshold.
|
||||
|
||||
iii) Messages
|
||||
|
||||
create_thin <dev id>
|
||||
|
|
|
|||
|
|
@ -1,7 +0,0 @@
|
|||
Adapteva Platforms Device Tree Bindings
|
||||
---------------------------------------
|
||||
|
||||
Parallella board
|
||||
|
||||
Required root node properties:
|
||||
- compatible = "adapteva,parallella";
|
||||
|
|
@ -41,6 +41,14 @@ Boards with the Amlogic Meson GXL S905D SoC shall have the following properties:
|
|||
Required root node property:
|
||||
compatible: "amlogic,s905d", "amlogic,meson-gxl";
|
||||
|
||||
Boards with the Amlogic Meson GXL S805X SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,s805x", "amlogic,meson-gxl";
|
||||
|
||||
Boards with the Amlogic Meson GXL S905W SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,s905w", "amlogic,meson-gxl";
|
||||
|
||||
Boards with the Amlogic Meson GXM S912 SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,s912", "amlogic,meson-gxm";
|
||||
|
|
@ -79,6 +87,11 @@ Board compatible values (alphabetically, grouped by SoC):
|
|||
- "amlogic,p230" (Meson gxl s905d)
|
||||
- "amlogic,p231" (Meson gxl s905d)
|
||||
|
||||
- "amlogic,p241" (Meson gxl s805x)
|
||||
|
||||
- "amlogic,p281" (Meson gxl s905w)
|
||||
- "oranth,tx3-mini" (Meson gxl s905w)
|
||||
|
||||
- "amlogic,q200" (Meson gxm s912)
|
||||
- "amlogic,q201" (Meson gxm s912)
|
||||
- "khadas,vim2" (Meson gxm s912)
|
||||
|
|
|
|||
|
|
@ -1,14 +0,0 @@
|
|||
* Power Management Controller (PMC)
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "atmel,<chip>-pmc".
|
||||
<chip> can be: at91rm9200, at91sam9260, at91sam9g45, at91sam9n12,
|
||||
at91sam9x5, sama5d3
|
||||
|
||||
- reg: Should contain PMC registers location and length
|
||||
|
||||
Examples:
|
||||
pmc: pmc@fffffc00 {
|
||||
compatible = "atmel,at91rm9200-pmc";
|
||||
reg = <0xfffffc00 0x100>;
|
||||
};
|
||||
|
|
@ -189,7 +189,11 @@ Power-Down (SRPD), among other things.
|
|||
|
||||
Required properties:
|
||||
- compatible : should contain one of these
|
||||
"brcm,brcmstb-memc-ddr-rev-b.2.1"
|
||||
"brcm,brcmstb-memc-ddr-rev-b.2.2"
|
||||
"brcm,brcmstb-memc-ddr-rev-b.2.3"
|
||||
"brcm,brcmstb-memc-ddr-rev-b.3.0"
|
||||
"brcm,brcmstb-memc-ddr-rev-b.3.1"
|
||||
"brcm,brcmstb-memc-ddr"
|
||||
- reg : the MEMC DDR register range
|
||||
|
||||
|
|
|
|||
|
|
@ -39,6 +39,8 @@ its hardware characteristcs.
|
|||
|
||||
- System Trace Macrocell:
|
||||
"arm,coresight-stm", "arm,primecell"; [1]
|
||||
- Coresight Address Translation Unit (CATU)
|
||||
"arm,coresight-catu", "arm,primecell";
|
||||
|
||||
* reg: physical base address and length of the register
|
||||
set(s) of the component.
|
||||
|
|
@ -84,8 +86,15 @@ its hardware characteristcs.
|
|||
* Optional property for TMC:
|
||||
|
||||
* arm,buffer-size: size of contiguous buffer space for TMC ETR
|
||||
(embedded trace router)
|
||||
(embedded trace router). This property is obsolete. The buffer size
|
||||
can be configured dynamically via buffer_size property in sysfs.
|
||||
|
||||
* arm,scatter-gather: boolean. Indicates that the TMC-ETR can safely
|
||||
use the SG mode on this system.
|
||||
|
||||
* Optional property for CATU :
|
||||
* interrupts : Exactly one SPI may be listed for reporting the address
|
||||
error
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -118,6 +127,35 @@ Example:
|
|||
};
|
||||
};
|
||||
|
||||
etr@20070000 {
|
||||
compatible = "arm,coresight-tmc", "arm,primecell";
|
||||
reg = <0 0x20070000 0 0x1000>;
|
||||
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* input port */
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
etr_in_port: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&replicator2_out_port0>;
|
||||
};
|
||||
};
|
||||
|
||||
/* CATU link represented by output port */
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
etr_out_port: endpoint {
|
||||
remote-endpoint = <&catu_in_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
2. Links
|
||||
replicator {
|
||||
/* non-configurable replicators don't show up on the
|
||||
|
|
@ -247,5 +285,23 @@ Example:
|
|||
};
|
||||
};
|
||||
|
||||
5. CATU
|
||||
|
||||
catu@207e0000 {
|
||||
compatible = "arm,coresight-catu", "arm,primecell";
|
||||
reg = <0 0x207e0000 0 0x1000>;
|
||||
|
||||
clocks = <&oscclk6a>;
|
||||
clock-names = "apb_pclk";
|
||||
|
||||
interrupts = <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>;
|
||||
port {
|
||||
catu_in_port: endpoint {
|
||||
slave-mode;
|
||||
remote-endpoint = <&etr_out_port>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
[1]. There is currently two version of STM: STM32 and STM500. Both
|
||||
have the same HW interface and as such don't need an explicit binding name.
|
||||
|
|
|
|||
|
|
@ -94,7 +94,7 @@ cpus {
|
|||
};
|
||||
|
||||
idle-states {
|
||||
entry-method = "arm,psci";
|
||||
entry-method = "psci";
|
||||
|
||||
CPU_SLEEP_0: cpu-sleep-0 {
|
||||
compatible = "arm,idle-state";
|
||||
|
|
|
|||
|
|
@ -183,6 +183,7 @@ described below.
|
|||
"marvell,sheeva-v5"
|
||||
"nvidia,tegra132-denver"
|
||||
"nvidia,tegra186-denver"
|
||||
"nvidia,tegra194-carmel"
|
||||
"qcom,krait"
|
||||
"qcom,kryo"
|
||||
"qcom,kryo385"
|
||||
|
|
@ -219,6 +220,7 @@ described below.
|
|||
"qcom,kpss-acc-v1"
|
||||
"qcom,kpss-acc-v2"
|
||||
"renesas,apmu"
|
||||
"renesas,r9a06g032-smp"
|
||||
"rockchip,rk3036-smp"
|
||||
"rockchip,rk3066-smp"
|
||||
"ste,dbx500-smp"
|
||||
|
|
|
|||
|
|
@ -18,9 +18,6 @@ Required properties:
|
|||
assignment of the interrupt router is required.
|
||||
Flags get passed only when using GIC as parent. Flags
|
||||
encoding as documented by the GIC bindings.
|
||||
- interrupt-parent: Should be the phandle for the interrupt controller of
|
||||
the CPU the device tree is intended to be used on. This
|
||||
is either the node of the GIC or NVIC controller.
|
||||
|
||||
Example:
|
||||
mscm_ir: interrupt-controller@40001800 {
|
||||
|
|
|
|||
|
|
@ -0,0 +1,12 @@
|
|||
* Freescale Multi Master Multi Memory Interface (M4IF) module
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "fsl,imx51-m4if"
|
||||
- reg : Address and length of the register set for the device
|
||||
|
||||
Example:
|
||||
|
||||
m4if: m4if@83fd8000 {
|
||||
compatible = "fsl,imx51-m4if";
|
||||
reg = <0x83fd8000 0x1000>;
|
||||
};
|
||||
|
|
@ -0,0 +1,12 @@
|
|||
* Freescale Tigerp platform module
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "fsl,imx51-tigerp"
|
||||
- reg : Address and length of the register set for the device
|
||||
|
||||
Example:
|
||||
|
||||
tigerp: tigerp@83fa0000 {
|
||||
compatible = "fsl,imx51-tigerp";
|
||||
reg = <0x83fa0000 0x28>;
|
||||
};
|
||||
|
|
@ -53,6 +53,10 @@ i.MX6 Quad SABRE Automotive Board
|
|||
Required root node properties:
|
||||
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
|
||||
|
||||
i.MX6SLL EVK board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,imx6sll-evk", "fsl,imx6sll";
|
||||
|
||||
Generic i.MX boards
|
||||
-------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -237,8 +237,8 @@ processor idle states, defined as device tree nodes, are listed.
|
|||
Value type: <stringlist>
|
||||
Usage and definition depend on ARM architecture version.
|
||||
# On ARM v8 64-bit this property is required and must
|
||||
be one of:
|
||||
- "psci" (see bindings in [2])
|
||||
be:
|
||||
- "psci"
|
||||
# On ARM 32-bit systems this property is optional
|
||||
|
||||
The nodes describing the idle states (state) can only be defined within the
|
||||
|
|
|
|||
|
|
@ -1,8 +0,0 @@
|
|||
* Insignal's Exynos4210 based Origen evaluation board
|
||||
|
||||
Origen low-cost evaluation board is based on Samsung's Exynos4210 SoC.
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following.
|
||||
(a) "samsung,smdkv310" - for Samsung's SMDKV310 eval board.
|
||||
(b) "samsung,exynos4210" - for boards based on Exynos4210 SoC.
|
||||
|
|
@ -2,14 +2,17 @@ Marvell Armada AP806 System Controller
|
|||
======================================
|
||||
|
||||
The AP806 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
||||
SoCs. It contains a system controller, which provides a number
|
||||
registers giving access to numerous features: clocks, pin-muxing and
|
||||
many other SoC configuration items. This DT binding allows to describe
|
||||
this system controller.
|
||||
SoCs. It contains system controllers, which provide several registers
|
||||
giving access to numerous features: clocks, pin-muxing and many other
|
||||
SoC configuration items. This DT binding allows to describe these
|
||||
system controllers.
|
||||
|
||||
For the top level node:
|
||||
- compatible: must be: "syscon", "simple-mfd";
|
||||
- reg: register area of the AP806 system controller
|
||||
- reg: register area of the AP806 system controller
|
||||
|
||||
SYSTEM CONTROLLER 0
|
||||
===================
|
||||
|
||||
Clocks:
|
||||
-------
|
||||
|
|
@ -98,3 +101,38 @@ ap_syscon: system-controller@6f4000 {
|
|||
gpio-ranges = <&ap_pinctrl 0 0 19>;
|
||||
};
|
||||
};
|
||||
|
||||
SYSTEM CONTROLLER 1
|
||||
===================
|
||||
|
||||
Thermal:
|
||||
--------
|
||||
|
||||
For common binding part and usage, refer to
|
||||
Documentation/devicetree/bindings/thermal/thermal.txt
|
||||
|
||||
The thermal IP can probe the temperature all around the processor. It
|
||||
may feature several channels, each of them wired to one sensor.
|
||||
|
||||
Required properties:
|
||||
- compatible: must be one of:
|
||||
* marvell,armada-ap806-thermal
|
||||
- reg: register range associated with the thermal functions.
|
||||
|
||||
Optional properties:
|
||||
- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
|
||||
to this IP and represents the channel ID. There is one sensor per
|
||||
channel. O refers to the thermal IP internal channel, while positive
|
||||
IDs refer to each CPU.
|
||||
|
||||
Example:
|
||||
ap_syscon1: system-controller@6f8000 {
|
||||
compatible = "syscon", "simple-mfd";
|
||||
reg = <0x6f8000 0x1000>;
|
||||
|
||||
ap_thermal: thermal-sensor@80 {
|
||||
compatible = "marvell,armada-ap806-thermal";
|
||||
reg = <0x80 0x10>;
|
||||
#thermal-sensor-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -33,3 +33,18 @@ nb_pm: syscon@14000 {
|
|||
compatible = "marvell,armada-3700-nb-pm", "syscon";
|
||||
reg = <0x14000 0x60>;
|
||||
}
|
||||
|
||||
AVS
|
||||
---
|
||||
|
||||
For AVS an other component is needed:
|
||||
|
||||
Required properties:
|
||||
- compatible : should contain "marvell,armada-3700-avs", "syscon";
|
||||
- reg : the register start and length for the AVS
|
||||
|
||||
Example:
|
||||
avs: avs@11500 {
|
||||
compatible = "marvell,armada-3700-avs", "syscon";
|
||||
reg = <0x11500 0x40>;
|
||||
}
|
||||
|
|
|
|||
|
|
@ -1,15 +1,18 @@
|
|||
Marvell Armada CP110 System Controller 0
|
||||
========================================
|
||||
Marvell Armada CP110 System Controller
|
||||
======================================
|
||||
|
||||
The CP110 is one of the two core HW blocks of the Marvell Armada 7K/8K
|
||||
SoCs. It contains two sets of system control registers, System
|
||||
Controller 0 and System Controller 1. This Device Tree binding allows
|
||||
to describe the first system controller, which provides registers to
|
||||
configure various aspects of the SoC.
|
||||
SoCs. It contains system controllers, which provide several registers
|
||||
giving access to numerous features: clocks, pin-muxing and many other
|
||||
SoC configuration items. This DT binding allows to describe these
|
||||
system controllers.
|
||||
|
||||
For the top level node:
|
||||
- compatible: must be: "syscon", "simple-mfd";
|
||||
- reg: register area of the CP110 system controller 0
|
||||
- reg: register area of the CP110 system controller
|
||||
|
||||
SYSTEM CONTROLLER 0
|
||||
===================
|
||||
|
||||
Clocks:
|
||||
-------
|
||||
|
|
@ -163,26 +166,60 @@ Required properties:
|
|||
|
||||
Example:
|
||||
|
||||
cpm_syscon0: system-controller@440000 {
|
||||
CP110_LABEL(syscon0): system-controller@440000 {
|
||||
compatible = "syscon", "simple-mfd";
|
||||
reg = <0x440000 0x1000>;
|
||||
|
||||
cpm_clk: clock {
|
||||
CP110_LABEL(clk): clock {
|
||||
compatible = "marvell,cp110-clock";
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
cpm_pinctrl: pinctrl {
|
||||
CP110_LABEL(pinctrl): pinctrl {
|
||||
compatible = "marvell,armada-8k-cpm-pinctrl";
|
||||
};
|
||||
|
||||
cpm_gpio1: gpio@100 {
|
||||
CP110_LABEL(gpio1): gpio@100 {
|
||||
compatible = "marvell,armada-8k-gpio";
|
||||
offset = <0x100>;
|
||||
ngpios = <32>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
gpio-ranges = <&cpm_pinctrl 0 0 32>;
|
||||
gpio-ranges = <&CP110_LABEL(pinctrl) 0 0 32>;
|
||||
};
|
||||
|
||||
};
|
||||
|
||||
SYSTEM CONTROLLER 1
|
||||
===================
|
||||
|
||||
Thermal:
|
||||
--------
|
||||
|
||||
The thermal IP can probe the temperature all around the processor. It
|
||||
may feature several channels, each of them wired to one sensor.
|
||||
|
||||
For common binding part and usage, refer to
|
||||
Documentation/devicetree/bindings/thermal/thermal.txt
|
||||
|
||||
Required properties:
|
||||
- compatible: must be one of:
|
||||
* marvell,armada-cp110-thermal
|
||||
- reg: register range associated with the thermal functions.
|
||||
|
||||
Optional properties:
|
||||
- #thermal-sensor-cells: shall be <1> when thermal-zones subnodes refer
|
||||
to this IP and represents the channel ID. There is one sensor per
|
||||
channel. O refers to the thermal IP internal channel.
|
||||
|
||||
Example:
|
||||
CP110_LABEL(syscon1): system-controller@6f8000 {
|
||||
compatible = "syscon", "simple-mfd";
|
||||
reg = <0x6f8000 0x1000>;
|
||||
|
||||
CP110_LABEL(thermal): thermal-sensor@70 {
|
||||
compatible = "marvell,armada-cp110-thermal";
|
||||
reg = <0x70 0x10>;
|
||||
#thermal-sensor-cells = <1>;
|
||||
};
|
||||
};
|
||||
|
|
@ -11,6 +11,7 @@ compatible: Must contain one of
|
|||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
"mediatek,mt6755"
|
||||
"mediatek,mt6765"
|
||||
"mediatek,mt6795"
|
||||
"mediatek,mt6797"
|
||||
"mediatek,mt7622"
|
||||
|
|
@ -41,12 +42,18 @@ Supported boards:
|
|||
- Evaluation phone for MT6755(Helio P10):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6755-evb", "mediatek,mt6755";
|
||||
- Evaluation board for MT6765(Helio P22):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6765-evb", "mediatek,mt6765";
|
||||
- Evaluation board for MT6795(Helio X10):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
|
||||
- Evaluation board for MT6797(Helio X20):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6797-evb", "mediatek,mt6797";
|
||||
- Mediatek X20 Development Board:
|
||||
Required root node properties:
|
||||
- compatible = "archermind,mt6797-x20-dev", "mediatek,mt6797";
|
||||
- Reference board variant 1 for MT7622:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt7622-rfb1", "mediatek,mt7622";
|
||||
|
|
@ -59,9 +66,6 @@ Supported boards:
|
|||
- Reference board for MT7623n with eMMC:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt7623n-rfb-emmc", "mediatek,mt7623";
|
||||
- Reference board for MT7623n with NAND:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt7623n-rfb-nand", "mediatek,mt7623";
|
||||
- Bananapi BPI-R2 board:
|
||||
- compatible = "bananapi,bpi-r2", "mediatek,mt7623";
|
||||
- MTK mt8127 tablet moose EVB:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,26 @@
|
|||
== Introduction==
|
||||
|
||||
LLCC (Last Level Cache Controller) provides last level of cache memory in SOC,
|
||||
that can be shared by multiple clients. Clients here are different cores in the
|
||||
SOC, the idea is to minimize the local caches at the clients and migrate to
|
||||
common pool of memory. Cache memory is divided into partitions called slices
|
||||
which are assigned to clients. Clients can query the slice details, activate
|
||||
and deactivate them.
|
||||
|
||||
Properties:
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be "qcom,sdm845-llcc"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value Type: <prop-encoded-array>
|
||||
Definition: Start address and the the size of the register region.
|
||||
|
||||
Example:
|
||||
|
||||
cache-controller@1100000 {
|
||||
compatible = "qcom,sdm845-llcc";
|
||||
reg = <0x1100000 0x250000>;
|
||||
};
|
||||
|
|
@ -10,7 +10,6 @@ Required properties:
|
|||
- compatible : Should be "ti,irq-crossbar"
|
||||
- reg: Base address and the size of the crossbar registers.
|
||||
- interrupt-controller: indicates that this block is an interrupt controller.
|
||||
- interrupt-parent: the interrupt controller this block is connected to.
|
||||
- ti,max-irqs: Total number of irqs available at the parent interrupt controller.
|
||||
- ti,max-crossbar-sources: Maximum number of crossbar sources that can be routed.
|
||||
- ti,reg-size: Size of a individual register in bytes. Every individual
|
||||
|
|
|
|||
|
|
@ -7,6 +7,7 @@ Required properties:
|
|||
Should be "ti,omap2-l4-wkup" for OMAP2 family l4 wkup bus
|
||||
Should be "ti,omap3-l4-core" for OMAP3 family l4 core bus
|
||||
Should be "ti,omap4-l4-cfg" for OMAP4 family l4 cfg bus
|
||||
Should be "ti,omap4-l4-per" for OMAP4 family l4 per bus
|
||||
Should be "ti,omap4-l4-wkup" for OMAP4 family l4 wkup bus
|
||||
Should be "ti,omap5-l4-cfg" for OMAP5 family l4 cfg bus
|
||||
Should be "ti,omap5-l4-wkup" for OMAP5 family l4 wkup bus
|
||||
|
|
@ -15,11 +16,21 @@ Required properties:
|
|||
Should be "ti,am3-l4-wkup" for AM33xx family l4 wkup bus
|
||||
Should be "ti,am4-l4-wkup" for AM43xx family l4 wkup bus
|
||||
- ranges : contains the IO map range for the bus
|
||||
- reg : registers link agent and interconnect agent and access protection
|
||||
- reg-names : "la" for link agent, "ia0" to "ia3" for one to three
|
||||
interconnect agent instances, "ap" for access if it exists
|
||||
|
||||
Examples:
|
||||
|
||||
l4: l4@48000000 {
|
||||
compatible "ti,omap2-l4", "simple-bus";
|
||||
l4: interconnect@48000000 {
|
||||
compatible "ti,omap4-l4-per", "simple-bus";
|
||||
reg = <0x48000000 0x800>,
|
||||
<0x48000800 0x800>,
|
||||
<0x48001000 0x400>,
|
||||
<0x48001400 0x400>,
|
||||
<0x48001800 0x400>,
|
||||
<0x48001c00 0x400>;
|
||||
reg-names = "ap", "la", "ia0", "ia1", "ia2", "ia3";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges = <0 0x48000000 0x100000>;
|
||||
|
|
|
|||
|
|
@ -1,5 +1,10 @@
|
|||
Rockchip platforms device tree bindings
|
||||
---------------------------------------
|
||||
|
||||
- 96boards RK3399 Ficus (ROCK960 Enterprise Edition)
|
||||
Required root node properties:
|
||||
- compatible = "vamrs,ficus", "rockchip,rk3399";
|
||||
|
||||
- Amarula Vyasa RK3288 board
|
||||
Required root node properties:
|
||||
- compatible = "amarula,vyasa-rk3288", "rockchip,rk3288";
|
||||
|
|
@ -66,6 +71,15 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "geekbuying,geekbox", "rockchip,rk3368";
|
||||
|
||||
- Google Bob (Asus Chromebook Flip C101PA):
|
||||
Required root node properties:
|
||||
compatible = "google,bob-rev13", "google,bob-rev12",
|
||||
"google,bob-rev11", "google,bob-rev10",
|
||||
"google,bob-rev9", "google,bob-rev8",
|
||||
"google,bob-rev7", "google,bob-rev6",
|
||||
"google,bob-rev5", "google,bob-rev4",
|
||||
"google,bob", "google,gru", "rockchip,rk3399";
|
||||
|
||||
- Google Brain (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-brain-rev0", "google,veyron-brain",
|
||||
|
|
|
|||
|
|
@ -40,9 +40,6 @@ following properties:
|
|||
- #interrupt-cells: must be identical to the that of the parent interrupt
|
||||
controller.
|
||||
|
||||
- interrupt-parent: a phandle indicating which interrupt controller
|
||||
this PMU signals interrupts to.
|
||||
|
||||
|
||||
Optional nodes:
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
* Samsung's Exynos SoC based boards
|
||||
* Samsung's Exynos and S5P SoC based boards
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following.
|
||||
- "samsung,aries" - for S5PV210-based Samsung Aries board.
|
||||
- "samsung,fascinate4g" - for S5PV210-based Samsung Galaxy S Fascinate 4G (SGH-T959P) board.
|
||||
- "samsung,galaxys" - for S5PV210-based Samsung Galaxy S (i9000) board.
|
||||
- "samsung,artik5" - for Exynos3250-based Samsung ARTIK5 module.
|
||||
- "samsung,artik5-eval" - for Exynos3250-based Samsung ARTIK5 eval board.
|
||||
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
|
||||
|
|
|
|||
|
|
@ -51,7 +51,8 @@ SoCs:
|
|||
compatible = "renesas,r8a77990"
|
||||
- R-Car D3 (R8A77995)
|
||||
compatible = "renesas,r8a77995"
|
||||
|
||||
- RZ/N1D (R9A06G032)
|
||||
compatible = "renesas,r9a06g032"
|
||||
|
||||
Boards:
|
||||
|
||||
|
|
@ -112,6 +113,8 @@ Boards:
|
|||
compatible = "renesas,porter", "renesas,r8a7791"
|
||||
- RSKRZA1 (YR0K77210C000BE)
|
||||
compatible = "renesas,rskrza1", "renesas,r7s72100"
|
||||
- RZN1D-DB (RZ/N1D Demo Board for the RZ/N1D 400 pins package)
|
||||
compatible = "renesas,rzn1d400-db", "renesas,r9a06g032"
|
||||
- Salvator-X (RTP0RC7795SIPB0010S)
|
||||
compatible = "renesas,salvator-x", "renesas,r8a7795"
|
||||
- Salvator-X (RTP0RC7796SIPB0011S)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
Texas Instruments K3 Multicore SoC architecture device tree bindings
|
||||
--------------------------------------------------------------------
|
||||
|
||||
Platforms based on Texas Instruments K3 Multicore SoC architecture
|
||||
shall follow the following scheme:
|
||||
|
||||
SoCs
|
||||
----
|
||||
|
||||
Each device tree root node must specify which exact SoC in K3 Multicore SoC
|
||||
architecture it uses, using one of the following compatible values:
|
||||
|
||||
- AM654
|
||||
compatible = "ti,am654";
|
||||
|
||||
Boards
|
||||
------
|
||||
|
||||
In addition, each device tree root node must specify which one or more
|
||||
of the following board-specific compatible values:
|
||||
|
||||
- AM654 EVM
|
||||
compatible = "ti,am654-evm", "ti,am654";
|
||||
|
|
@ -8,18 +8,38 @@ Required root node properties:
|
|||
|
||||
Additional compatible strings:
|
||||
|
||||
- Xilinx internal board cc108
|
||||
- Adapteva Parallella board
|
||||
"adapteva,parallella"
|
||||
|
||||
- Avnet MicroZed board
|
||||
"avnet,zynq-microzed"
|
||||
"xlnx,zynq-microzed"
|
||||
|
||||
- Avnet ZedBoard board
|
||||
"avnet,zynq-zed"
|
||||
"xlnx,zynq-zed"
|
||||
|
||||
- Digilent Zybo board
|
||||
"digilent,zynq-zybo"
|
||||
|
||||
- Digilent Zybo Z7 board
|
||||
"digilent,zynq-zybo-z7"
|
||||
|
||||
- Xilinx CC108 internal board
|
||||
"xlnx,zynq-cc108"
|
||||
|
||||
- Xilinx internal board zc770 with different FMC cards
|
||||
- Xilinx ZC702 internal board
|
||||
"xlnx,zynq-zc702"
|
||||
|
||||
- Xilinx ZC706 internal board
|
||||
"xlnx,zynq-zc706"
|
||||
|
||||
- Xilinx ZC770 internal board, with different FMC cards
|
||||
"xlnx,zynq-zc770-xm010"
|
||||
"xlnx,zynq-zc770-xm011"
|
||||
"xlnx,zynq-zc770-xm012"
|
||||
"xlnx,zynq-zc770-xm013"
|
||||
|
||||
- Digilent Zybo Z7 board
|
||||
"digilent,zynq-zybo-z7"
|
||||
|
||||
---------------------------------------------------------------
|
||||
|
||||
Xilinx Zynq UltraScale+ MPSoC Platforms Device Tree Bindings
|
||||
|
|
|
|||
|
|
@ -17,7 +17,6 @@ Required properties:
|
|||
- "marvell,armada-380-ahci"
|
||||
- "marvell,armada-3700-ahci"
|
||||
- "snps,dwc-ahci"
|
||||
- "snps,exynos5440-ahci"
|
||||
- "snps,spear-ahci"
|
||||
- "generic-ahci"
|
||||
- interrupts : <interrupt mapping for SATA IRQ>
|
||||
|
|
@ -30,6 +29,7 @@ compatible:
|
|||
Optional properties:
|
||||
- dma-coherent : Present if dma operations are coherent
|
||||
- clocks : a list of phandle + clock specifier pairs
|
||||
- resets : a list of phandle + reset specifier pairs
|
||||
- target-supply : regulator for SATA target power
|
||||
- phys : reference to the SATA PHY node
|
||||
- phy-names : must be "sata-phy"
|
||||
|
|
|
|||
|
|
@ -16,7 +16,6 @@ Required properties:
|
|||
4 for controller @ 0x1b000
|
||||
|
||||
Optional properties:
|
||||
- interrupt-parent : optional, if needed for interrupt mapping
|
||||
- reg : <registers mapping>
|
||||
|
||||
Example:
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue