mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2025-01-01 10:45:49 +00:00
Merge drm/drm-next into drm-misc-next
Get drm-misc-next to the state of v6.11-rc2. Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>
This commit is contained in:
Thomas Zimmermann
commit
5c61f59824
@ -4,7 +4,7 @@
|
||||
#
|
||||
# For more information, see:
|
||||
#
|
||||
# Documentation/process/clang-format.rst
|
||||
# Documentation/dev-tools/clang-format.rst
|
||||
# https://clang.llvm.org/docs/ClangFormat.html
|
||||
# https://clang.llvm.org/docs/ClangFormatStyleOptions.html
|
||||
#
|
||||
|
||||
6
.gitignore
vendored
6
.gitignore
vendored
@ -92,6 +92,12 @@ modules.order
|
||||
#
|
||||
/tar-install/
|
||||
|
||||
#
|
||||
# pacman files (make pacman-pkg)
|
||||
#
|
||||
/PKGBUILD
|
||||
/pacman/
|
||||
|
||||
#
|
||||
# We don't want to ignore the following even if they are dot-files
|
||||
#
|
||||
|
||||
6
.mailmap
6
.mailmap
@ -260,6 +260,7 @@ Jaegeuk Kim <jaegeuk@kernel.org> <jaegeuk@motorola.com>
|
||||
Jakub Kicinski <kuba@kernel.org> <jakub.kicinski@netronome.com>
|
||||
James Bottomley <jejb@mulgrave.(none)>
|
||||
James Bottomley <jejb@titanic.il.steeleye.com>
|
||||
James Clark <james.clark@linaro.org> <james.clark@arm.com>
|
||||
James E Wilson <wilson@specifix.com>
|
||||
James Hogan <jhogan@kernel.org> <james@albanarts.com>
|
||||
James Hogan <jhogan@kernel.org> <james.hogan@imgtec.com>
|
||||
@ -384,7 +385,9 @@ Li Yang <leoyang.li@nxp.com> <leoli@freescale.com>
|
||||
Li Yang <leoyang.li@nxp.com> <leo@zh-kernel.org>
|
||||
Lior David <quic_liord@quicinc.com> <liord@codeaurora.org>
|
||||
Lorenzo Pieralisi <lpieralisi@kernel.org> <lorenzo.pieralisi@arm.com>
|
||||
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> <lstoakes@gmail.com>
|
||||
Luca Ceresoli <luca.ceresoli@bootlin.com> <luca@lucaceresoli.net>
|
||||
Luca Weiss <luca@lucaweiss.eu> <luca@z3ntu.xyz>
|
||||
Lukasz Luba <lukasz.luba@arm.com> <l.luba@partner.samsung.com>
|
||||
Luo Jie <quic_luoj@quicinc.com> <luoj@codeaurora.org>
|
||||
Maciej W. Rozycki <macro@mips.com> <macro@imgtec.com>
|
||||
@ -472,6 +475,8 @@ Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <n-horiguchi@ah.jp.nec.com>
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <naoya.horiguchi@nec.com>
|
||||
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
|
||||
Naveen N Rao <naveen@kernel.org> <naveen.n.rao@linux.ibm.com>
|
||||
Naveen N Rao <naveen@kernel.org> <naveen.n.rao@linux.vnet.ibm.com>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <quic_neeraju@quicinc.com>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <neeraju@codeaurora.org>
|
||||
Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com>
|
||||
@ -689,6 +694,7 @@ Vivien Didelot <vivien.didelot@gmail.com> <vivien.didelot@savoirfairelinux.com>
|
||||
Vlad Dogaru <ddvlad@gmail.com> <vlad.dogaru@intel.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@parallels.com>
|
||||
Vladimir Davydov <vdavydov.dev@gmail.com> <vdavydov@virtuozzo.com>
|
||||
Weiwen Hu <huweiwen@linux.alibaba.com> <sehuww@mail.scut.edu.cn>
|
||||
WeiXiong Liao <gmpy.liaowx@gmail.com> <liaoweixiong@allwinnertech.com>
|
||||
Wen Gong <quic_wgong@quicinc.com> <wgong@codeaurora.org>
|
||||
Wesley Cheng <quic_wcheng@quicinc.com> <wcheng@codeaurora.org>
|
||||
|
||||
24
CREDITS
24
CREDITS
@ -531,6 +531,13 @@ S: Kopmansg 2
|
||||
S: 411 13 Goteborg
|
||||
S: Sweden
|
||||
|
||||
N: Daniel Bristot de Oliveira
|
||||
D: Scheduler contributions, notably: SCHED_DEADLINE
|
||||
D: Real-time Linux Analysis
|
||||
D: Runtime Verification
|
||||
D: OS Noise and Latency Tracers
|
||||
S: Brazil and Italy
|
||||
|
||||
N: Paul Bristow
|
||||
E: paul@paulbristow.net
|
||||
W: https://paulbristow.net/linux/idefloppy.html
|
||||
@ -796,6 +803,11 @@ E: luisfcorreia@gmail.com
|
||||
D: Ralink rt2x00 WLAN driver
|
||||
S: Belas, Portugal
|
||||
|
||||
N: Benoît Cousson
|
||||
E: bcousson@baylibre.com
|
||||
D: TI OMAP Devicetree platforms
|
||||
D: TI OMAP HWMOD boards
|
||||
|
||||
N: Alan Cox
|
||||
W: http://www.linux.org.uk/diary/
|
||||
D: Linux Networking (0.99.10->2.0.29)
|
||||
@ -1214,6 +1226,10 @@ D: UDF filesystem
|
||||
S: (ask for current address)
|
||||
S: USA
|
||||
|
||||
N: Larry Finger
|
||||
E: Larry.Finger@lwfinger.net
|
||||
D: Maintainer of wireless drivers, too many to list here
|
||||
|
||||
N: Jürgen Fischer
|
||||
E: fischer@norbit.de
|
||||
D: Author of Adaptec AHA-152x SCSI driver
|
||||
@ -3146,9 +3162,11 @@ S: Triftstra=DFe 55
|
||||
S: 13353 Berlin
|
||||
S: Germany
|
||||
|
||||
N: Gustavo Pimental
|
||||
N: Gustavo Pimentel
|
||||
E: gustavo.pimentel@synopsys.com
|
||||
D: PCI driver for Synopsys DesignWare
|
||||
D: Synopsys DesignWare eDMA driver
|
||||
D: Synopsys DesignWare xData traffic generator
|
||||
|
||||
N: Emanuel Pirker
|
||||
E: epirker@edu.uni-klu.ac.at
|
||||
@ -4362,6 +4380,10 @@ N: Haojian Zhuang
|
||||
E: haojian.zhuang@gmail.com
|
||||
D: MMP support
|
||||
|
||||
N: Tsahee Zidenberg
|
||||
E: tsahee@annapurnalabs.com
|
||||
D: Annapurna Labs Alpine Architecture
|
||||
|
||||
N: Richard Zidlicky
|
||||
E: rz@linux-m68k.org, rdzidlic@geocities.com
|
||||
W: http://www.geocities.com/rdzidlic
|
||||
|
||||
@ -21,6 +21,59 @@ Description:
|
||||
device is offset from the internal allocation unit's
|
||||
natural alignment.
|
||||
|
||||
What: /sys/block/<disk>/atomic_write_max_bytes
|
||||
Date: February 2024
|
||||
Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
|
||||
Description:
|
||||
[RO] This parameter specifies the maximum atomic write
|
||||
size reported by the device. This parameter is relevant
|
||||
for merging of writes, where a merged atomic write
|
||||
operation must not exceed this number of bytes.
|
||||
This parameter may be greater than the value in
|
||||
atomic_write_unit_max_bytes as
|
||||
atomic_write_unit_max_bytes will be rounded down to a
|
||||
power-of-two and atomic_write_unit_max_bytes may also be
|
||||
limited by some other queue limits, such as max_segments.
|
||||
This parameter - along with atomic_write_unit_min_bytes
|
||||
and atomic_write_unit_max_bytes - will not be larger than
|
||||
max_hw_sectors_kb, but may be larger than max_sectors_kb.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/atomic_write_unit_min_bytes
|
||||
Date: February 2024
|
||||
Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
|
||||
Description:
|
||||
[RO] This parameter specifies the smallest block which can
|
||||
be written atomically with an atomic write operation. All
|
||||
atomic write operations must begin at a
|
||||
atomic_write_unit_min boundary and must be multiples of
|
||||
atomic_write_unit_min. This value must be a power-of-two.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/atomic_write_unit_max_bytes
|
||||
Date: February 2024
|
||||
Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
|
||||
Description:
|
||||
[RO] This parameter defines the largest block which can be
|
||||
written atomically with an atomic write operation. This
|
||||
value must be a multiple of atomic_write_unit_min and must
|
||||
be a power-of-two. This value will not be larger than
|
||||
atomic_write_max_bytes.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/atomic_write_boundary_bytes
|
||||
Date: February 2024
|
||||
Contact: Himanshu Madhani <himanshu.madhani@oracle.com>
|
||||
Description:
|
||||
[RO] A device may need to internally split an atomic write I/O
|
||||
which straddles a given logical block address boundary. This
|
||||
parameter specifies the size in bytes of the atomic boundary if
|
||||
one is reported by the device. This value must be a
|
||||
power-of-two and at least the size as in
|
||||
atomic_write_unit_max_bytes.
|
||||
Any attempt to merge atomic write I/Os must not result in a
|
||||
merged I/O which crosses this boundary (if any).
|
||||
|
||||
|
||||
What: /sys/block/<disk>/diskseq
|
||||
Date: February 2021
|
||||
|
||||
@ -1,6 +1,23 @@
|
||||
What: /sys/bus/nvmem/devices/.../force_ro
|
||||
Date: June 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Vasut <marex@denx.de>
|
||||
Description:
|
||||
This read/write attribute allows users to set read-write
|
||||
devices as read-only and back to read-write from userspace.
|
||||
This can be used to unlock and relock write-protection of
|
||||
devices which are generally locked, except during sporadic
|
||||
programming operation.
|
||||
Read returns '0' or '1' for read-write or read-only modes
|
||||
respectively.
|
||||
Write parses one of 'YyTt1NnFf0', or [oO][NnFf] for "on"
|
||||
and "off", i.e. what kstrbool() supports.
|
||||
Note: This file is only present if CONFIG_NVMEM_SYSFS
|
||||
is enabled.
|
||||
|
||||
What: /sys/bus/nvmem/devices/.../nvmem
|
||||
Date: July 2015
|
||||
KernelVersion: 4.2
|
||||
KernelVersion: 4.2
|
||||
Contact: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
|
||||
Description:
|
||||
This file allows user to read/write the raw NVMEM contents.
|
||||
@ -20,3 +37,14 @@ Description:
|
||||
...
|
||||
*
|
||||
0001000
|
||||
|
||||
What: /sys/bus/nvmem/devices/.../type
|
||||
Date: November 2018
|
||||
KernelVersion: 5.0
|
||||
Contact: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
||||
Description:
|
||||
This read-only attribute allows user to read the NVMEM
|
||||
device type. Supported types are "Unknown", "EEPROM",
|
||||
"OTP", "Battery backed", "FRAM".
|
||||
Note: This file is only present if CONFIG_NVMEM_SYSFS
|
||||
is enabled.
|
||||
|
||||
@ -3,10 +3,11 @@ Date: April 2005
|
||||
KernelVersion: 2.6.12
|
||||
Contact: Richard Purdie <rpurdie@rpsys.net>
|
||||
Description:
|
||||
Control BACKLIGHT power, values are FB_BLANK_* from fb.h
|
||||
Control BACKLIGHT power, values are compatible with
|
||||
FB_BLANK_* from fb.h
|
||||
|
||||
- FB_BLANK_UNBLANK (0) : power on.
|
||||
- FB_BLANK_POWERDOWN (4) : power off
|
||||
- 0 (FB_BLANK_UNBLANK) : power on.
|
||||
- 4 (FB_BLANK_POWERDOWN) : power off
|
||||
Users: HAL
|
||||
|
||||
What: /sys/class/backlight/<backlight>/brightness
|
||||
|
||||
25
Documentation/ABI/stable/sysfs-driver-misc-cp500
Normal file
25
Documentation/ABI/stable/sysfs-driver-misc-cp500
Normal file
@ -0,0 +1,25 @@
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/0000:XX:XX.X/version
|
||||
Date: June 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Gerhard Engleder <eg@keba.com>
|
||||
Description: Version of the FPGA configuration bitstream as printable string.
|
||||
This file is read only.
|
||||
Users: KEBA
|
||||
|
||||
What: /sys/devices/pciXXXX:XX/0000:XX:XX.X/0000:XX:XX.X/keep_cfg
|
||||
Date: June 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Gerhard Engleder <eg@keba.com>
|
||||
Description: Flag which signals if FPGA shall keep or reload configuration
|
||||
bitstream on reset. Normal FPGA behavior and default is to keep
|
||||
configuration bitstream and to only reset the configured logic.
|
||||
|
||||
Reloading configuration on reset enables an update of the
|
||||
configuration bitstream with a simple reboot. Otherwise it is
|
||||
necessary to power cycle the device to reload the new
|
||||
configuration bitstream.
|
||||
|
||||
This file is read/write. The values are as follows:
|
||||
1 = keep configuration bitstream on reset, default
|
||||
0 = reload configuration bitstream on reset
|
||||
Users: KEBA
|
||||
@ -31,6 +31,18 @@ Description:
|
||||
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
|
||||
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/manifestblob
|
||||
Date: January, 2024
|
||||
KernelVersion: v6.10
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RO) Optional supplemental data that a TSM may emit, visibility
|
||||
of this attribute depends on TSM, and may be empty if no
|
||||
manifest data is available.
|
||||
|
||||
See 'service_provider' for information on the format of the
|
||||
manifest blob.
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/provider
|
||||
Date: September, 2023
|
||||
KernelVersion: v6.7
|
||||
@ -80,3 +92,54 @@ Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RO) Indicates the minimum permissible value that can be written
|
||||
to @privlevel.
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/service_provider
|
||||
Date: January, 2024
|
||||
KernelVersion: v6.10
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(WO) Attribute is visible if a TSM implementation provider
|
||||
supports the concept of attestation reports from a service
|
||||
provider for TVMs, like SEV-SNP running under an SVSM.
|
||||
Specifying the service provider via this attribute will create
|
||||
an attestation report as specified by the service provider.
|
||||
The only currently supported service provider is "svsm".
|
||||
|
||||
For the "svsm" service provider, see the Secure VM Service Module
|
||||
for SEV-SNP Guests v1.00 Section 7. For the doc, search for
|
||||
"site:amd.com "Secure VM Service Module for SEV-SNP
|
||||
Guests", docID: 58019"
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/service_guid
|
||||
Date: January, 2024
|
||||
KernelVersion: v6.10
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(WO) Attribute is visible if a TSM implementation provider
|
||||
supports the concept of attestation reports from a service
|
||||
provider for TVMs, like SEV-SNP running under an SVSM.
|
||||
Specifying an empty/null GUID (00000000-0000-0000-0000-000000)
|
||||
requests all active services within the service provider be
|
||||
part of the attestation report. Specifying a GUID request
|
||||
an attestation report of just the specified service using the
|
||||
manifest form specified by the service_manifest_version
|
||||
attribute.
|
||||
|
||||
See 'service_provider' for information on the format of the
|
||||
service guid.
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/service_manifest_version
|
||||
Date: January, 2024
|
||||
KernelVersion: v6.10
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(WO) Attribute is visible if a TSM implementation provider
|
||||
supports the concept of attestation reports from a service
|
||||
provider for TVMs, like SEV-SNP running under an SVSM.
|
||||
Indicates the service manifest version requested for the
|
||||
attestation report (default 0). If this field is not set by
|
||||
the user, the default manifest version of the service (the
|
||||
service's initial/first manifest version) is returned.
|
||||
|
||||
See 'service_provider' for information on the format of the
|
||||
service manifest version.
|
||||
|
||||
@ -14,9 +14,10 @@ Description:
|
||||
event to its internal Informational Event log, updates the
|
||||
Event Status register, and if configured, interrupts the host.
|
||||
It is not an error to inject poison into an address that
|
||||
already has poison present and no error is returned. The
|
||||
inject_poison attribute is only visible for devices supporting
|
||||
the capability.
|
||||
already has poison present and no error is returned. If the
|
||||
device returns 'Inject Poison Limit Reached' an -EBUSY error
|
||||
is returned to the user. The inject_poison attribute is only
|
||||
visible for devices supporting the capability.
|
||||
|
||||
|
||||
What: /sys/kernel/debug/memX/clear_poison
|
||||
|
||||
@ -29,3 +29,12 @@ Example:
|
||||
echo 0,0x20,0xff > mem_write
|
||||
echo 1,64,64 > mem_write
|
||||
Users: Debugging, any user space test suite
|
||||
|
||||
What: /sys/kernel/debug/tpmi-<n>/plr/domain<n>/status
|
||||
Date: Aug 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Tero Kristo <tero.kristo@linux.intel.com>
|
||||
Description:
|
||||
Shows the currently active Performance Limit Reasons for die level and the
|
||||
individual CPUs under the die. The contents of this file are sticky, and
|
||||
clearing all the statuses can be done by writing "0\n" to this file.
|
||||
|
||||
9
Documentation/ABI/testing/sysfs-bus-auxiliary
Normal file
9
Documentation/ABI/testing/sysfs-bus-auxiliary
Normal file
@ -0,0 +1,9 @@
|
||||
What: /sys/bus/auxiliary/devices/.../irqs/
|
||||
Date: April, 2024
|
||||
Contact: Shay Drory <shayd@nvidia.com>
|
||||
Description:
|
||||
The /sys/devices/.../irqs directory contains a variable set of
|
||||
files, with each file is named as irq number similar to PCI PF
|
||||
or VF's irq number located in msi_irqs directory.
|
||||
These irq files are added and removed dynamically when an IRQ
|
||||
is requested and freed respectively for the PCI SF.
|
||||
113
Documentation/ABI/testing/sysfs-bus-i2c-devices-turris-omnia-mcu
Normal file
113
Documentation/ABI/testing/sysfs-bus-i2c-devices-turris-omnia-mcu
Normal file
@ -0,0 +1,113 @@
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/board_revision
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Contains board revision number.
|
||||
|
||||
Only available if board information is burned in the MCU (older
|
||||
revisions have board information burned in the ATSHA204-A chip).
|
||||
|
||||
Format: %u.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/first_mac_address
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Contains device first MAC address. Each Turris Omnia is
|
||||
allocated 3 MAC addresses. The two additional addresses are
|
||||
computed from the first one by incrementing it.
|
||||
|
||||
Only available if board information is burned in the MCU (older
|
||||
revisions have board information burned in the ATSHA204-A chip).
|
||||
|
||||
Format: %pM.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/front_button_mode
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RW) The front button on the Turris Omnia router can be
|
||||
configured either to change the intensity of all the LEDs on the
|
||||
front panel, or to send the press event to the CPU as an
|
||||
interrupt.
|
||||
|
||||
This file switches between these two modes:
|
||||
- "mcu" makes the button press event be handled by the MCU to
|
||||
change the LEDs panel intensity.
|
||||
- "cpu" makes the button press event be handled by the CPU.
|
||||
|
||||
Format: %s.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/front_button_poweron
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RW) Newer versions of the microcontroller firmware of the
|
||||
Turris Omnia router support powering off the router into true
|
||||
low power mode. The router can be powered on by pressing the
|
||||
front button.
|
||||
|
||||
This file configures whether front button power on is enabled.
|
||||
|
||||
This file is present only if the power off feature is supported
|
||||
by the firmware.
|
||||
|
||||
Format: %i.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/fw_features
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Newer versions of the microcontroller firmware report the
|
||||
features they support. These can be read from this file. If the
|
||||
MCU firmware is too old, this file reads 0x0.
|
||||
|
||||
Format: 0x%x.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/fw_version_hash_application
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Contains the version hash (commit hash) of the application
|
||||
part of the microcontroller firmware.
|
||||
|
||||
Format: %s.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/fw_version_hash_bootloader
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Contains the version hash (commit hash) of the bootloader
|
||||
part of the microcontroller firmware.
|
||||
|
||||
Format: %s.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/mcu_type
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Contains the microcontroller type (STM32, GD32, MKL).
|
||||
|
||||
Format: %s.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/reset_selector
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Contains the selected factory reset level, determined by
|
||||
how long the rear reset button was held by the user during board
|
||||
reset.
|
||||
|
||||
Format: %i.
|
||||
|
||||
What: /sys/bus/i2c/devices/<mcu_device>/serial_number
|
||||
Date: September 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RO) Contains the 64-bit board serial number in hexadecimal
|
||||
format.
|
||||
|
||||
Only available if board information is burned in the MCU (older
|
||||
revisions have board information burned in the ATSHA204-A chip).
|
||||
|
||||
Format: %016X.
|
||||
18
Documentation/ABI/testing/sysfs-bus-iio-inv_icm42600
Normal file
18
Documentation/ABI/testing/sysfs-bus-iio-inv_icm42600
Normal file
@ -0,0 +1,18 @@
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_power_mode
|
||||
KernelVersion: 6.11
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Accelerometer power mode. Setting this attribute will set the
|
||||
requested power mode to use if the ODR support it. If ODR
|
||||
support only 1 mode, power mode will be enforced.
|
||||
Reading this attribute will return the current accelerometer
|
||||
power mode if the sensor is on, or the requested value if the
|
||||
sensor is off. The value between real and requested value can
|
||||
be different for ODR supporting only 1 mode.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_power_mode_available
|
||||
KernelVersion: 6.11
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
List of available accelerometer power modes that can be set in
|
||||
in_accel_power_mode attribute.
|
||||
@ -75,3 +75,13 @@ Description:
|
||||
The default value is 1 (GNU Remote Debug command).
|
||||
Other permissible value is 0 which is for vendor defined debug
|
||||
target.
|
||||
|
||||
What: /sys/bus/pci/drivers/xhci_hcd/.../dbc_poll_interval_ms
|
||||
Date: February 2024
|
||||
Contact: Mathias Nyman <mathias.nyman@linux.intel.com>
|
||||
Description:
|
||||
This attribute adjust the polling interval used to check for
|
||||
DbC events. Unit is milliseconds. Accepted values range from 0
|
||||
up to 5000. The default value is 64 ms.
|
||||
This polling interval is used while DbC is enabled but has no
|
||||
active data transfers.
|
||||
|
||||
81
Documentation/ABI/testing/sysfs-bus-wmi
Normal file
81
Documentation/ABI/testing/sysfs-bus-wmi
Normal file
@ -0,0 +1,81 @@
|
||||
What: /sys/bus/wmi/devices/.../driver_override
|
||||
Date: February 2024
|
||||
Contact: Armin Wolf <W_Armin@gmx.de>
|
||||
Description:
|
||||
This file allows the driver for a device to be specified which
|
||||
will override standard ID table matching.
|
||||
When specified, only a driver with a name matching the value
|
||||
written to driver_override will have an opportunity to bind
|
||||
to the device.
|
||||
The override is specified by writing a string to the
|
||||
driver_override file (echo wmi-event-dummy > driver_override).
|
||||
The override may be cleared with an empty string (echo > \
|
||||
driver_override) which returns the device to standard matching
|
||||
rules binding.
|
||||
Writing to driver_override does not automatically unbind the
|
||||
device from its current driver or make any attempt to automatically
|
||||
load the specified driver. If no driver with a matching name is
|
||||
currently loaded in the kernel, the device will not bind to any
|
||||
driver.
|
||||
This also allows devices to opt-out of driver binding using a
|
||||
driver_override name such as "none". Only a single driver may be
|
||||
specified in the override, there is no support for parsing delimiters.
|
||||
|
||||
What: /sys/bus/wmi/devices/.../modalias
|
||||
Date: November 20:15
|
||||
Contact: Andy Lutomirski <luto@kernel.org>
|
||||
Description:
|
||||
This file contains the MODALIAS value emitted by uevent for a
|
||||
given WMI device.
|
||||
|
||||
Format: wmi:XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.
|
||||
|
||||
What: /sys/bus/wmi/devices/.../guid
|
||||
Date: November 2015
|
||||
Contact: Andy Lutomirski <luto@kernel.org>
|
||||
Description:
|
||||
This file contains the GUID used to match WMI devices to
|
||||
compatible WMI drivers. This GUID is not necessarily unique
|
||||
inside a given machine, it is solely used to identify the
|
||||
interface exposed by a given WMI device.
|
||||
|
||||
What: /sys/bus/wmi/devices/.../object_id
|
||||
Date: November 2015
|
||||
Contact: Andy Lutomirski <luto@kernel.org>
|
||||
Description:
|
||||
This file contains the WMI object ID used internally to construct
|
||||
the ACPI method names used by non-event WMI devices. It contains
|
||||
two ASCII letters.
|
||||
|
||||
What: /sys/bus/wmi/devices/.../notify_id
|
||||
Date: November 2015
|
||||
Contact: Andy Lutomirski <luto@kernel.org>
|
||||
Description:
|
||||
This file contains the WMI notify ID used internally to map ACPI
|
||||
events to WMI event devices. It contains two ASCII letters.
|
||||
|
||||
What: /sys/bus/wmi/devices/.../instance_count
|
||||
Date: November 2015
|
||||
Contact: Andy Lutomirski <luto@kernel.org>
|
||||
Description:
|
||||
This file contains the number of WMI object instances being
|
||||
present on a given WMI device. It contains a non-negative
|
||||
number.
|
||||
|
||||
What: /sys/bus/wmi/devices/.../expensive
|
||||
Date: November 2015
|
||||
Contact: Andy Lutomirski <luto@kernel.org>
|
||||
Description:
|
||||
This file contains a boolean flag signaling if interacting with
|
||||
the given WMI device will consume significant CPU resources.
|
||||
The WMI driver core will take care of enabling/disabling such
|
||||
WMI devices.
|
||||
|
||||
What: /sys/bus/wmi/devices/.../setable
|
||||
Date: May 2017
|
||||
Contact: Darren Hart (VMware) <dvhart@infradead.org>
|
||||
Description:
|
||||
This file contains a boolean flags signaling the data block
|
||||
aassociated with the given WMI device is writable. If the
|
||||
given WMI device is not associated with a data block, then
|
||||
this file will not exist.
|
||||
@ -605,6 +605,18 @@ Description: Umwait control
|
||||
Note that a value of zero means there is no limit.
|
||||
Low order two bits must be zero.
|
||||
|
||||
What: /sys/devices/system/cpu/sev
|
||||
/sys/devices/system/cpu/sev/vmpl
|
||||
Date: May 2024
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description: Secure Encrypted Virtualization (SEV) information
|
||||
|
||||
This directory is only present when running as an SEV-SNP guest.
|
||||
|
||||
vmpl: Reports the Virtual Machine Privilege Level (VMPL) at which
|
||||
the SEV-SNP guest is running.
|
||||
|
||||
|
||||
What: /sys/devices/system/cpu/svm
|
||||
Date: August 2019
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
@ -694,3 +706,9 @@ Description:
|
||||
(RO) indicates whether or not the kernel directly supports
|
||||
modifying the crash elfcorehdr for CPU hot un/plug and/or
|
||||
on/offline changes.
|
||||
|
||||
What: /sys/devices/system/cpu/enabled
|
||||
Date: Nov 2022
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Description:
|
||||
(RO) the list of CPUs that can be brought online.
|
||||
|
||||
@ -143,8 +143,8 @@ Description:
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat/auto_reset
|
||||
Date: March 2024
|
||||
KernelVersion: 6.8
|
||||
Date: May 2024
|
||||
KernelVersion: 6.9
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RW) Reports the current state of the autoreset feature
|
||||
for a QAT device
|
||||
|
||||
@ -920,14 +920,16 @@ Description: This file shows whether the configuration descriptor is locked.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_number_of_rtt
|
||||
What: /sys/bus/platform/devices/*.ufs/attributes/max_number_of_rtt
|
||||
Date: February 2018
|
||||
Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
|
||||
Date: May 2024
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: This file provides the maximum current number of
|
||||
outstanding RTTs in device that is allowed. The full
|
||||
information about the attribute could be found at
|
||||
UFS specifications 2.1.
|
||||
outstanding RTTs in device that is allowed. bMaxNumOfRTT is a
|
||||
read-write persistent attribute and is equal to two after device
|
||||
manufacturing. It shall not be set to a value greater than
|
||||
bDeviceRTTCap value, and it may be set only when the hw queues are
|
||||
empty.
|
||||
|
||||
The file is read only.
|
||||
The file is read write.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_control
|
||||
What: /sys/bus/platform/devices/*.ufs/attributes/exception_event_control
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
What: /sys/fs/xfs/<disk>/log/log_head_lsn
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
Contact: linux-xfs@vger.kernel.org
|
||||
Description:
|
||||
The log sequence number (LSN) of the current head of the
|
||||
log. The LSN is exported in "cycle:basic block" format.
|
||||
@ -10,30 +10,28 @@ Users: xfstests
|
||||
What: /sys/fs/xfs/<disk>/log/log_tail_lsn
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
Contact: linux-xfs@vger.kernel.org
|
||||
Description:
|
||||
The log sequence number (LSN) of the current tail of the
|
||||
log. The LSN is exported in "cycle:basic block" format.
|
||||
|
||||
What: /sys/fs/xfs/<disk>/log/reserve_grant_head
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
What: /sys/fs/xfs/<disk>/log/reserve_grant_head_bytes
|
||||
Date: June 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: linux-xfs@vger.kernel.org
|
||||
Description:
|
||||
The current state of the log reserve grant head. It
|
||||
represents the total log reservation of all currently
|
||||
outstanding transactions. The grant head is exported in
|
||||
"cycle:bytes" format.
|
||||
outstanding transactions in bytes.
|
||||
Users: xfstests
|
||||
|
||||
What: /sys/fs/xfs/<disk>/log/write_grant_head
|
||||
Date: July 2014
|
||||
KernelVersion: 3.17
|
||||
Contact: xfs@oss.sgi.com
|
||||
What: /sys/fs/xfs/<disk>/log/write_grant_head_bytes
|
||||
Date: June 2024
|
||||
KernelVersion: 6.11
|
||||
Contact: linux-xfs@vger.kernel.org
|
||||
Description:
|
||||
The current state of the log write grant head. It
|
||||
represents the total log reservation of all currently
|
||||
outstanding transactions, including regrants due to
|
||||
rolling transactions. The grant head is exported in
|
||||
"cycle:bytes" format.
|
||||
rolling transactions in bytes.
|
||||
Users: xfstests
|
||||
|
||||
@ -47,6 +47,14 @@ Description:
|
||||
disabled when the feature is used. See
|
||||
Documentation/livepatch/livepatch.rst for more information.
|
||||
|
||||
What: /sys/kernel/livepatch/<patch>/replace
|
||||
Date: Jun 2024
|
||||
KernelVersion: 6.11.0
|
||||
Contact: live-patching@vger.kernel.org
|
||||
Description:
|
||||
An attribute which indicates whether the patch supports
|
||||
atomic-replace.
|
||||
|
||||
What: /sys/kernel/livepatch/<patch>/<object>
|
||||
Date: Nov 2014
|
||||
KernelVersion: 3.19.0
|
||||
|
||||
@ -155,6 +155,12 @@ Contact: SeongJae Park <sj@kernel.org>
|
||||
Description: Writing to and reading from this file sets and gets the action
|
||||
of the scheme.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/target_nid
|
||||
Date: Jun 2024
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
Description: Action's target NUMA node id. Supported by only relevant
|
||||
actions.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/apply_interval_us
|
||||
Date: Sep 2023
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
|
||||
@ -172,8 +172,8 @@ by the PCI endpoint function driver.
|
||||
* bind: ops to perform when a EPC device has been bound to EPF device
|
||||
* unbind: ops to perform when a binding has been lost between a EPC
|
||||
device and EPF device
|
||||
* linkup: ops to perform when the EPC device has established a
|
||||
connection with a host system
|
||||
* add_cfs: optional ops to create function specific configfs
|
||||
attributes
|
||||
|
||||
The PCI Function driver can then register the PCI EPF driver by using
|
||||
pci_epf_register_driver().
|
||||
|
||||
@ -139,7 +139,7 @@ driver data structure.
|
||||
|
||||
static struct pcie_port_service_driver root_aerdrv = {
|
||||
.name = (char *)device_name,
|
||||
.id_table = &service_id[0],
|
||||
.id_table = service_id,
|
||||
|
||||
.probe = aerdrv_load,
|
||||
.remove = aerdrv_unload,
|
||||
|
||||
@ -149,9 +149,9 @@ This case is handled by calls to the strongly ordered
|
||||
``atomic_add_return()`` read-modify-write atomic operation that
|
||||
is invoked within ``rcu_dynticks_eqs_enter()`` at idle-entry
|
||||
time and within ``rcu_dynticks_eqs_exit()`` at idle-exit time.
|
||||
The grace-period kthread invokes ``rcu_dynticks_snap()`` and
|
||||
``rcu_dynticks_in_eqs_since()`` (both of which invoke
|
||||
an ``atomic_add_return()`` of zero) to detect idle CPUs.
|
||||
The grace-period kthread invokes first ``ct_dynticks_cpu_acquire()``
|
||||
(preceded by a full memory barrier) and ``rcu_dynticks_in_eqs_since()``
|
||||
(both of which rely on acquire semantics) to detect idle CPUs.
|
||||
|
||||
+-----------------------------------------------------------------------+
|
||||
| **Quick Quiz**: |
|
||||
|
||||
@ -2357,6 +2357,7 @@ section.
|
||||
#. `Sched Flavor (Historical)`_
|
||||
#. `Sleepable RCU`_
|
||||
#. `Tasks RCU`_
|
||||
#. `Tasks Trace RCU`_
|
||||
|
||||
Bottom-Half Flavor (Historical)
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -2610,6 +2611,16 @@ critical sections that are delimited by voluntary context switches, that
|
||||
is, calls to schedule(), cond_resched(), and
|
||||
synchronize_rcu_tasks(). In addition, transitions to and from
|
||||
userspace execution also delimit tasks-RCU read-side critical sections.
|
||||
Idle tasks are ignored by Tasks RCU, and Tasks Rude RCU may be used to
|
||||
interact with them.
|
||||
|
||||
Note well that involuntary context switches are *not* Tasks-RCU quiescent
|
||||
states. After all, in preemptible kernels, a task executing code in a
|
||||
trampoline might be preempted. In this case, the Tasks-RCU grace period
|
||||
clearly cannot end until that task resumes and its execution leaves that
|
||||
trampoline. This means, among other things, that cond_resched() does
|
||||
not provide a Tasks RCU quiescent state. (Instead, use rcu_softirq_qs()
|
||||
from softirq or rcu_tasks_classic_qs() otherwise.)
|
||||
|
||||
The tasks-RCU API is quite compact, consisting only of
|
||||
call_rcu_tasks(), synchronize_rcu_tasks(), and
|
||||
@ -2632,6 +2643,11 @@ moniker. And this operation is considered to be quite rude by real-time
|
||||
workloads that don't want their ``nohz_full`` CPUs receiving IPIs and
|
||||
by battery-powered systems that don't want their idle CPUs to be awakened.
|
||||
|
||||
Once kernel entry/exit and deep-idle functions have been properly tagged
|
||||
``noinstr``, Tasks RCU can start paying attention to idle tasks (except
|
||||
those that are idle from RCU's perspective) and then Tasks Rude RCU can
|
||||
be removed from the kernel.
|
||||
|
||||
The tasks-rude-RCU API is also reader-marking-free and thus quite compact,
|
||||
consisting of call_rcu_tasks_rude(), synchronize_rcu_tasks_rude(),
|
||||
and rcu_barrier_tasks_rude().
|
||||
|
||||
@ -250,21 +250,25 @@ rcu_assign_pointer()
|
||||
^^^^^^^^^^^^^^^^^^^^
|
||||
void rcu_assign_pointer(p, typeof(p) v);
|
||||
|
||||
Yes, rcu_assign_pointer() **is** implemented as a macro, though it
|
||||
would be cool to be able to declare a function in this manner.
|
||||
(Compiler experts will no doubt disagree.)
|
||||
Yes, rcu_assign_pointer() **is** implemented as a macro, though
|
||||
it would be cool to be able to declare a function in this manner.
|
||||
(And there has been some discussion of adding overloaded functions
|
||||
to the C language, so who knows?)
|
||||
|
||||
The updater uses this spatial macro to assign a new value to an
|
||||
RCU-protected pointer, in order to safely communicate the change
|
||||
in value from the updater to the reader. This is a spatial (as
|
||||
opposed to temporal) macro. It does not evaluate to an rvalue,
|
||||
but it does execute any memory-barrier instructions required
|
||||
for a given CPU architecture. Its ordering properties are that
|
||||
of a store-release operation.
|
||||
but it does provide any compiler directives and memory-barrier
|
||||
instructions required for a given compile or CPU architecture.
|
||||
Its ordering properties are that of a store-release operation,
|
||||
that is, any prior loads and stores required to initialize the
|
||||
structure are ordered before the store that publishes the pointer
|
||||
to that structure.
|
||||
|
||||
Perhaps just as important, it serves to document (1) which
|
||||
pointers are protected by RCU and (2) the point at which a
|
||||
given structure becomes accessible to other CPUs. That said,
|
||||
Perhaps just as important, rcu_assign_pointer() serves to document
|
||||
(1) which pointers are protected by RCU and (2) the point at which
|
||||
a given structure becomes accessible to other CPUs. That said,
|
||||
rcu_assign_pointer() is most frequently used indirectly, via
|
||||
the _rcu list-manipulation primitives such as list_add_rcu().
|
||||
|
||||
@ -283,7 +287,11 @@ rcu_dereference()
|
||||
executes any needed memory-barrier instructions for a given
|
||||
CPU architecture. Currently, only Alpha needs memory barriers
|
||||
within rcu_dereference() -- on other CPUs, it compiles to a
|
||||
volatile load.
|
||||
volatile load. However, no mainstream C compilers respect
|
||||
address dependencies, so rcu_dereference() uses volatile casts,
|
||||
which, in combination with the coding guidelines listed in
|
||||
rcu_dereference.rst, prevent current compilers from breaking
|
||||
these dependencies.
|
||||
|
||||
Common coding practice uses rcu_dereference() to copy an
|
||||
RCU-protected pointer to a local variable, then dereferences
|
||||
|
||||
@ -36,7 +36,8 @@ superset of parent/child/pids.current.
|
||||
|
||||
The pids.events file contains event counters:
|
||||
|
||||
- max: Number of times fork failed because limit was hit.
|
||||
- max: Number of times fork failed in the cgroup because limit was hit in
|
||||
self or ancestors.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
@ -239,6 +239,13 @@ cgroup v2 currently supports the following mount options.
|
||||
will not be tracked by the memory controller (even if cgroup
|
||||
v2 is remounted later on).
|
||||
|
||||
pids_localevents
|
||||
The option restores v1-like behavior of pids.events:max, that is only
|
||||
local (inside cgroup proper) fork failures are counted. Without this
|
||||
option pids.events.max represents any pids.max enforcemnt across
|
||||
cgroup's subtree.
|
||||
|
||||
|
||||
|
||||
Organizing Processes and Threads
|
||||
--------------------------------
|
||||
@ -1299,17 +1306,10 @@ PAGE_SIZE multiple when read back.
|
||||
This is a simple interface to trigger memory reclaim in the
|
||||
target cgroup.
|
||||
|
||||
This file accepts a single key, the number of bytes to reclaim.
|
||||
No nested keys are currently supported.
|
||||
|
||||
Example::
|
||||
|
||||
echo "1G" > memory.reclaim
|
||||
|
||||
The interface can be later extended with nested keys to
|
||||
configure the reclaim behavior. For example, specify the
|
||||
type of memory to reclaim from (anon, file, ..).
|
||||
|
||||
Please note that the kernel can over or under reclaim from
|
||||
the target cgroup. If less bytes are reclaimed than the
|
||||
specified amount, -EAGAIN is returned.
|
||||
@ -1321,6 +1321,17 @@ PAGE_SIZE multiple when read back.
|
||||
This means that the networking layer will not adapt based on
|
||||
reclaim induced by memory.reclaim.
|
||||
|
||||
The following nested keys are defined.
|
||||
|
||||
========== ================================
|
||||
swappiness Swappiness value to reclaim with
|
||||
========== ================================
|
||||
|
||||
Specifying a swappiness value instructs the kernel to perform
|
||||
the reclaim with that swappiness value. Note that this has the
|
||||
same semantics as vm.swappiness applied to memcg reclaim with
|
||||
all the existing limitations and potential future extensions.
|
||||
|
||||
memory.peak
|
||||
A read-only single value file which exists on non-root
|
||||
cgroups.
|
||||
@ -2205,12 +2216,18 @@ PID Interface Files
|
||||
descendants has ever reached.
|
||||
|
||||
pids.events
|
||||
A read-only flat-keyed file which exists on non-root cgroups. The
|
||||
following entries are defined. Unless specified otherwise, a value
|
||||
change in this file generates a file modified event.
|
||||
A read-only flat-keyed file which exists on non-root cgroups. Unless
|
||||
specified otherwise, a value change in this file generates a file
|
||||
modified event. The following entries are defined.
|
||||
|
||||
max
|
||||
Number of times fork failed because limit was hit.
|
||||
The number of times the cgroup's total number of processes hit the pids.max
|
||||
limit (see also pids_localevents).
|
||||
|
||||
pids.events.local
|
||||
Similar to pids.events but the fields in the file are local
|
||||
to the cgroup i.e. not hierarchical. The file modified event
|
||||
generated on this file reflects only the local events.
|
||||
|
||||
Organisational operations are not blocked by cgroup policies, so it is
|
||||
possible to have pids.current > pids.max. This can be done by either
|
||||
@ -2346,8 +2363,12 @@ Cpuset Interface Files
|
||||
is always a subset of it.
|
||||
|
||||
Users can manually set it to a value that is different from
|
||||
"cpuset.cpus". The only constraint in setting it is that the
|
||||
list of CPUs must be exclusive with respect to its sibling.
|
||||
"cpuset.cpus". One constraint in setting it is that the list of
|
||||
CPUs must be exclusive with respect to "cpuset.cpus.exclusive"
|
||||
of its sibling. If "cpuset.cpus.exclusive" of a sibling cgroup
|
||||
isn't set, its "cpuset.cpus" value, if set, cannot be a subset
|
||||
of it to leave at least one CPU available when the exclusive
|
||||
CPUs are taken away.
|
||||
|
||||
For a parent cgroup, any one of its exclusive CPUs can only
|
||||
be distributed to at most one of its child cgroups. Having an
|
||||
@ -2363,8 +2384,8 @@ Cpuset Interface Files
|
||||
cpuset-enabled cgroups.
|
||||
|
||||
This file shows the effective set of exclusive CPUs that
|
||||
can be used to create a partition root. The content of this
|
||||
file will always be a subset of "cpuset.cpus" and its parent's
|
||||
can be used to create a partition root. The content
|
||||
of this file will always be a subset of its parent's
|
||||
"cpuset.cpus.exclusive.effective" if its parent is not the root
|
||||
cgroup. It will also be a subset of "cpuset.cpus.exclusive"
|
||||
if it is set. If "cpuset.cpus.exclusive" is not set, it is
|
||||
@ -2625,6 +2646,15 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_
|
||||
res_a 3
|
||||
res_b 0
|
||||
|
||||
misc.peak
|
||||
A read-only flat-keyed file shown in all cgroups. It shows the
|
||||
historical maximum usage of the resources in the cgroup and its
|
||||
children.::
|
||||
|
||||
$ cat misc.peak
|
||||
res_a 10
|
||||
res_b 8
|
||||
|
||||
misc.max
|
||||
A read-write flat-keyed file shown in the non root cgroups. Allowed
|
||||
maximum usage of the resources in the cgroup and its children.::
|
||||
@ -2654,6 +2684,11 @@ Miscellaneous controller provides 3 interface files. If two misc resources (res_
|
||||
The number of times the cgroup's resource usage was
|
||||
about to go over the max boundary.
|
||||
|
||||
misc.events.local
|
||||
Similar to misc.events but the fields in the file are local to the
|
||||
cgroup i.e. not hierarchical. The file modified event generated on
|
||||
this file reflects only the local events.
|
||||
|
||||
Migration and Ownership
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@ -723,40 +723,26 @@ Configuration pseudo-files:
|
||||
======================= =======================================================
|
||||
SecurityFlags Flags which control security negotiation and
|
||||
also packet signing. Authentication (may/must)
|
||||
flags (e.g. for NTLM and/or NTLMv2) may be combined with
|
||||
flags (e.g. for NTLMv2) may be combined with
|
||||
the signing flags. Specifying two different password
|
||||
hashing mechanisms (as "must use") on the other hand
|
||||
does not make much sense. Default flags are::
|
||||
|
||||
0x07007
|
||||
0x00C5
|
||||
|
||||
(NTLM, NTLMv2 and packet signing allowed). The maximum
|
||||
allowable flags if you want to allow mounts to servers
|
||||
using weaker password hashes is 0x37037 (lanman,
|
||||
plaintext, ntlm, ntlmv2, signing allowed). Some
|
||||
SecurityFlags require the corresponding menuconfig
|
||||
options to be enabled. Enabling plaintext
|
||||
authentication currently requires also enabling
|
||||
lanman authentication in the security flags
|
||||
because the cifs module only supports sending
|
||||
laintext passwords using the older lanman dialect
|
||||
form of the session setup SMB. (e.g. for authentication
|
||||
using plain text passwords, set the SecurityFlags
|
||||
to 0x30030)::
|
||||
(NTLMv2 and packet signing allowed). Some SecurityFlags
|
||||
may require enabling a corresponding menuconfig option.
|
||||
|
||||
may use packet signing 0x00001
|
||||
must use packet signing 0x01001
|
||||
may use NTLM (most common password hash) 0x00002
|
||||
must use NTLM 0x02002
|
||||
may use NTLMv2 0x00004
|
||||
must use NTLMv2 0x04004
|
||||
may use Kerberos security 0x00008
|
||||
must use Kerberos 0x08008
|
||||
may use lanman (weak) password hash 0x00010
|
||||
must use lanman password hash 0x10010
|
||||
may use plaintext passwords 0x00020
|
||||
must use plaintext passwords 0x20020
|
||||
(reserved for future packet encryption) 0x00040
|
||||
may use Kerberos security (krb5) 0x00008
|
||||
must use Kerberos 0x08008
|
||||
may use NTLMSSP 0x00080
|
||||
must use NTLMSSP 0x80080
|
||||
seal (packet encryption) 0x00040
|
||||
must seal (not implemented yet) 0x40040
|
||||
|
||||
cifsFYI If set to non-zero value, additional debug information
|
||||
will be logged to the system error log. This field
|
||||
|
||||
@ -160,6 +160,17 @@ iv_large_sectors
|
||||
The <iv_offset> must be multiple of <sector_size> (in 512 bytes units)
|
||||
if this flag is specified.
|
||||
|
||||
|
||||
Module parameters::
|
||||
max_read_size
|
||||
max_write_size
|
||||
Maximum size of read or write requests. When a request larger than this size
|
||||
is received, dm-crypt will split the request. The splitting improves
|
||||
concurrency (the split requests could be encrypted in parallel by multiple
|
||||
cores), but it also causes overhead. The user should tune these parameters to
|
||||
fit the actual workload.
|
||||
|
||||
|
||||
Example scripts
|
||||
===============
|
||||
LUKS (Linux Unified Key Setup) is now the preferred way to set up disk
|
||||
|
||||
@ -241,6 +241,7 @@ Messages
|
||||
All vdo devices accept messages in the form:
|
||||
|
||||
::
|
||||
|
||||
dmsetup message <target-name> 0 <message-name> <message-parameters>
|
||||
|
||||
The messages are:
|
||||
|
||||
@ -26,6 +26,11 @@ Dynamic debug provides:
|
||||
- format string
|
||||
- class name (as known/declared by each module)
|
||||
|
||||
NOTE: To actually get the debug-print output on the console, you may
|
||||
need to adjust the kernel ``loglevel=``, or use ``ignore_loglevel``.
|
||||
Read about these kernel parameters in
|
||||
Documentation/admin-guide/kernel-parameters.rst.
|
||||
|
||||
Viewing Dynamic Debug Behaviour
|
||||
===============================
|
||||
|
||||
|
||||
177
Documentation/admin-guide/gpio/gpio-virtuser.rst
Normal file
177
Documentation/admin-guide/gpio/gpio-virtuser.rst
Normal file
@ -0,0 +1,177 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0-only
|
||||
|
||||
Virtual GPIO Consumer
|
||||
=====================
|
||||
|
||||
The virtual GPIO Consumer module allows users to instantiate virtual devices
|
||||
that request GPIOs and then control their behavior over debugfs. Virtual
|
||||
consumer devices can be instantiated from device-tree or over configfs.
|
||||
|
||||
A virtual consumer uses the driver-facing GPIO APIs and allows to cover it with
|
||||
automated tests driven by user-space. The GPIOs are requested using
|
||||
``gpiod_get_array()`` and so we support multiple GPIOs per connector ID.
|
||||
|
||||
Creating GPIO consumers
|
||||
-----------------------
|
||||
|
||||
The gpio-consumer module registers a configfs subsystem called
|
||||
``'gpio-virtuser'``. For details of the configfs filesystem, please refer to
|
||||
the configfs documentation.
|
||||
|
||||
The user can create a hierarchy of configfs groups and items as well as modify
|
||||
values of exposed attributes. Once the consumer is instantiated, this hierarchy
|
||||
will be translated to appropriate device properties. The general structure is:
|
||||
|
||||
**Group:** ``/config/gpio-virtuser``
|
||||
|
||||
This is the top directory of the gpio-consumer configfs tree.
|
||||
|
||||
**Group:** ``/config/gpio-consumer/example-name``
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/live``
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/dev_name``
|
||||
|
||||
This is a directory representing a GPIO consumer device.
|
||||
|
||||
The read-only ``dev_name`` attribute exposes the name of the device as it will
|
||||
appear in the system on the platform bus. This is useful for locating the
|
||||
associated debugfs directory under
|
||||
``/sys/kernel/debug/gpio-virtuser/$dev_name``.
|
||||
|
||||
The ``'live'`` attribute allows to trigger the actual creation of the device
|
||||
once it's fully configured. The accepted values are: ``'1'`` to enable the
|
||||
virtual device and ``'0'`` to disable and tear it down.
|
||||
|
||||
Creating GPIO lookup tables
|
||||
---------------------------
|
||||
|
||||
Users can create a number of configfs groups under the device group:
|
||||
|
||||
**Group:** ``/config/gpio-consumer/example-name/con_id``
|
||||
|
||||
The ``'con_id'`` directory represents a single GPIO lookup and its value maps
|
||||
to the ``'con_id'`` argument of the ``gpiod_get()`` function. For example:
|
||||
``con_id`` == ``'reset'`` maps to the ``reset-gpios`` device property.
|
||||
|
||||
Users can assign a number of GPIOs to each lookup. Each GPIO is a sub-directory
|
||||
with a user-defined name under the ``'con_id'`` group.
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/key``
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/offset``
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/drive``
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/pull``
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/active_low``
|
||||
|
||||
**Attribute:** ``/config/gpio-consumer/example-name/con_id/0/transitory``
|
||||
|
||||
This is a group describing a single GPIO in the ``con_id-gpios`` property.
|
||||
|
||||
For virtual consumers created using configfs we use machine lookup tables so
|
||||
this group can be considered as a mapping between the filesystem and the fields
|
||||
of a single entry in ``'struct gpiod_lookup'``.
|
||||
|
||||
The ``'key'`` attribute represents either the name of the chip this GPIO
|
||||
belongs to or the GPIO line name. This depends on the value of the ``'offset'``
|
||||
attribute: if its value is >= 0, then ``'key'`` represents the label of the
|
||||
chip to lookup while ``'offset'`` represents the offset of the line in that
|
||||
chip. If ``'offset'`` is < 0, then ``'key'`` represents the name of the line.
|
||||
|
||||
The remaining attributes map to the ``'flags'`` field of the GPIO lookup
|
||||
struct. The first two take string values as arguments:
|
||||
|
||||
**``'drive'``:** ``'push-pull'``, ``'open-drain'``, ``'open-source'``
|
||||
**``'pull'``:** ``'pull-up'``, ``'pull-down'``, ``'pull-disabled'``, ``'as-is'``
|
||||
|
||||
``'active_low'`` and ``'transitory'`` are boolean attributes.
|
||||
|
||||
Activating GPIO consumers
|
||||
-------------------------
|
||||
|
||||
Once the confiuration is complete, the ``'live'`` attribute must be set to 1 in
|
||||
order to instantiate the consumer. It can be set back to 0 to destroy the
|
||||
virtual device. The module will synchronously wait for the new simulated device
|
||||
to be successfully probed and if this doesn't happen, writing to ``'live'`` will
|
||||
result in an error.
|
||||
|
||||
Device-tree
|
||||
-----------
|
||||
|
||||
Virtual GPIO consumers can also be defined in device-tree. The compatible string
|
||||
must be: ``"gpio-virtuser"`` with at least one property following the
|
||||
standardized GPIO pattern.
|
||||
|
||||
An example device-tree code defining a virtual GPIO consumer:
|
||||
|
||||
.. code-block :: none
|
||||
|
||||
gpio-virt-consumer {
|
||||
compatible = "gpio-virtuser";
|
||||
|
||||
foo-gpios = <&gpio0 5 GPIO_ACTIVE_LOW>, <&gpio1 2 0>;
|
||||
bar-gpios = <&gpio0 6 0>;
|
||||
};
|
||||
|
||||
Controlling virtual GPIO consumers
|
||||
----------------------------------
|
||||
|
||||
Once active, the device will export debugfs attributes for controlling GPIO
|
||||
arrays as well as each requested GPIO line separately. Let's consider the
|
||||
following device property: ``foo-gpios = <&gpio0 0 0>, <&gpio0 4 0>;``.
|
||||
|
||||
The following debugfs attribute groups will be created:
|
||||
|
||||
**Group:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo/``
|
||||
|
||||
This is the group that will contain the attributes for the entire GPIO array.
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo/values``
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo/values_atomic``
|
||||
|
||||
Both attributes allow to read and set arrays of GPIO values. User must pass
|
||||
exactly the number of values that the array contains in the form of a string
|
||||
containing zeroes and ones representing inactive and active GPIO states
|
||||
respectively. In this example: ``echo 11 > values``.
|
||||
|
||||
The ``values_atomic`` attribute works the same as ``values`` but the kernel
|
||||
will execute the GPIO driver callbacks in interrupt context.
|
||||
|
||||
**Group:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/``
|
||||
|
||||
This is a group that represents a single GPIO with ``$index`` being its offset
|
||||
in the array.
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/consumer``
|
||||
|
||||
Allows to set and read the consumer label of the GPIO line.
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/debounce``
|
||||
|
||||
Allows to set and read the debounce period of the GPIO line.
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/direction``
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/direction_atomic``
|
||||
|
||||
These two attributes allow to set the direction of the GPIO line. They accept
|
||||
"input" and "output" as values. The atomic variant executes the driver callback
|
||||
in interrupt context.
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/interrupts``
|
||||
|
||||
If the line is requested in input mode, writing ``1`` to this attribute will
|
||||
make the module listen for edge interrupts on the GPIO. Writing ``0`` disables
|
||||
the monitoring. Reading this attribute returns the current number of registered
|
||||
interrupts (both edges).
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/value``
|
||||
|
||||
**Attribute:** ``/sys/kernel/debug/gpio-virtuser/$dev_name/gpiod:foo:$index/value_atomic``
|
||||
|
||||
Both attributes allow to read and set values of individual requested GPIO lines.
|
||||
They accept the following values: ``1`` and ``0``.
|
||||
@ -10,6 +10,7 @@ GPIO
|
||||
Character Device Userspace API <../../userspace-api/gpio/chardev>
|
||||
gpio-aggregator
|
||||
gpio-sim
|
||||
gpio-virtuser
|
||||
Obsolete APIs <obsolete>
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
@ -592,85 +592,19 @@ Spectre variant 2
|
||||
Mitigation control on the kernel command line
|
||||
---------------------------------------------
|
||||
|
||||
Spectre variant 2 mitigation can be disabled or force enabled at the
|
||||
kernel command line.
|
||||
In general the kernel selects reasonable default mitigations for the
|
||||
current CPU.
|
||||
|
||||
nospectre_v1
|
||||
Spectre default mitigations can be disabled or changed at the kernel
|
||||
command line with the following options:
|
||||
|
||||
[X86,PPC] Disable mitigations for Spectre Variant 1
|
||||
(bounds check bypass). With this option data leaks are
|
||||
possible in the system.
|
||||
- nospectre_v1
|
||||
- nospectre_v2
|
||||
- spectre_v2={option}
|
||||
- spectre_v2_user={option}
|
||||
- spectre_bhi={option}
|
||||
|
||||
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
|
||||
to spectre_v2=off.
|
||||
|
||||
|
||||
spectre_v2=
|
||||
|
||||
[X86] Control mitigation of Spectre variant 2
|
||||
(indirect branch speculation) vulnerability.
|
||||
The default operation protects the kernel from
|
||||
user space attacks.
|
||||
|
||||
on
|
||||
unconditionally enable, implies
|
||||
spectre_v2_user=on
|
||||
off
|
||||
unconditionally disable, implies
|
||||
spectre_v2_user=off
|
||||
auto
|
||||
kernel detects whether your CPU model is
|
||||
vulnerable
|
||||
|
||||
Selecting 'on' will, and 'auto' may, choose a
|
||||
mitigation method at run time according to the
|
||||
CPU, the available microcode, the setting of the
|
||||
CONFIG_MITIGATION_RETPOLINE configuration option,
|
||||
and the compiler with which the kernel was built.
|
||||
|
||||
Selecting 'on' will also enable the mitigation
|
||||
against user space to user space task attacks.
|
||||
|
||||
Selecting 'off' will disable both the kernel and
|
||||
the user space protections.
|
||||
|
||||
Specific mitigations can also be selected manually:
|
||||
|
||||
retpoline auto pick between generic,lfence
|
||||
retpoline,generic Retpolines
|
||||
retpoline,lfence LFENCE; indirect branch
|
||||
retpoline,amd alias for retpoline,lfence
|
||||
eibrs Enhanced/Auto IBRS
|
||||
eibrs,retpoline Enhanced/Auto IBRS + Retpolines
|
||||
eibrs,lfence Enhanced/Auto IBRS + LFENCE
|
||||
ibrs use IBRS to protect kernel
|
||||
|
||||
Not specifying this option is equivalent to
|
||||
spectre_v2=auto.
|
||||
|
||||
In general the kernel by default selects
|
||||
reasonable mitigations for the current CPU. To
|
||||
disable Spectre variant 2 mitigations, boot with
|
||||
spectre_v2=off. Spectre variant 1 mitigations
|
||||
cannot be disabled.
|
||||
|
||||
spectre_bhi=
|
||||
|
||||
[X86] Control mitigation of Branch History Injection
|
||||
(BHI) vulnerability. This setting affects the deployment
|
||||
of the HW BHI control and the SW BHB clearing sequence.
|
||||
|
||||
on
|
||||
(default) Enable the HW or SW mitigation as
|
||||
needed.
|
||||
off
|
||||
Disable the mitigation.
|
||||
|
||||
For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt
|
||||
For more details on the available options, refer to Documentation/admin-guide/kernel-parameters.txt
|
||||
|
||||
Mitigation selection guide
|
||||
--------------------------
|
||||
|
||||
@ -121,7 +121,6 @@ configure specific aspects of kernel behavior to your liking.
|
||||
parport
|
||||
perf-security
|
||||
pm/index
|
||||
pmf
|
||||
pnp
|
||||
rapidio
|
||||
RAS/index
|
||||
|
||||
@ -118,7 +118,6 @@ is applicable::
|
||||
HIBERNATION HIBERNATION is enabled.
|
||||
HW Appropriate hardware is enabled.
|
||||
HYPER_V HYPERV support is enabled.
|
||||
IA-64 IA-64 architecture is enabled.
|
||||
IMA Integrity measurement architecture is enabled.
|
||||
IP_PNP IP DHCP, BOOTP, or RARP is enabled.
|
||||
IPV6 IPv6 support is enabled.
|
||||
|
||||
@ -12,7 +12,7 @@
|
||||
acpi= [HW,ACPI,X86,ARM64,RISCV64,EARLY]
|
||||
Advanced Configuration and Power Interface
|
||||
Format: { force | on | off | strict | noirq | rsdt |
|
||||
copy_dsdt }
|
||||
copy_dsdt | nospcr }
|
||||
force -- enable ACPI if default was off
|
||||
on -- enable ACPI but allow fallback to DT [arm64,riscv64]
|
||||
off -- disable ACPI if default was on
|
||||
@ -21,8 +21,12 @@
|
||||
strictly ACPI specification compliant.
|
||||
rsdt -- prefer RSDT over (default) XSDT
|
||||
copy_dsdt -- copy DSDT to memory
|
||||
For ARM64 and RISCV64, ONLY "acpi=off", "acpi=on" or
|
||||
"acpi=force" are available
|
||||
nospcr -- disable console in ACPI SPCR table as
|
||||
default _serial_ console on ARM64
|
||||
For ARM64, ONLY "acpi=off", "acpi=on", "acpi=force" or
|
||||
"acpi=nospcr" are available
|
||||
For RISCV64, ONLY "acpi=off", "acpi=on" or "acpi=force"
|
||||
are available
|
||||
|
||||
See also Documentation/power/runtime_pm.rst, pci=noacpi
|
||||
|
||||
@ -788,6 +792,25 @@
|
||||
Documentation/networking/netconsole.rst for an
|
||||
alternative.
|
||||
|
||||
<DEVNAME>:<n>.<n>[,options]
|
||||
Use the specified serial port on the serial core bus.
|
||||
The addressing uses DEVNAME of the physical serial port
|
||||
device, followed by the serial core controller instance,
|
||||
and the serial port instance. The options are the same
|
||||
as documented for the ttyS addressing above.
|
||||
|
||||
The mapping of the serial ports to the tty instances
|
||||
can be viewed with:
|
||||
|
||||
$ ls -d /sys/bus/serial-base/devices/*:*.*/tty/*
|
||||
/sys/bus/serial-base/devices/00:04:0.0/tty/ttyS0
|
||||
|
||||
In the above example, the console can be addressed with
|
||||
console=00:04:0.0. Note that a console addressed this
|
||||
way will only get added when the related device driver
|
||||
is ready. The use of an earlycon parameter in addition to
|
||||
the console may be desired for console output early on.
|
||||
|
||||
uart[8250],io,<addr>[,options]
|
||||
uart[8250],mmio,<addr>[,options]
|
||||
uart[8250],mmio16,<addr>[,options]
|
||||
@ -1431,27 +1454,6 @@
|
||||
you are really sure that your UEFI does sane gc and
|
||||
fulfills the spec otherwise your board may brick.
|
||||
|
||||
efi_fake_mem= nn[KMG]@ss[KMG]:aa[,nn[KMG]@ss[KMG]:aa,..] [EFI,X86,EARLY]
|
||||
Add arbitrary attribute to specific memory range by
|
||||
updating original EFI memory map.
|
||||
Region of memory which aa attribute is added to is
|
||||
from ss to ss+nn.
|
||||
|
||||
If efi_fake_mem=2G@4G:0x10000,2G@0x10a0000000:0x10000
|
||||
is specified, EFI_MEMORY_MORE_RELIABLE(0x10000)
|
||||
attribute is added to range 0x100000000-0x180000000 and
|
||||
0x10a0000000-0x1120000000.
|
||||
|
||||
If efi_fake_mem=8G@9G:0x40000 is specified, the
|
||||
EFI_MEMORY_SP(0x40000) attribute is added to
|
||||
range 0x240000000-0x43fffffff.
|
||||
|
||||
Using this parameter you can do debugging of EFI memmap
|
||||
related features. For example, you can do debugging of
|
||||
Address Range Mirroring feature even if your box
|
||||
doesn't support it, or mark specific memory as
|
||||
"soft reserved".
|
||||
|
||||
efivar_ssdt= [EFI; X86] Name of an EFI variable that contains an SSDT
|
||||
that is to be dynamically loaded by Linux. If there are
|
||||
multiple variables with the same name but with different
|
||||
@ -1759,8 +1761,6 @@
|
||||
for 64-bit NUMA, off otherwise.
|
||||
Format: 0 | 1 (for off | on)
|
||||
|
||||
hcl= [IA-64] SGI's Hardware Graph compatibility layer
|
||||
|
||||
hd= [EIDE] (E)IDE hard drive subsystem geometry
|
||||
Format: <cyl>,<head>,<sect>
|
||||
|
||||
@ -2003,7 +2003,7 @@
|
||||
for the device. By default it is set to false (0).
|
||||
|
||||
ieee754= [MIPS] Select IEEE Std 754 conformance mode
|
||||
Format: { strict | legacy | 2008 | relaxed }
|
||||
Format: { strict | legacy | 2008 | relaxed | emulated }
|
||||
Default: strict
|
||||
|
||||
Choose which programs will be accepted for execution
|
||||
@ -2023,6 +2023,8 @@
|
||||
by the FPU
|
||||
relaxed accept any binaries regardless of whether
|
||||
supported by the FPU
|
||||
emulated accept any binaries but enable FPU emulator
|
||||
if binary mode is unsupported by the FPU.
|
||||
|
||||
The FPU emulator is always able to support both NaN
|
||||
encodings, so if no FPU hardware is present or it has
|
||||
@ -2519,7 +2521,7 @@
|
||||
|
||||
keepinitrd [HW,ARM] See retain_initrd.
|
||||
|
||||
kernelcore= [KNL,X86,IA-64,PPC,EARLY]
|
||||
kernelcore= [KNL,X86,PPC,EARLY]
|
||||
Format: nn[KMGTPE] | nn% | "mirror"
|
||||
This parameter specifies the amount of memory usable by
|
||||
the kernel for non-movable allocations. The requested
|
||||
@ -2720,6 +2722,24 @@
|
||||
[KVM,ARM,EARLY] Allow use of GICv4 for direct
|
||||
injection of LPIs.
|
||||
|
||||
kvm-arm.wfe_trap_policy=
|
||||
[KVM,ARM] Control when to set WFE instruction trap for
|
||||
KVM VMs. Traps are allowed but not guaranteed by the
|
||||
CPU architecture.
|
||||
|
||||
trap: set WFE instruction trap
|
||||
|
||||
notrap: clear WFE instruction trap
|
||||
|
||||
kvm-arm.wfi_trap_policy=
|
||||
[KVM,ARM] Control when to set WFI instruction trap for
|
||||
KVM VMs. Traps are allowed but not guaranteed by the
|
||||
CPU architecture.
|
||||
|
||||
trap: set WFI instruction trap
|
||||
|
||||
notrap: clear WFI instruction trap
|
||||
|
||||
kvm_cma_resv_ratio=n [PPC,EARLY]
|
||||
Reserves given percentage from system memory area for
|
||||
contiguous memory allocation for KVM hash pagetable
|
||||
@ -3159,26 +3179,16 @@
|
||||
unlikely, in the extreme case this might damage your
|
||||
hardware.
|
||||
|
||||
ltpc= [NET]
|
||||
Format: <io>,<irq>,<dma>
|
||||
|
||||
lsm.debug [SECURITY] Enable LSM initialization debugging output.
|
||||
|
||||
lsm=lsm1,...,lsmN
|
||||
[SECURITY] Choose order of LSM initialization. This
|
||||
overrides CONFIG_LSM, and the "security=" parameter.
|
||||
|
||||
machvec= [IA-64] Force the use of a particular machine-vector
|
||||
(machvec) in a generic kernel.
|
||||
Example: machvec=hpzx1
|
||||
|
||||
machtype= [Loongson] Share the same kernel image file between
|
||||
different yeeloong laptops.
|
||||
Example: machtype=lemote-yeeloong-2f-7inch
|
||||
|
||||
max_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory greater
|
||||
than or equal to this physical address is ignored.
|
||||
|
||||
maxcpus= [SMP,EARLY] Maximum number of processors that an SMP kernel
|
||||
will bring up during bootup. maxcpus=n : n >= 0 limits
|
||||
the kernel to bring up 'n' processors. Surely after
|
||||
@ -3404,10 +3414,6 @@
|
||||
deep - Suspend-To-RAM or equivalent (if supported)
|
||||
See Documentation/admin-guide/pm/sleep-states.rst.
|
||||
|
||||
mfgpt_irq= [IA-32] Specify the IRQ to use for the
|
||||
Multi-Function General Purpose Timers on AMD Geode
|
||||
platforms.
|
||||
|
||||
mfgptfix [X86-32] Fix MFGPT timers on AMD Geode platforms when
|
||||
the BIOS has incorrectly applied a workaround. TinyBIOS
|
||||
version 0.98 is known to be affected, 0.99 fixes the
|
||||
@ -3420,9 +3426,6 @@
|
||||
Enable or disable the microcode minimal revision
|
||||
enforcement for the runtime microcode loader.
|
||||
|
||||
min_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory below this
|
||||
physical address is ignored.
|
||||
|
||||
mini2440= [ARM,HW,KNL]
|
||||
Format:[0..2][b][c][t]
|
||||
Default: "0tb"
|
||||
@ -3587,7 +3590,7 @@
|
||||
mousedev.yres= [MOUSE] Vertical screen resolution, used for devices
|
||||
reporting absolute coordinates, such as tablets
|
||||
|
||||
movablecore= [KNL,X86,IA-64,PPC,EARLY]
|
||||
movablecore= [KNL,X86,PPC,EARLY]
|
||||
Format: nn[KMGTPE] | nn%
|
||||
This parameter is the complement to kernelcore=, it
|
||||
specifies the amount of memory used for migratable
|
||||
@ -3613,11 +3616,6 @@
|
||||
mtdparts= [MTD]
|
||||
See drivers/mtd/parsers/cmdlinepart.c
|
||||
|
||||
mtdset= [ARM]
|
||||
ARM/S3C2412 JIVE boot control
|
||||
|
||||
See arch/arm/mach-s3c/mach-jive.c
|
||||
|
||||
mtouchusb.raw_coordinates=
|
||||
[HW] Make the MicroTouch USB driver use raw coordinates
|
||||
('y', default) or cooked coordinates ('n')
|
||||
@ -3832,9 +3830,6 @@
|
||||
|
||||
noalign [KNL,ARM]
|
||||
|
||||
noaltinstr [S390,EARLY] Disables alternative instructions
|
||||
patching (CPU alternatives feature).
|
||||
|
||||
noapic [SMP,APIC,EARLY] Tells the kernel to not make use of any
|
||||
IOAPICs that may be present in the system.
|
||||
|
||||
@ -3866,8 +3861,6 @@
|
||||
|
||||
no_entry_flush [PPC,EARLY] Don't flush the L1-D cache when entering the kernel.
|
||||
|
||||
noexec [IA-64]
|
||||
|
||||
noexec32 [X86-64]
|
||||
This affects only 32-bit executables.
|
||||
noexec32=on: enable non-executable mappings (default)
|
||||
@ -3887,13 +3880,6 @@
|
||||
register save and restore. The kernel will only save
|
||||
legacy floating-point registers on task switch.
|
||||
|
||||
nohalt [IA-64] Tells the kernel not to use the power saving
|
||||
function PAL_HALT_LIGHT when idle. This increases
|
||||
power-consumption. On the positive side, it reduces
|
||||
interrupt wake-up latency, which may improve performance
|
||||
in certain environments such as networked servers or
|
||||
real-time systems.
|
||||
|
||||
no_hash_pointers
|
||||
[KNL,EARLY]
|
||||
Force pointers printed to the console or buffers to be
|
||||
@ -3911,7 +3897,7 @@
|
||||
|
||||
nohibernate [HIBERNATION] Disable hibernation and resume.
|
||||
|
||||
nohlt [ARM,ARM64,MICROBLAZE,MIPS,PPC,SH] Forces the kernel to
|
||||
nohlt [ARM,ARM64,MICROBLAZE,MIPS,PPC,RISCV,SH] Forces the kernel to
|
||||
busy wait in do_idle() and not use the arch_cpu_idle()
|
||||
implementation; requires CONFIG_GENERIC_IDLE_POLL_SETUP
|
||||
to be effective. This is useful on platforms where the
|
||||
@ -3948,8 +3934,6 @@
|
||||
remapping.
|
||||
[Deprecated - use intremap=off]
|
||||
|
||||
nointroute [IA-64]
|
||||
|
||||
noinvpcid [X86,EARLY] Disable the INVPCID cpu feature.
|
||||
|
||||
noiotrap [SH] Disables trapped I/O port accesses.
|
||||
@ -3959,8 +3943,6 @@
|
||||
|
||||
noisapnp [ISAPNP] Disables ISA PnP code.
|
||||
|
||||
nojitter [IA-64] Disables jitter checking for ITC timers.
|
||||
|
||||
nokaslr [KNL,EARLY]
|
||||
When CONFIG_RANDOMIZE_BASE is set, this disables
|
||||
kernel and module base offset ASLR (Address Space
|
||||
@ -3975,8 +3957,6 @@
|
||||
|
||||
nolapic_timer [X86-32,APIC,EARLY] Do not use the local APIC timer.
|
||||
|
||||
nomca [IA-64] Disable machine check abort handling
|
||||
|
||||
nomce [X86-32] Disable Machine Check Exception
|
||||
|
||||
nomfgpt [X86-32] Disable Multi-Function General Purpose
|
||||
@ -4028,8 +4008,6 @@
|
||||
noresume [SWSUSP] Disables resume and restores original swap
|
||||
space.
|
||||
|
||||
nosbagart [IA-64]
|
||||
|
||||
no-scroll [VGA] Disables scrollback.
|
||||
This is required for the Braillex ib80-piezo Braille
|
||||
reader made by F.H. Papenmeier (Germany).
|
||||
@ -4073,9 +4051,9 @@
|
||||
prediction) vulnerability. System may allow data
|
||||
leaks with this option.
|
||||
|
||||
no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES,RISCV,EARLY] Disable
|
||||
paravirtualized steal time accounting. steal time is
|
||||
computed, but won't influence scheduler behaviour
|
||||
no-steal-acc [X86,PV_OPS,ARM64,PPC/PSERIES,RISCV,LOONGARCH,EARLY]
|
||||
Disable paravirtualized steal time accounting. steal time
|
||||
is computed, but won't influence scheduler behaviour
|
||||
|
||||
nosync [HW,M68K] Disables sync negotiation for all devices.
|
||||
|
||||
@ -4130,19 +4108,6 @@
|
||||
parameter, xsave area per process might occupy more
|
||||
memory on xsaves enabled systems.
|
||||
|
||||
nps_mtm_hs_ctr= [KNL,ARC]
|
||||
This parameter sets the maximum duration, in
|
||||
cycles, each HW thread of the CTOP can run
|
||||
without interruptions, before HW switches it.
|
||||
The actual maximum duration is 16 times this
|
||||
parameter's value.
|
||||
Format: integer between 1 and 255
|
||||
Default: 255
|
||||
|
||||
nptcg= [IA-64] Override max number of concurrent global TLB
|
||||
purges which is reported from either PAL_VM_SUMMARY or
|
||||
SAL PALO.
|
||||
|
||||
nr_cpus= [SMP,EARLY] Maximum number of processors that an SMP kernel
|
||||
could support. nr_cpus=n : n >= 1 limits the kernel to
|
||||
support 'n' processors. It could be larger than the
|
||||
@ -4616,6 +4581,38 @@
|
||||
bridges without forcing it upstream. Note:
|
||||
this removes isolation between devices and
|
||||
may put more devices in an IOMMU group.
|
||||
config_acs=
|
||||
Format:
|
||||
<ACS flags>@<pci_dev>[; ...]
|
||||
Specify one or more PCI devices (in the format
|
||||
specified above) optionally prepended with flags
|
||||
and separated by semicolons. The respective
|
||||
capabilities will be enabled, disabled or
|
||||
unchanged based on what is specified in
|
||||
flags.
|
||||
|
||||
ACS Flags is defined as follows:
|
||||
bit-0 : ACS Source Validation
|
||||
bit-1 : ACS Translation Blocking
|
||||
bit-2 : ACS P2P Request Redirect
|
||||
bit-3 : ACS P2P Completion Redirect
|
||||
bit-4 : ACS Upstream Forwarding
|
||||
bit-5 : ACS P2P Egress Control
|
||||
bit-6 : ACS Direct Translated P2P
|
||||
Each bit can be marked as:
|
||||
'0' – force disabled
|
||||
'1' – force enabled
|
||||
'x' – unchanged
|
||||
For example,
|
||||
pci=config_acs=10x
|
||||
would configure all devices that support
|
||||
ACS to enable P2P Request Redirect, disable
|
||||
Translation Blocking, and leave Source
|
||||
Validation unchanged from whatever power-up
|
||||
or firmware set it to.
|
||||
|
||||
Note: this may remove isolation between devices
|
||||
and may put more devices in an IOMMU group.
|
||||
force_floating [S390] Force usage of floating interrupts.
|
||||
nomio [S390] Do not use MIO instructions.
|
||||
norid [S390] ignore the RID field and force use of
|
||||
@ -4749,7 +4746,9 @@
|
||||
none - Limited to cond_resched() calls
|
||||
voluntary - Limited to cond_resched() and might_sleep() calls
|
||||
full - Any section that isn't explicitly preempt disabled
|
||||
can be preempted anytime.
|
||||
can be preempted anytime. Tasks will also yield
|
||||
contended spinlocks (if the critical section isn't
|
||||
explicitly preempt disabled beyond the lock itself).
|
||||
|
||||
print-fatal-signals=
|
||||
[KNL] debug: print fatal signals
|
||||
@ -4799,11 +4798,9 @@
|
||||
|
||||
profile= [KNL] Enable kernel profiling via /proc/profile
|
||||
Format: [<profiletype>,]<number>
|
||||
Param: <profiletype>: "schedule", "sleep", or "kvm"
|
||||
Param: <profiletype>: "schedule" or "kvm"
|
||||
[defaults to kernel profiling]
|
||||
Param: "schedule" - profile schedule points.
|
||||
Param: "sleep" - profile D-state sleeping (millisecs).
|
||||
Requires CONFIG_SCHEDSTATS
|
||||
Param: "kvm" - profile VM exits.
|
||||
Param: <number> - step/bucket size as a power of 2 for
|
||||
statistical time based profiling.
|
||||
@ -5015,6 +5012,14 @@
|
||||
the ->nocb_bypass queue. The definition of "too
|
||||
many" is supplied by this kernel boot parameter.
|
||||
|
||||
rcutree.nohz_full_patience_delay= [KNL]
|
||||
On callback-offloaded (rcu_nocbs) CPUs, avoid
|
||||
disturbing RCU unless the grace period has
|
||||
reached the specified age in milliseconds.
|
||||
Defaults to zero. Large values will be capped
|
||||
at five seconds. All values will be rounded down
|
||||
to the nearest value representable by jiffies.
|
||||
|
||||
rcutree.qhimark= [KNL]
|
||||
Set threshold of queued RCU callbacks beyond which
|
||||
batch limiting is disabled.
|
||||
@ -5685,6 +5690,28 @@
|
||||
them. If <base> is less than 0x10000, the region
|
||||
is assumed to be I/O ports; otherwise it is memory.
|
||||
|
||||
reserve_mem= [RAM]
|
||||
Format: nn[KNG]:<align>:<label>
|
||||
Reserve physical memory and label it with a name that
|
||||
other subsystems can use to access it. This is typically
|
||||
used for systems that do not wipe the RAM, and this command
|
||||
line will try to reserve the same physical memory on
|
||||
soft reboots. Note, it is not guaranteed to be the same
|
||||
location. For example, if anything about the system changes
|
||||
or if booting a different kernel. It can also fail if KASLR
|
||||
places the kernel at the location of where the RAM reservation
|
||||
was from a previous boot, the new reservation will be at a
|
||||
different location.
|
||||
Any subsystem using this feature must add a way to verify
|
||||
that the contents of the physical memory is from a previous
|
||||
boot, as there may be cases where the memory will not be
|
||||
located at the same location.
|
||||
|
||||
The format is size:align:label for example, to request
|
||||
12 megabytes of 4096 alignment for ramoops:
|
||||
|
||||
reserve_mem=12M:4096:oops ramoops.mem_name=oops
|
||||
|
||||
reservetop= [X86-32,EARLY]
|
||||
Format: nn[KMG]
|
||||
Reserves a hole at the top of the kernel virtual
|
||||
@ -5763,9 +5790,6 @@
|
||||
2 The "airplane mode" button toggles between everything
|
||||
blocked and everything unblocked.
|
||||
|
||||
rhash_entries= [KNL,NET]
|
||||
Set number of hash buckets for route cache
|
||||
|
||||
ring3mwait=disable
|
||||
[KNL] Disable ring 3 MONITOR/MWAIT feature on supported
|
||||
CPUs.
|
||||
@ -5999,9 +6023,6 @@
|
||||
apic=verbose is specified.
|
||||
Example: apic=debug show_lapic=all
|
||||
|
||||
simeth= [IA-64]
|
||||
simscsi=
|
||||
|
||||
slab_debug[=options[,slabs][;[options[,slabs]]...] [MM]
|
||||
Enabling slab_debug allows one to determine the
|
||||
culprit if slab objects become corrupted. Enabling
|
||||
@ -6117,9 +6138,15 @@
|
||||
deployment of the HW BHI control and the SW BHB
|
||||
clearing sequence.
|
||||
|
||||
on - (default) Enable the HW or SW mitigation
|
||||
as needed.
|
||||
off - Disable the mitigation.
|
||||
on - (default) Enable the HW or SW mitigation as
|
||||
needed. This protects the kernel from
|
||||
both syscalls and VMs.
|
||||
vmexit - On systems which don't have the HW mitigation
|
||||
available, enable the SW mitigation on vmexit
|
||||
ONLY. On such systems, the host kernel is
|
||||
protected from VM-originated BHI attacks, but
|
||||
may still be vulnerable to syscall attacks.
|
||||
off - Disable the mitigation.
|
||||
|
||||
spectre_v2= [X86,EARLY] Control mitigation of Spectre variant 2
|
||||
(indirect branch speculation) vulnerability.
|
||||
@ -6263,11 +6290,6 @@
|
||||
Not specifying this option is equivalent to
|
||||
spec_store_bypass_disable=auto.
|
||||
|
||||
spia_io_base= [HW,MTD]
|
||||
spia_fio_base=
|
||||
spia_pedr=
|
||||
spia_peddr=
|
||||
|
||||
split_lock_detect=
|
||||
[X86] Enable split lock detection or bus lock detection
|
||||
|
||||
@ -6523,7 +6545,7 @@
|
||||
This parameter controls use of the Protected
|
||||
Execution Facility on pSeries.
|
||||
|
||||
swiotlb= [ARM,IA-64,PPC,MIPS,X86,EARLY]
|
||||
swiotlb= [ARM,PPC,MIPS,X86,S390,EARLY]
|
||||
Format: { <int> [,<int>] | force | noforce }
|
||||
<int> -- Number of I/O TLB slabs
|
||||
<int> -- Second integer after comma. Number of swiotlb
|
||||
@ -6604,12 +6626,6 @@
|
||||
e.g. base its process migration decisions on it.
|
||||
Default is on.
|
||||
|
||||
topology_updates= [KNL, PPC, NUMA]
|
||||
Format: {off}
|
||||
Specify if the kernel should ignore (off)
|
||||
topology updates sent by the hypervisor to this
|
||||
LPAR.
|
||||
|
||||
torture.disable_onoff_at_boot= [KNL]
|
||||
Prevent the CPU-hotplug component of torturing
|
||||
until after init has spawned.
|
||||
@ -6629,8 +6645,6 @@
|
||||
torture.verbose_sleep_duration= [KNL]
|
||||
Duration of each verbose-printk() sleep in jiffies.
|
||||
|
||||
tp720= [HW,PS2]
|
||||
|
||||
tpm_suspend_pcr=[HW,TPM]
|
||||
Format: integer pcr id
|
||||
Specify that at suspend time, the tpm driver
|
||||
@ -7074,6 +7088,9 @@
|
||||
usb-storage.delay_use=
|
||||
[UMS] The delay in seconds before a new device is
|
||||
scanned for Logical Units (default 1).
|
||||
Optionally the delay in milliseconds if the value has
|
||||
suffix with "ms".
|
||||
Example: delay_use=2567ms
|
||||
|
||||
usb-storage.quirks=
|
||||
[UMS] A list of quirks entries to supplement or
|
||||
@ -7167,9 +7184,6 @@
|
||||
Try vdso32=0 if you encounter an error that says:
|
||||
dl_main: Assertion `(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso' failed!
|
||||
|
||||
vector= [IA-64,SMP]
|
||||
vector=percpu: enable percpu vector domain
|
||||
|
||||
video= [FB,EARLY] Frame buffer configuration
|
||||
See Documentation/fb/modedb.rst.
|
||||
|
||||
@ -7220,9 +7234,12 @@
|
||||
|
||||
vmalloc=nn[KMG] [KNL,BOOT,EARLY] Forces the vmalloc area to have an
|
||||
exact size of <nn>. This can be used to increase
|
||||
the minimum size (128MB on x86). It can also be
|
||||
used to decrease the size and leave more room
|
||||
for directly mapped kernel RAM.
|
||||
the minimum size (128MB on x86, arm32 platforms).
|
||||
It can also be used to decrease the size and leave more room
|
||||
for directly mapped kernel RAM. Note that this parameter does
|
||||
not exist on many other platforms (including arm64, alpha,
|
||||
loongarch, arc, csky, hexagon, microblaze, mips, nios2, openrisc,
|
||||
parisc, m64k, powerpc, riscv, sh, um, xtensa, s390, sparc).
|
||||
|
||||
vmcp_cma=nn[MG] [KNL,S390,EARLY]
|
||||
Sets the memory size reserved for contiguous memory
|
||||
@ -7427,17 +7444,18 @@
|
||||
Crash from Xen panic notifier, without executing late
|
||||
panic() code such as dumping handler.
|
||||
|
||||
xen_mc_debug [X86,XEN,EARLY]
|
||||
Enable multicall debugging when running as a Xen PV guest.
|
||||
Enabling this feature will reduce performance a little
|
||||
bit, so it should only be enabled for obtaining extended
|
||||
debug data in case of multicall errors.
|
||||
|
||||
xen_msr_safe= [X86,XEN,EARLY]
|
||||
Format: <bool>
|
||||
Select whether to always use non-faulting (safe) MSR
|
||||
access functions when running as Xen PV guest. The
|
||||
default value is controlled by CONFIG_XEN_PV_MSR_SAFE.
|
||||
|
||||
xen_nopvspin [X86,XEN,EARLY]
|
||||
Disables the qspinlock slowpath using Xen PV optimizations.
|
||||
This parameter is obsoleted by "nopvspin" parameter, which
|
||||
has equivalent effect for XEN platform.
|
||||
|
||||
xen_nopv [X86]
|
||||
Disables the PV optimizations forcing the HVM guest to
|
||||
run as generic HVM guest with no PV drivers.
|
||||
|
||||
@ -438,3 +438,11 @@ EM28xx cards list
|
||||
- MyGica iGrabber
|
||||
- em2860
|
||||
- 1f4d:1abe
|
||||
* - 106
|
||||
- Hauppauge USB QuadHD ATSC
|
||||
- em28274
|
||||
- 2040:846d
|
||||
* - 107
|
||||
- MyGica UTV3 Analog USB2.0 TV Box
|
||||
- em2860
|
||||
- eb1a:2860
|
||||
|
||||
@ -135,16 +135,16 @@ sensor ov2740 on Lenovo X1 Yoga laptop.
|
||||
.. code-block:: none
|
||||
|
||||
media-ctl -l "\"ov2740 14-0036\":0 -> \"Intel IPU6 CSI2 1\":0[1]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":1 -> \"Intel IPU6 ISYS Capture 0\":0[5]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":2 -> \"Intel IPU6 ISYS Capture 1\":0[5]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":1 -> \"Intel IPU6 ISYS Capture 0\":0[1]"
|
||||
media-ctl -l "\"Intel IPU6 CSI2 1\":2 -> \"Intel IPU6 ISYS Capture 1\":0[1]"
|
||||
|
||||
# set routing
|
||||
media-ctl -v -R "\"Intel IPU6 CSI2 1\" [0/0->1/0[1],0/1->2/1[1]]"
|
||||
media-ctl -R "\"Intel IPU6 CSI2 1\" [0/0->1/0[1],0/1->2/1[1]]"
|
||||
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":0/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":0/1 [fmt:GENERIC_8/97x1]"
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":1/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -v "\"Intel IPU6 CSI2 1\":2/1 [fmt:GENERIC_8/97x1]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":0/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":0/1 [fmt:GENERIC_8/97x1]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":1/0 [fmt:SGRBG10/1932x1092]"
|
||||
media-ctl -V "\"Intel IPU6 CSI2 1\":2/1 [fmt:GENERIC_8/97x1]"
|
||||
|
||||
CAPTURE_DEV=$(media-ctl -e "Intel IPU6 ISYS Capture 0")
|
||||
./yavta --data-prefix -c100 -n5 -I -s1932x1092 --file=/tmp/frame-#.bin \
|
||||
|
||||
20
Documentation/admin-guide/media/raspberrypi-pisp-be.dot
Normal file
20
Documentation/admin-guide/media/raspberrypi-pisp-be.dot
Normal file
@ -0,0 +1,20 @@
|
||||
digraph board {
|
||||
rankdir=TB
|
||||
n00000001 [label="{{<port0> 0 | <port1> 1 | <port2> 2 | <port7> 7} | pispbe\n | {<port3> 3 | <port4> 4 | <port5> 5 | <port6> 6}}", shape=Mrecord, style=filled, fillcolor=green]
|
||||
n00000001:port3 -> n0000001c [style=bold]
|
||||
n00000001:port4 -> n00000022 [style=bold]
|
||||
n00000001:port5 -> n00000028 [style=bold]
|
||||
n00000001:port6 -> n0000002e [style=bold]
|
||||
n0000000a [label="pispbe-input\n/dev/video0", shape=box, style=filled, fillcolor=yellow]
|
||||
n0000000a -> n00000001:port0 [style=bold]
|
||||
n00000010 [label="pispbe-tdn_input\n/dev/video1", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000010 -> n00000001:port1 [style=bold]
|
||||
n00000016 [label="pispbe-stitch_input\n/dev/video2", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000016 -> n00000001:port2 [style=bold]
|
||||
n0000001c [label="pispbe-output0\n/dev/video3", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000022 [label="pispbe-output1\n/dev/video4", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000028 [label="pispbe-tdn_output\n/dev/video5", shape=box, style=filled, fillcolor=yellow]
|
||||
n0000002e [label="pispbe-stitch_output\n/dev/video6", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000034 [label="pispbe-config\n/dev/video7", shape=box, style=filled, fillcolor=yellow]
|
||||
n00000034 -> n00000001:port7 [style=bold]
|
||||
}
|
||||
109
Documentation/admin-guide/media/raspberrypi-pisp-be.rst
Normal file
109
Documentation/admin-guide/media/raspberrypi-pisp-be.rst
Normal file
@ -0,0 +1,109 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=========================================================
|
||||
Raspberry Pi PiSP Back End Memory-to-Memory ISP (pisp-be)
|
||||
=========================================================
|
||||
|
||||
The PiSP Back End
|
||||
=================
|
||||
|
||||
The PiSP Back End is a memory-to-memory Image Signal Processor (ISP) which reads
|
||||
image data from DRAM memory and performs image processing as specified by the
|
||||
application through the parameters in a configuration buffer, before writing
|
||||
pixel data back to memory through two distinct output channels.
|
||||
|
||||
The ISP registers and programming model are documented in the `Raspberry Pi
|
||||
Image Signal Processor (PiSP) Specification document`_
|
||||
|
||||
The PiSP Back End ISP processes images in tiles. The handling of image
|
||||
tessellation and the computation of low-level configuration parameters is
|
||||
realized by a free software library called `libpisp
|
||||
<https://github.com/raspberrypi/libpisp>`_.
|
||||
|
||||
The full image processing pipeline, which involves capturing RAW Bayer data from
|
||||
an image sensor through a MIPI CSI-2 compatible capture interface, storing them
|
||||
in DRAM memory and processing them in the PiSP Back End to obtain images usable
|
||||
by an application is implemented in `libcamera <https://libcamera.org>`_ as
|
||||
part of the Raspberry Pi platform support.
|
||||
|
||||
The pisp-be driver
|
||||
==================
|
||||
|
||||
The Raspberry Pi PiSP Back End (pisp-be) driver is located under
|
||||
drivers/media/platform/raspberrypi/pisp-be. It uses the `V4L2 API` to register
|
||||
a number of video capture and output devices, the `V4L2 subdev API` to register
|
||||
a subdevice for the ISP that connects the video devices in a single media graph
|
||||
realized using the `Media Controller (MC) API`.
|
||||
|
||||
The media topology registered by the `pisp-be` driver is represented below:
|
||||
|
||||
.. _pips-be-topology:
|
||||
|
||||
.. kernel-figure:: raspberrypi-pisp-be.dot
|
||||
:alt: Diagram of the default media pipeline topology
|
||||
:align: center
|
||||
|
||||
|
||||
The media graph registers the following video device nodes:
|
||||
|
||||
- pispbe-input: output device for images to be submitted to the ISP for
|
||||
processing.
|
||||
- pispbe-tdn_input: output device for temporal denoise.
|
||||
- pispbe-stitch_input: output device for image stitching (HDR).
|
||||
- pispbe-output0: first capture device for processed images.
|
||||
- pispbe-output1: second capture device for processed images.
|
||||
- pispbe-tdn_output: capture device for temporal denoise.
|
||||
- pispbe-stitch_output: capture device for image stitching (HDR).
|
||||
- pispbe-config: output device for ISP configuration parameters.
|
||||
|
||||
pispbe-input
|
||||
------------
|
||||
|
||||
Images to be processed by the ISP are queued to the `pispbe-input` output device
|
||||
node. For a list of image formats supported as input to the ISP refer to the
|
||||
`Raspberry Pi Image Signal Processor (PiSP) Specification document`_.
|
||||
|
||||
pispbe-tdn_input, pispbe-tdn_output
|
||||
-----------------------------------
|
||||
|
||||
The `pispbe-tdn_input` output video device receives images to be processed by
|
||||
the temporal denoise block which are captured from the `pispbe-tdn_output`
|
||||
capture video device. Userspace is responsible for maintaining queues on both
|
||||
devices, and ensuring that buffers completed on the output are queued to the
|
||||
input.
|
||||
|
||||
pispbe-stitch_input, pispbe-stitch_output
|
||||
-----------------------------------------
|
||||
|
||||
To realize HDR (high dynamic range) image processing the image stitching and
|
||||
tonemapping blocks are used. The `pispbe-stitch_output` writes images to memory
|
||||
and the `pispbe-stitch_input` receives the previously written frame to process
|
||||
it along with the current input image. Userspace is responsible for maintaining
|
||||
queues on both devices, and ensuring that buffers completed on the output are
|
||||
queued to the input.
|
||||
|
||||
pispbe-output0, pispbe-output1
|
||||
------------------------------
|
||||
|
||||
The two capture devices write to memory the pixel data as processed by the ISP.
|
||||
|
||||
pispbe-config
|
||||
-------------
|
||||
|
||||
The `pispbe-config` output video devices receives a buffer of configuration
|
||||
parameters that define the desired image processing to be performed by the ISP.
|
||||
|
||||
The format of the ISP configuration parameter is defined by
|
||||
:c:type:`pisp_be_tiles_config` C structure and the meaning of each parameter is
|
||||
described in the `Raspberry Pi Image Signal Processor (PiSP) Specification
|
||||
document`_.
|
||||
|
||||
ISP configuration
|
||||
=================
|
||||
|
||||
The ISP configuration is described solely by the content of the parameters
|
||||
buffer. The only parameter that userspace needs to configure using the V4L2 API
|
||||
is the image format on the output and capture video devices for validation of
|
||||
the content of the parameters buffer.
|
||||
|
||||
.. _Raspberry Pi Image Signal Processor (PiSP) Specification document: https://datasheets.raspberrypi.com/camera/raspberry-pi-image-signal-processor-specification.pdf
|
||||
@ -97,4 +97,6 @@ Tuner number Card name
|
||||
89 Sony BTF-PG472Z PAL/SECAM
|
||||
90 Sony BTF-PK467Z NTSC-M-JP
|
||||
91 Sony BTF-PB463Z NTSC-M
|
||||
92 Silicon Labs Si2157 tuner
|
||||
93 Tena TNF931D-DFDR1
|
||||
============ =====================================================
|
||||
|
||||
@ -23,6 +23,7 @@ Video4Linux (V4L) driver-specific documentation
|
||||
omap4_camera
|
||||
philips
|
||||
qcom_camss
|
||||
raspberrypi-pisp-be
|
||||
rcar-fdp1
|
||||
rkisp1
|
||||
saa7134
|
||||
|
||||
@ -302,6 +302,15 @@ all configurable using the following module options:
|
||||
- 0: forbid hints
|
||||
- 1: allow hints
|
||||
|
||||
- supports_requests:
|
||||
|
||||
specifies if the device should support the Request API. There are
|
||||
three possible values, default is 1:
|
||||
|
||||
- 0: no request
|
||||
- 1: supports requests
|
||||
- 2: requires requests
|
||||
|
||||
Taken together, all these module options allow you to precisely customize
|
||||
the driver behavior and test your application with all sorts of permutations.
|
||||
It is also very suitable to emulate hardware that is not yet available, e.g.
|
||||
@ -313,10 +322,10 @@ Video Capture
|
||||
|
||||
This is probably the most frequently used feature. The video capture device
|
||||
can be configured by using the module options num_inputs, input_types and
|
||||
ccs_cap_mode (see section 1 for more detailed information), but by default
|
||||
four inputs are configured: a webcam, a TV tuner, an S-Video and an HDMI
|
||||
input, one input for each input type. Those are described in more detail
|
||||
below.
|
||||
ccs_cap_mode (see "Configuring the driver" for more detailed information),
|
||||
but by default four inputs are configured: a webcam, a TV tuner, an S-Video
|
||||
and an HDMI input, one input for each input type. Those are described in more
|
||||
detail below.
|
||||
|
||||
Special attention has been given to the rate at which new frames become
|
||||
available. The jitter will be around 1 jiffie (that depends on the HZ
|
||||
@ -434,10 +443,10 @@ Video Output
|
||||
------------
|
||||
|
||||
The video output device can be configured by using the module options
|
||||
num_outputs, output_types and ccs_out_mode (see section 1 for more detailed
|
||||
information), but by default two outputs are configured: an S-Video and an
|
||||
HDMI input, one output for each output type. Those are described in more detail
|
||||
below.
|
||||
num_outputs, output_types and ccs_out_mode (see "Configuring the driver"
|
||||
for more detailed information), but by default two outputs are configured:
|
||||
an S-Video and an HDMI input, one output for each output type. Those are
|
||||
described in more detail below.
|
||||
|
||||
Like with video capture the framerate is also exact in the long term.
|
||||
|
||||
@ -1011,11 +1020,6 @@ Digital Video Controls
|
||||
affects the reported colorspace since DVI_D outputs will always use
|
||||
sRGB.
|
||||
|
||||
- Display Present:
|
||||
|
||||
sets the presence of a "display" on the HDMI output. This affects
|
||||
the tx_edid_present, tx_hotplug and tx_rxsense controls.
|
||||
|
||||
|
||||
FM Radio Receiver Controls
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@ -1130,35 +1134,34 @@ Metadata Capture Controls
|
||||
|
||||
if set, then the generated metadata stream contains Source Clock information.
|
||||
|
||||
Video, VBI and RDS Looping
|
||||
--------------------------
|
||||
|
||||
The vivid driver supports looping of video output to video input, VBI output
|
||||
to VBI input and RDS output to RDS input. For video/VBI looping this emulates
|
||||
as if a cable was hooked up between the output and input connector. So video
|
||||
and VBI looping is only supported between S-Video and HDMI inputs and outputs.
|
||||
VBI is only valid for S-Video as it makes no sense for HDMI.
|
||||
Video, Sliced VBI and HDMI CEC Looping
|
||||
--------------------------------------
|
||||
|
||||
Since radio is wireless this looping always happens if the radio receiver
|
||||
frequency is close to the radio transmitter frequency. In that case the radio
|
||||
transmitter will 'override' the emulated radio stations.
|
||||
Video Looping functionality is supported for devices created by the same
|
||||
vivid driver instance, as well as across multiple instances of the vivid driver.
|
||||
The vivid driver supports looping of video and Sliced VBI data between an S-Video output
|
||||
and an S-Video input. It also supports looping of video and HDMI CEC data between an
|
||||
HDMI output and an HDMI input.
|
||||
|
||||
Looping is currently supported only between devices created by the same
|
||||
vivid driver instance.
|
||||
To enable looping, set the 'HDMI/S-Video XXX-N Is Connected To' control(s) to select
|
||||
whether an input uses the Test Pattern Generator, or is disconnected, or is connected
|
||||
to an output. An input can be connected to an output from any vivid instance.
|
||||
The inputs and outputs are numbered XXX-N where XXX is the vivid instance number
|
||||
(see module option n_devs). If there is only one vivid instance (the default), then
|
||||
XXX will be 000. And N is the Nth S-Video/HDMI input or output of that instance.
|
||||
If vivid is loaded without module options, then you can connect the S-Video 000-0 input
|
||||
to the S-Video 000-0 output, or the HDMI 000-0 input to the HDMI 000-0 output.
|
||||
This is the equivalent of connecting or disconnecting a cable between an input and an
|
||||
output in a physical device.
|
||||
|
||||
If an 'HDMI/S-Video XXX-N Is Connected To' control selected an output, then the video
|
||||
output will be looped to the video input provided that:
|
||||
|
||||
Video and Sliced VBI looping
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
- the currently selected input matches the input indicated by the control name.
|
||||
|
||||
The way to enable video/VBI looping is currently fairly crude. A 'Loop Video'
|
||||
control is available in the "Vivid" control class of the video
|
||||
capture and VBI capture devices. When checked the video looping will be enabled.
|
||||
Once enabled any video S-Video or HDMI input will show a static test pattern
|
||||
until the video output has started. At that time the video output will be
|
||||
looped to the video input provided that:
|
||||
|
||||
- the input type matches the output type. So the HDMI input cannot receive
|
||||
video from the S-Video output.
|
||||
- in the vivid instance of the output connector, the currently selected output matches
|
||||
the output indicated by the control's value.
|
||||
|
||||
- the video resolution of the video input must match that of the video output.
|
||||
So it is not possible to loop a 50 Hz (720x576) S-Video output to a 60 Hz
|
||||
@ -1185,6 +1188,8 @@ looped to the video input provided that:
|
||||
"DV Timings Signal Mode" for the HDMI input should be configured so that a
|
||||
valid signal is passed to the video input.
|
||||
|
||||
If any condition is not valid, then the 'Noise' test pattern is shown.
|
||||
|
||||
The framerates do not have to match, although this might change in the future.
|
||||
|
||||
By default you will see the OSD text superimposed on top of the looped video.
|
||||
@ -1198,17 +1203,26 @@ and WSS (50 Hz formats) VBI data is looped. Teletext VBI data is not looped.
|
||||
|
||||
|
||||
Radio & RDS Looping
|
||||
~~~~~~~~~~~~~~~~~~~
|
||||
-------------------
|
||||
|
||||
As mentioned in section 6 the radio receiver emulates stations are regular
|
||||
frequency intervals. Depending on the frequency of the radio receiver a
|
||||
signal strength value is calculated (this is returned by VIDIOC_G_TUNER).
|
||||
However, it will also look at the frequency set by the radio transmitter and
|
||||
if that results in a higher signal strength than the settings of the radio
|
||||
transmitter will be used as if it was a valid station. This also includes
|
||||
the RDS data (if any) that the transmitter 'transmits'. This is received
|
||||
faithfully on the receiver side. Note that when the driver is loaded the
|
||||
frequencies of the radio receiver and transmitter are not identical, so
|
||||
The vivid driver supports looping of RDS output to RDS input.
|
||||
|
||||
Since radio is wireless this looping always happens if the radio receiver
|
||||
frequency is close to the radio transmitter frequency. In that case the radio
|
||||
transmitter will 'override' the emulated radio stations.
|
||||
|
||||
RDS looping is currently supported only between devices created by the same
|
||||
vivid driver instance.
|
||||
|
||||
As mentioned in the "Radio Receiver" section, the radio receiver emulates
|
||||
stations at regular frequency intervals. Depending on the frequency of the
|
||||
radio receiver a signal strength value is calculated (this is returned by
|
||||
VIDIOC_G_TUNER). However, it will also look at the frequency set by the radio
|
||||
transmitter and if that results in a higher signal strength than the settings
|
||||
of the radio transmitter will be used as if it was a valid station. This also
|
||||
includes the RDS data (if any) that the transmitter 'transmits'. This is
|
||||
received faithfully on the receiver side. Note that when the driver is loaded
|
||||
the frequencies of the radio receiver and transmitter are not identical, so
|
||||
initially no looping takes place.
|
||||
|
||||
|
||||
@ -1218,8 +1232,8 @@ Cropping, Composing, Scaling
|
||||
This driver supports cropping, composing and scaling in any combination. Normally
|
||||
which features are supported can be selected through the Vivid controls,
|
||||
but it is also possible to hardcode it when the module is loaded through the
|
||||
ccs_cap_mode and ccs_out_mode module options. See section 1 on the details of
|
||||
these module options.
|
||||
ccs_cap_mode and ccs_out_mode module options. See "Configuring the driver" on
|
||||
the details of these module options.
|
||||
|
||||
This allows you to test your application for all these variations.
|
||||
|
||||
@ -1260,7 +1274,8 @@ is set, then the alpha component is only used for the color red and set to
|
||||
|
||||
The driver has to be configured to support the multiplanar formats. By default
|
||||
the driver instances are single-planar. This can be changed by setting the
|
||||
multiplanar module option, see section 1 for more details on that option.
|
||||
multiplanar module option, see "Configuring the driver" for more details on that
|
||||
option.
|
||||
|
||||
If the driver instance is using the multiplanar formats/API, then the first
|
||||
single planar format (YUYV) and the multiplanar NV16M and NV61M formats the
|
||||
@ -1270,74 +1285,6 @@ data_offset to be non-zero, so this is a useful feature for testing applications
|
||||
Video output will also honor any data_offset that the application set.
|
||||
|
||||
|
||||
Capture Overlay
|
||||
---------------
|
||||
|
||||
Note: capture overlay support is implemented primarily to test the existing
|
||||
V4L2 capture overlay API. In practice few if any GPUs support such overlays
|
||||
anymore, and neither are they generally needed anymore since modern hardware
|
||||
is so much more capable. By setting flag 0x10000 in the node_types module
|
||||
option the vivid driver will create a simple framebuffer device that can be
|
||||
used for testing this API. Whether this API should be used for new drivers is
|
||||
questionable.
|
||||
|
||||
This driver has support for a destructive capture overlay with bitmap clipping
|
||||
and list clipping (up to 16 rectangles) capabilities. Overlays are not
|
||||
supported for multiplanar formats. It also honors the struct v4l2_window field
|
||||
setting: if it is set to FIELD_TOP or FIELD_BOTTOM and the capture setting is
|
||||
FIELD_ALTERNATE, then only the top or bottom fields will be copied to the overlay.
|
||||
|
||||
The overlay only works if you are also capturing at that same time. This is a
|
||||
vivid limitation since it copies from a buffer to the overlay instead of
|
||||
filling the overlay directly. And if you are not capturing, then no buffers
|
||||
are available to fill.
|
||||
|
||||
In addition, the pixelformat of the capture format and that of the framebuffer
|
||||
must be the same for the overlay to work. Otherwise VIDIOC_OVERLAY will return
|
||||
an error.
|
||||
|
||||
In order to really see what it going on you will need to create two vivid
|
||||
instances: the first with a framebuffer enabled. You configure the capture
|
||||
overlay of the second instance to use the framebuffer of the first, then
|
||||
you start capturing in the second instance. For the first instance you setup
|
||||
the output overlay for the video output, turn on video looping and capture
|
||||
to see the blended framebuffer overlay that's being written to by the second
|
||||
instance. This setup would require the following commands:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ sudo modprobe vivid n_devs=2 node_types=0x10101,0x1
|
||||
$ v4l2-ctl -d1 --find-fb
|
||||
/dev/fb1 is the framebuffer associated with base address 0x12800000
|
||||
$ sudo v4l2-ctl -d2 --set-fbuf fb=1
|
||||
$ v4l2-ctl -d1 --set-fbuf fb=1
|
||||
$ v4l2-ctl -d0 --set-fmt-video=pixelformat='AR15'
|
||||
$ v4l2-ctl -d1 --set-fmt-video-out=pixelformat='AR15'
|
||||
$ v4l2-ctl -d2 --set-fmt-video=pixelformat='AR15'
|
||||
$ v4l2-ctl -d0 -i2
|
||||
$ v4l2-ctl -d2 -i2
|
||||
$ v4l2-ctl -d2 -c horizontal_movement=4
|
||||
$ v4l2-ctl -d1 --overlay=1
|
||||
$ v4l2-ctl -d0 -c loop_video=1
|
||||
$ v4l2-ctl -d2 --stream-mmap --overlay=1
|
||||
|
||||
And from another console:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ v4l2-ctl -d1 --stream-out-mmap
|
||||
|
||||
And yet another console:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ qv4l2
|
||||
|
||||
and start streaming.
|
||||
|
||||
As you can see, this is not for the faint of heart...
|
||||
|
||||
|
||||
Output Overlay
|
||||
--------------
|
||||
|
||||
@ -1405,8 +1352,6 @@ Just as a reminder and in no particular order:
|
||||
- Add ARGB888 overlay support: better testing of the alpha channel
|
||||
- Improve pixel aspect support in the tpg code by passing a real v4l2_fract
|
||||
- Use per-queue locks and/or per-device locks to improve throughput
|
||||
- Add support to loop from a specific output to a specific input across
|
||||
vivid instances
|
||||
- The SDR radio should use the same 'frequencies' for stations as the normal
|
||||
radio receiver, and give back noise if the frequency doesn't match up with
|
||||
a station frequency
|
||||
|
||||
@ -34,18 +34,56 @@ detail) of DAMON, you should ensure :doc:`sysfs </filesystems/sysfs>` is
|
||||
mounted.
|
||||
|
||||
|
||||
Snapshot Data Access Patterns
|
||||
=============================
|
||||
|
||||
The commands below show the memory access pattern of a program at the moment of
|
||||
the execution. ::
|
||||
|
||||
$ git clone https://github.com/sjp38/masim; cd masim; make
|
||||
$ sudo damo start "./masim ./configs/stairs.cfg --quiet"
|
||||
$ sudo ./damo show
|
||||
0 addr [85.541 TiB , 85.541 TiB ) (57.707 MiB ) access 0 % age 10.400 s
|
||||
1 addr [85.541 TiB , 85.542 TiB ) (413.285 MiB) access 0 % age 11.400 s
|
||||
2 addr [127.649 TiB , 127.649 TiB) (57.500 MiB ) access 0 % age 1.600 s
|
||||
3 addr [127.649 TiB , 127.649 TiB) (32.500 MiB ) access 0 % age 500 ms
|
||||
4 addr [127.649 TiB , 127.649 TiB) (9.535 MiB ) access 100 % age 300 ms
|
||||
5 addr [127.649 TiB , 127.649 TiB) (8.000 KiB ) access 60 % age 0 ns
|
||||
6 addr [127.649 TiB , 127.649 TiB) (6.926 MiB ) access 0 % age 1 s
|
||||
7 addr [127.998 TiB , 127.998 TiB) (120.000 KiB) access 0 % age 11.100 s
|
||||
8 addr [127.998 TiB , 127.998 TiB) (8.000 KiB ) access 40 % age 100 ms
|
||||
9 addr [127.998 TiB , 127.998 TiB) (4.000 KiB ) access 0 % age 11 s
|
||||
total size: 577.590 MiB
|
||||
$ sudo ./damo stop
|
||||
|
||||
The first command of the above example downloads and builds an artificial
|
||||
memory access generator program called ``masim``. The second command asks DAMO
|
||||
to execute the artificial generator process start via the given command and
|
||||
make DAMON monitors the generator process. The third command retrieves the
|
||||
current snapshot of the monitored access pattern of the process from DAMON and
|
||||
shows the pattern in a human readable format.
|
||||
|
||||
Each line of the output shows which virtual address range (``addr [XX, XX)``)
|
||||
of the process is how frequently (``access XX %``) accessed for how long time
|
||||
(``age XX``). For example, the fifth region of ~9 MiB size is being most
|
||||
frequently accessed for last 300 milliseconds. Finally, the fourth command
|
||||
stops DAMON.
|
||||
|
||||
Note that DAMON can monitor not only virtual address spaces but multiple types
|
||||
of address spaces including the physical address space.
|
||||
|
||||
|
||||
Recording Data Access Patterns
|
||||
==============================
|
||||
|
||||
The commands below record the memory access patterns of a program and save the
|
||||
monitoring results to a file. ::
|
||||
|
||||
$ git clone https://github.com/sjp38/masim
|
||||
$ cd masim; make; ./masim ./configs/zigzag.cfg &
|
||||
$ ./masim ./configs/zigzag.cfg &
|
||||
$ sudo damo record -o damon.data $(pidof masim)
|
||||
|
||||
The first two lines of the commands download an artificial memory access
|
||||
generator program and run it in the background. The generator will repeatedly
|
||||
The line of the commands run the artificial memory access
|
||||
generator program again. The generator will repeatedly
|
||||
access two 100 MiB sized memory regions one by one. You can substitute this
|
||||
with your real workload. The last line asks ``damo`` to record the access
|
||||
pattern in the ``damon.data`` file.
|
||||
|
||||
@ -78,7 +78,7 @@ comma (",").
|
||||
│ │ │ │ │ │ │ │ ...
|
||||
│ │ │ │ │ │ ...
|
||||
│ │ │ │ │ :ref:`schemes <sysfs_schemes>`/nr_schemes
|
||||
│ │ │ │ │ │ :ref:`0 <sysfs_scheme>`/action,apply_interval_us
|
||||
│ │ │ │ │ │ :ref:`0 <sysfs_scheme>`/action,target_nid,apply_interval_us
|
||||
│ │ │ │ │ │ │ :ref:`access_pattern <sysfs_access_pattern>`/
|
||||
│ │ │ │ │ │ │ │ sz/min,max
|
||||
│ │ │ │ │ │ │ │ nr_accesses/min,max
|
||||
@ -289,14 +289,18 @@ schemes/<N>/
|
||||
------------
|
||||
|
||||
In each scheme directory, five directories (``access_pattern``, ``quotas``,
|
||||
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and two files
|
||||
(``action`` and ``apply_interval``) exist.
|
||||
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and three files
|
||||
(``action``, ``target_nid`` and ``apply_interval``) exist.
|
||||
|
||||
The ``action`` file is for setting and getting the scheme's :ref:`action
|
||||
<damon_design_damos_action>`. The keywords that can be written to and read
|
||||
from the file and their meaning are same to those of the list on
|
||||
:ref:`design doc <damon_design_damos_action>`.
|
||||
|
||||
The ``target_nid`` file is for setting the migration target node, which is
|
||||
only meaningful when the ``action`` is either ``migrate_hot`` or
|
||||
``migrate_cold``.
|
||||
|
||||
The ``apply_interval_us`` file is for setting and getting the scheme's
|
||||
:ref:`apply_interval <damon_design_damos>` in microseconds.
|
||||
|
||||
|
||||
@ -10,7 +10,7 @@ processes address space and many other cool things.
|
||||
|
||||
Linux memory management is a complex system with many configurable
|
||||
settings. Most of these settings are available via ``/proc``
|
||||
filesystem and can be quired and adjusted using ``sysctl``. These APIs
|
||||
filesystem and can be queried and adjusted using ``sysctl``. These APIs
|
||||
are described in Documentation/admin-guide/sysctl/vm.rst and in `man 5 proc`_.
|
||||
|
||||
.. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html
|
||||
|
||||
@ -118,7 +118,7 @@ Short descriptions to the page flags
|
||||
21 - KSM
|
||||
Identical memory pages dynamically shared between one or more processes.
|
||||
22 - THP
|
||||
Contiguous pages which construct transparent hugepages.
|
||||
Contiguous pages which construct THP of any size and mapped by any granularity.
|
||||
23 - OFFLINE
|
||||
The page is logically offline.
|
||||
24 - ZERO_PAGE
|
||||
@ -173,27 +173,6 @@ LRU related page flags
|
||||
The page-types tool in the tools/mm directory can be used to query the
|
||||
above flags.
|
||||
|
||||
Using pagemap to do something useful
|
||||
====================================
|
||||
|
||||
The general procedure for using pagemap to find out about a process' memory
|
||||
usage goes like this:
|
||||
|
||||
1. Read ``/proc/pid/maps`` to determine which parts of the memory space are
|
||||
mapped to what.
|
||||
2. Select the maps you are interested in -- all of them, or a particular
|
||||
library, or the stack or the heap, etc.
|
||||
3. Open ``/proc/pid/pagemap`` and seek to the pages you would like to examine.
|
||||
4. Read a u64 for each page from pagemap.
|
||||
5. Open ``/proc/kpagecount`` and/or ``/proc/kpageflags``. For each PFN you
|
||||
just read, seek to that entry in the file, and read the data you want.
|
||||
|
||||
For example, to find the "unique set size" (USS), which is the amount of
|
||||
memory that a process is using that is not shared with any other process,
|
||||
you can go through every map in the process, find the PFNs, look those up
|
||||
in kpagecount, and tally up the number of pages that are only referenced
|
||||
once.
|
||||
|
||||
Exceptions for Shared Memory
|
||||
============================
|
||||
|
||||
@ -252,7 +231,7 @@ Following flags about pages are currently supported:
|
||||
- ``PAGE_IS_PRESENT`` - Page is present in the memory
|
||||
- ``PAGE_IS_SWAPPED`` - Page is in swapped
|
||||
- ``PAGE_IS_PFNZERO`` - Page has zero PFN
|
||||
- ``PAGE_IS_HUGE`` - Page is THP or Hugetlb backed
|
||||
- ``PAGE_IS_HUGE`` - Page is PMD-mapped THP or Hugetlb backed
|
||||
- ``PAGE_IS_SOFT_DIRTY`` - Page is soft-dirty
|
||||
|
||||
The ``struct pm_scan_arg`` is used as the argument of the IOCTL.
|
||||
|
||||
@ -202,12 +202,11 @@ PMD-mappable transparent hugepage::
|
||||
|
||||
cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
|
||||
|
||||
khugepaged will be automatically started when one or more hugepage
|
||||
sizes are enabled (either by directly setting "always" or "madvise",
|
||||
or by setting "inherit" while the top-level enabled is set to "always"
|
||||
or "madvise"), and it'll be automatically shutdown when the last
|
||||
hugepage size is disabled (either by directly setting "never", or by
|
||||
setting "inherit" while the top-level enabled is set to "never").
|
||||
khugepaged will be automatically started when PMD-sized THP is enabled
|
||||
(either of the per-size anon control or the top-level control are set
|
||||
to "always" or "madvise"), and it'll be automatically shutdown when
|
||||
PMD-sized THP is disabled (when both the per-size anon control and the
|
||||
top-level control are "never")
|
||||
|
||||
Khugepaged controls
|
||||
-------------------
|
||||
@ -332,6 +331,31 @@ deny
|
||||
force
|
||||
Force the huge option on for all - very useful for testing;
|
||||
|
||||
Shmem can also use "multi-size THP" (mTHP) by adding a new sysfs knob to
|
||||
control mTHP allocation:
|
||||
'/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/shmem_enabled',
|
||||
and its value for each mTHP is essentially consistent with the global
|
||||
setting. An 'inherit' option is added to ensure compatibility with these
|
||||
global settings. Conversely, the options 'force' and 'deny' are dropped,
|
||||
which are rather testing artifacts from the old ages.
|
||||
|
||||
always
|
||||
Attempt to allocate <size> huge pages every time we need a new page;
|
||||
|
||||
inherit
|
||||
Inherit the top-level "shmem_enabled" value. By default, PMD-sized hugepages
|
||||
have enabled="inherit" and all other hugepage sizes have enabled="never";
|
||||
|
||||
never
|
||||
Do not allocate <size> huge pages;
|
||||
|
||||
within_size
|
||||
Only allocate <size> huge page if it will be fully within i_size.
|
||||
Also respect fadvise()/madvise() hints;
|
||||
|
||||
advise
|
||||
Only allocate <size> huge pages if requested with fadvise()/madvise();
|
||||
|
||||
Need of application restart
|
||||
===========================
|
||||
|
||||
@ -344,10 +368,6 @@ also applies to the regions registered in khugepaged.
|
||||
Monitoring usage
|
||||
================
|
||||
|
||||
.. note::
|
||||
Currently the below counters only record events relating to
|
||||
PMD-sized THP. Events relating to other THP sizes are not included.
|
||||
|
||||
The number of PMD-sized anonymous transparent huge pages currently used by the
|
||||
system is available by reading the AnonHugePages field in ``/proc/meminfo``.
|
||||
To identify what applications are using PMD-sized anonymous transparent huge
|
||||
@ -392,20 +412,23 @@ thp_collapse_alloc_failed
|
||||
the allocation.
|
||||
|
||||
thp_file_alloc
|
||||
is incremented every time a file huge page is successfully
|
||||
allocated.
|
||||
is incremented every time a shmem huge page is successfully
|
||||
allocated (Note that despite being named after "file", the counter
|
||||
measures only shmem).
|
||||
|
||||
thp_file_fallback
|
||||
is incremented if a file huge page is attempted to be allocated
|
||||
but fails and instead falls back to using small pages.
|
||||
is incremented if a shmem huge page is attempted to be allocated
|
||||
but fails and instead falls back to using small pages. (Note that
|
||||
despite being named after "file", the counter measures only shmem).
|
||||
|
||||
thp_file_fallback_charge
|
||||
is incremented if a file huge page cannot be charged and instead
|
||||
is incremented if a shmem huge page cannot be charged and instead
|
||||
falls back to using small pages even though the allocation was
|
||||
successful.
|
||||
successful. (Note that despite being named after "file", the
|
||||
counter measures only shmem).
|
||||
|
||||
thp_file_mapped
|
||||
is incremented every time a file huge page is mapped into
|
||||
is incremented every time a file or shmem huge page is mapped into
|
||||
user address space.
|
||||
|
||||
thp_split_page
|
||||
@ -476,6 +499,34 @@ swpout_fallback
|
||||
Usually because failed to allocate some continuous swap space
|
||||
for the huge page.
|
||||
|
||||
shmem_alloc
|
||||
is incremented every time a shmem huge page is successfully
|
||||
allocated.
|
||||
|
||||
shmem_fallback
|
||||
is incremented if a shmem huge page is attempted to be allocated
|
||||
but fails and instead falls back to using small pages.
|
||||
|
||||
shmem_fallback_charge
|
||||
is incremented if a shmem huge page cannot be charged and instead
|
||||
falls back to using small pages even though the allocation was
|
||||
successful.
|
||||
|
||||
split
|
||||
is incremented every time a huge page is successfully split into
|
||||
smaller orders. This can happen for a variety of reasons but a
|
||||
common reason is that a huge page is old and is being reclaimed.
|
||||
|
||||
split_failed
|
||||
is incremented if kernel fails to split huge
|
||||
page. This can happen if the page was pinned by somebody.
|
||||
|
||||
split_deferred
|
||||
is incremented when a huge page is put onto split queue.
|
||||
This happens when a huge page is partially unmapped and splitting
|
||||
it would free up some memory. Pages on split queue are going to
|
||||
be split under memory pressure, if splitting is possible.
|
||||
|
||||
As the system ages, allocating huge pages may be expensive as the
|
||||
system uses memory compaction to copy data around memory to free a
|
||||
huge page for use. There are some counters in ``/proc/vmstat`` to help
|
||||
|
||||
@ -281,6 +281,22 @@ integer values defined between 0 to 255 when EPP feature is enabled by platform
|
||||
firmware, if EPP feature is disabled, driver will ignore the written value
|
||||
This attribute is read-write.
|
||||
|
||||
``boost``
|
||||
The `boost` sysfs attribute provides control over the CPU core
|
||||
performance boost, allowing users to manage the maximum frequency limitation
|
||||
of the CPU. This attribute can be used to enable or disable the boost feature
|
||||
on individual CPUs.
|
||||
|
||||
When the boost feature is enabled, the CPU can dynamically increase its frequency
|
||||
beyond the base frequency, providing enhanced performance for demanding workloads.
|
||||
On the other hand, disabling the boost feature restricts the CPU to operate at the
|
||||
base frequency, which may be desirable in certain scenarios to prioritize power
|
||||
efficiency or manage temperature.
|
||||
|
||||
To manipulate the `boost` attribute, users can write a value of `0` to disable the
|
||||
boost or `1` to enable it, for the respective CPU using the sysfs path
|
||||
`/sys/devices/system/cpu/cpuX/cpufreq/boost`, where `X` represents the CPU number.
|
||||
|
||||
Other performance and frequency values can be read back from
|
||||
``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`.
|
||||
|
||||
@ -406,7 +422,7 @@ control its functionality at the system level. They are located in the
|
||||
``/sys/devices/system/cpu/amd_pstate/`` directory and affect all CPUs.
|
||||
|
||||
``status``
|
||||
Operation mode of the driver: "active", "passive" or "disable".
|
||||
Operation mode of the driver: "active", "passive", "guided" or "disable".
|
||||
|
||||
"active"
|
||||
The driver is functional and in the ``active mode``
|
||||
|
||||
@ -267,6 +267,10 @@ are the following:
|
||||
``related_cpus``
|
||||
List of all (online and offline) CPUs belonging to this policy.
|
||||
|
||||
``scaling_available_frequencies``
|
||||
List of available frequencies of the CPUs belonging to this policy
|
||||
(in kHz).
|
||||
|
||||
``scaling_available_governors``
|
||||
List of ``CPUFreq`` scaling governors present in the kernel that can
|
||||
be attached to this policy or (if the |intel_pstate| scaling driver is
|
||||
|
||||
@ -1,24 +0,0 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Set udev rules for PMF Smart PC Builder
|
||||
---------------------------------------
|
||||
|
||||
AMD PMF(Platform Management Framework) Smart PC Solution builder has to set the system states
|
||||
like S0i3, Screen lock, hibernate etc, based on the output actions provided by the PMF
|
||||
TA (Trusted Application).
|
||||
|
||||
In order for this to work the PMF driver generates a uevent for userspace to react to. Below are
|
||||
sample udev rules that can facilitate this experience when a machine has PMF Smart PC solution builder
|
||||
enabled.
|
||||
|
||||
Please add the following line(s) to
|
||||
``/etc/udev/rules.d/99-local.rules``::
|
||||
|
||||
DRIVERS=="amd-pmf", ACTION=="change", ENV{EVENT_ID}=="0", RUN+="/usr/bin/systemctl suspend"
|
||||
DRIVERS=="amd-pmf", ACTION=="change", ENV{EVENT_ID}=="1", RUN+="/usr/bin/systemctl hibernate"
|
||||
DRIVERS=="amd-pmf", ACTION=="change", ENV{EVENT_ID}=="2", RUN+="/bin/loginctl lock-sessions"
|
||||
|
||||
EVENT_ID values:
|
||||
0= Put the system to S0i3/S2Idle
|
||||
1= Put the system to hibernate
|
||||
2= Lock the screen
|
||||
@ -23,6 +23,8 @@ and type of the memory area are set using three variables:
|
||||
* ``mem_size`` for the size. The memory size will be rounded down to a
|
||||
power of two.
|
||||
* ``mem_type`` to specify if the memory type (default is pgprot_writecombine).
|
||||
* ``mem_name`` to specify a memory region defined by ``reserve_mem`` command
|
||||
line parameter.
|
||||
|
||||
Typically the default value of ``mem_type=0`` should be used as that sets the pstore
|
||||
mapping to pgprot_writecombine. Setting ``mem_type=1`` attempts to use
|
||||
@ -118,6 +120,17 @@ Setting the ramoops parameters can be done in several different manners:
|
||||
return ret;
|
||||
}
|
||||
|
||||
D. Using a region of memory reserved via ``reserve_mem`` command line
|
||||
parameter. The address and size will be defined by the ``reserve_mem``
|
||||
parameter. Note, that ``reserve_mem`` may not always allocate memory
|
||||
in the same location, and cannot be relied upon. Testing will need
|
||||
to be done, and it may not work on every machine, nor every kernel.
|
||||
Consider this a "best effort" approach. The ``reserve_mem`` option
|
||||
takes a size, alignment and name as arguments. The name is used
|
||||
to map the memory to a label that can be retrieved by ramoops.
|
||||
|
||||
reserver_mem=2M:4096:oops ramoops.mem_name=oops
|
||||
|
||||
You can specify either RAM memory or peripheral devices' memory. However, when
|
||||
specifying RAM, be sure to reserve the memory by issuing memblock_reserve()
|
||||
very early in the architecture code, e.g.::
|
||||
|
||||
@ -454,7 +454,7 @@ ignore-unaligned-usertrap
|
||||
|
||||
On architectures where unaligned accesses cause traps, and where this
|
||||
feature is supported (``CONFIG_SYSCTL_ARCH_UNALIGN_NO_WARN``;
|
||||
currently, ``arc`` and ``loongarch``), controls whether all
|
||||
currently, ``arc``, ``parisc`` and ``loongarch``), controls whether all
|
||||
unaligned traps are logged.
|
||||
|
||||
= =============================================================
|
||||
|
||||
@ -36,6 +36,7 @@ Currently, these files are in /proc/sys/vm:
|
||||
- dirtytime_expire_seconds
|
||||
- dirty_writeback_centisecs
|
||||
- drop_caches
|
||||
- enable_soft_offline
|
||||
- extfrag_threshold
|
||||
- highmem_is_dirtyable
|
||||
- hugetlb_shm_group
|
||||
@ -267,6 +268,43 @@ used::
|
||||
These are informational only. They do not mean that anything is wrong
|
||||
with your system. To disable them, echo 4 (bit 2) into drop_caches.
|
||||
|
||||
enable_soft_offline
|
||||
===================
|
||||
Correctable memory errors are very common on servers. Soft-offline is kernel's
|
||||
solution for memory pages having (excessive) corrected memory errors.
|
||||
|
||||
For different types of page, soft-offline has different behaviors / costs.
|
||||
|
||||
- For a raw error page, soft-offline migrates the in-use page's content to
|
||||
a new raw page.
|
||||
|
||||
- For a page that is part of a transparent hugepage, soft-offline splits the
|
||||
transparent hugepage into raw pages, then migrates only the raw error page.
|
||||
As a result, user is transparently backed by 1 less hugepage, impacting
|
||||
memory access performance.
|
||||
|
||||
- For a page that is part of a HugeTLB hugepage, soft-offline first migrates
|
||||
the entire HugeTLB hugepage, during which a free hugepage will be consumed
|
||||
as migration target. Then the original hugepage is dissolved into raw
|
||||
pages without compensation, reducing the capacity of the HugeTLB pool by 1.
|
||||
|
||||
It is user's call to choose between reliability (staying away from fragile
|
||||
physical memory) vs performance / capacity implications in transparent and
|
||||
HugeTLB cases.
|
||||
|
||||
For all architectures, enable_soft_offline controls whether to soft offline
|
||||
memory pages. When set to 1, kernel attempts to soft offline the pages
|
||||
whenever it thinks needed. When set to 0, kernel returns EOPNOTSUPP to
|
||||
the request to soft offline the pages. Its default value is 1.
|
||||
|
||||
It is worth mentioning that after setting enable_soft_offline to 0, the
|
||||
following requests to soft offline pages will not be performed:
|
||||
|
||||
- Request to soft offline pages from RAS Correctable Errors Collector.
|
||||
|
||||
- On ARM, the request to soft offline pages from GHES driver.
|
||||
|
||||
- On PARISC, the request to soft offline pages from Page Deallocation Table.
|
||||
|
||||
extfrag_threshold
|
||||
=================
|
||||
|
||||
@ -23,7 +23,7 @@ mistakes occasionally made even by experienced developers.
|
||||
up in the reference section, then jump back to where you left off.
|
||||
..
|
||||
Find the latest rendered version of this text here:
|
||||
https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.rst.html
|
||||
https://docs.kernel.org/admin-guide/verify-bugs-and-bisect-regressions.html
|
||||
|
||||
The essence of the process (aka 'TL;DR')
|
||||
========================================
|
||||
|
||||
79
Documentation/arch/arm64/cpu-hotplug.rst
Normal file
79
Documentation/arch/arm64/cpu-hotplug.rst
Normal file
@ -0,0 +1,79 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. _cpuhp_index:
|
||||
|
||||
====================
|
||||
CPU Hotplug and ACPI
|
||||
====================
|
||||
|
||||
CPU hotplug in the arm64 world is commonly used to describe the kernel taking
|
||||
CPUs online/offline using PSCI. This document is about ACPI firmware allowing
|
||||
CPUs that were not available during boot to be added to the system later.
|
||||
|
||||
``possible`` and ``present`` refer to the state of the CPU as seen by linux.
|
||||
|
||||
|
||||
CPU Hotplug on physical systems - CPUs not present at boot
|
||||
----------------------------------------------------------
|
||||
|
||||
Physical systems need to mark a CPU that is ``possible`` but not ``present`` as
|
||||
being ``present``. An example would be a dual socket machine, where the package
|
||||
in one of the sockets can be replaced while the system is running.
|
||||
|
||||
This is not supported.
|
||||
|
||||
In the arm64 world CPUs are not a single device but a slice of the system.
|
||||
There are no systems that support the physical addition (or removal) of CPUs
|
||||
while the system is running, and ACPI is not able to sufficiently describe
|
||||
them.
|
||||
|
||||
e.g. New CPUs come with new caches, but the platform's cache toplogy is
|
||||
described in a static table, the PPTT. How caches are shared between CPUs is
|
||||
not discoverable, and must be described by firmware.
|
||||
|
||||
e.g. The GIC redistributor for each CPU must be accessed by the driver during
|
||||
boot to discover the system wide supported features. ACPI's MADT GICC
|
||||
structures can describe a redistributor associated with a disabled CPU, but
|
||||
can't describe whether the redistributor is accessible, only that it is not
|
||||
'always on'.
|
||||
|
||||
arm64's ACPI tables assume that everything described is ``present``.
|
||||
|
||||
|
||||
CPU Hotplug on virtual systems - CPUs not enabled at boot
|
||||
---------------------------------------------------------
|
||||
|
||||
Virtual systems have the advantage that all the properties the system will
|
||||
ever have can be described at boot. There are no power-domain considerations
|
||||
as such devices are emulated.
|
||||
|
||||
CPU Hotplug on virtual systems is supported. It is distinct from physical
|
||||
CPU Hotplug as all resources are described as ``present``, but CPUs may be
|
||||
marked as disabled by firmware. Only the CPU's online/offline behaviour is
|
||||
influenced by firmware. An example is where a virtual machine boots with a
|
||||
single CPU, and additional CPUs are added once a cloud orchestrator deploys
|
||||
the workload.
|
||||
|
||||
For a virtual machine, the VMM (e.g. Qemu) plays the part of firmware.
|
||||
|
||||
Virtual hotplug is implemented as a firmware policy affecting which CPUs can be
|
||||
brought online. Firmware can enforce its policy via PSCI's return codes. e.g.
|
||||
``DENIED``.
|
||||
|
||||
The ACPI tables must describe all the resources of the virtual machine. CPUs
|
||||
that firmware wishes to disable either from boot (or later) should not be
|
||||
``enabled`` in the MADT GICC structures, but should have the ``online capable``
|
||||
bit set, to indicate they can be enabled later. The boot CPU must be marked as
|
||||
``enabled``. The 'always on' GICR structure must be used to describe the
|
||||
redistributors.
|
||||
|
||||
CPUs described as ``online capable`` but not ``enabled`` can be set to enabled
|
||||
by the DSDT's Processor object's _STA method. On virtual systems the _STA method
|
||||
must always report the CPU as ``present``. Changes to the firmware policy can
|
||||
be notified to the OS via device-check or eject-request.
|
||||
|
||||
CPUs described as ``enabled`` in the static table, should not have their _STA
|
||||
modified dynamically by firmware. Soft-restart features such as kexec will
|
||||
re-read the static properties of the system from these static tables, and
|
||||
may malfunction if these no longer describe the running system. Linux will
|
||||
re-discover the dynamic properties of the system from the _STA method later
|
||||
during boot.
|
||||
@ -13,6 +13,7 @@ ARM64 Architecture
|
||||
asymmetric-32bit
|
||||
booting
|
||||
cpu-feature-registers
|
||||
cpu-hotplug
|
||||
elf_hwcaps
|
||||
hugetlbpage
|
||||
kdump
|
||||
|
||||
@ -18,12 +18,10 @@ ARMv8.2 adds optional support for Large Virtual Address space. This is
|
||||
only available when running with a 64KB page size and expands the
|
||||
number of descriptors in the first level of translation.
|
||||
|
||||
User addresses have bits 63:48 set to 0 while the kernel addresses have
|
||||
the same bits set to 1. TTBRx selection is given by bit 63 of the
|
||||
virtual address. The swapper_pg_dir contains only kernel (global)
|
||||
mappings while the user pgd contains only user (non-global) mappings.
|
||||
The swapper_pg_dir address is written to TTBR1 and never written to
|
||||
TTBR0.
|
||||
TTBRx selection is given by bit 55 of the virtual address. The
|
||||
swapper_pg_dir contains only kernel (global) mappings while the user pgd
|
||||
contains only user (non-global) mappings. The swapper_pg_dir address is
|
||||
written to TTBR1 and never written to TTBR0.
|
||||
|
||||
|
||||
AArch64 Linux memory layout with 4KB pages + 4 levels (48-bit)::
|
||||
@ -65,14 +63,14 @@ Translation table lookup with 4KB pages::
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | | |
|
||||
| | | | | v
|
||||
| | | | | [11:0] in-page offset
|
||||
| | | | +-> [20:12] L3 index
|
||||
| | | +-----------> [29:21] L2 index
|
||||
| | +---------------------> [38:30] L1 index
|
||||
| +-------------------------------> [47:39] L0 index
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
| | | | | |
|
||||
| | | | | v
|
||||
| | | | | [11:0] in-page offset
|
||||
| | | | +-> [20:12] L3 index
|
||||
| | | +-----------> [29:21] L2 index
|
||||
| | +---------------------> [38:30] L1 index
|
||||
| +-------------------------------> [47:39] L0 index
|
||||
+----------------------------------------> [55] TTBR0/1
|
||||
|
||||
|
||||
Translation table lookup with 64KB pages::
|
||||
@ -80,14 +78,14 @@ Translation table lookup with 64KB pages::
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
|63 56|55 48|47 40|39 32|31 24|23 16|15 8|7 0|
|
||||
+--------+--------+--------+--------+--------+--------+--------+--------+
|
||||
| | | | |
|
||||
| | | | v
|
||||
| | | | [15:0] in-page offset
|
||||
| | | +----------> [28:16] L3 index
|
||||
| | +--------------------------> [41:29] L2 index
|
||||
| +-------------------------------> [47:42] L1 index (48-bit)
|
||||
| [51:42] L1 index (52-bit)
|
||||
+-------------------------------------------------> [63] TTBR0/1
|
||||
| | | | |
|
||||
| | | | v
|
||||
| | | | [15:0] in-page offset
|
||||
| | | +----------> [28:16] L3 index
|
||||
| | +--------------------------> [41:29] L2 index
|
||||
| +-------------------------------> [47:42] L1 index (48-bit)
|
||||
| [51:42] L1 index (52-bit)
|
||||
+----------------------------------------> [55] TTBR0/1
|
||||
|
||||
|
||||
When using KVM without the Virtualization Host Extensions, the
|
||||
|
||||
@ -122,26 +122,50 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A76 | #1490853 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A76 | #3324349 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1491015 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A77 | #3324348 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A78 | #3324344 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A78C | #3324346,3324347| ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A710 | #3324338 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1 | #1502854 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1 | #3324344 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X1C | #3324346 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X2 | #3324338 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X3 | #3324335 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-X925 | #3324334 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1349291 | N/A |
|
||||
@ -150,15 +174,23 @@ stable kernels.
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #1542419 | ARM64_ERRATUM_1542419 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N1 | #3324349 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2139208 | ARM64_ERRATUM_2139208 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2067961 | ARM64_ERRATUM_2067961 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #2253138 | ARM64_ERRATUM_2253138 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #1619801 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3312417 |
|
||||
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | MMU-500 | #841119,826419 | N/A |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
||||
@ -128,24 +128,6 @@ IBM BookE
|
||||
- All 32 bit::
|
||||
|
||||
+--------------+
|
||||
| 401 |
|
||||
+--------------+
|
||||
|
|
||||
|
|
||||
v
|
||||
+--------------+
|
||||
| 403 |
|
||||
+--------------+
|
||||
|
|
||||
|
|
||||
v
|
||||
+--------------+
|
||||
| 405 |
|
||||
+--------------+
|
||||
|
|
||||
|
|
||||
v
|
||||
+--------------+
|
||||
| 440 |
|
||||
+--------------+
|
||||
|
|
||||
|
||||
@ -91,6 +91,7 @@ PPC_FEATURE_HAS_MMU
|
||||
|
||||
PPC_FEATURE_HAS_4xxMAC
|
||||
The processor is 40x or 44x family.
|
||||
Unused in the kernel since 732b32daef80 ("powerpc: Remove core support for 40x")
|
||||
|
||||
PPC_FEATURE_UNIFIED_CACHE
|
||||
The processor has a unified L1 cache for instructions and data, as
|
||||
|
||||
@ -546,7 +546,9 @@ table information.
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1052 | 0x08 | RW | T | CTRL |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1053-| | | | Reserved |
|
||||
| 0x1053 | 0x08 | RW | T | DPDES |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1054-| | | | Reserved |
|
||||
| 0x1FFF | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2000 | 0x04 | RW | T | CR |
|
||||
|
||||
@ -62,10 +62,10 @@ cmodx.c::
|
||||
printf("Value before cmodx: %d\n", value);
|
||||
|
||||
// Call prctl before first fence.i is called inside modify_instruction
|
||||
prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX_ON, PR_RISCV_CTX_SW_FENCEI, PR_RISCV_SCOPE_PER_PROCESS);
|
||||
prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI_ON, PR_RISCV_SCOPE_PER_PROCESS);
|
||||
modify_instruction();
|
||||
// Call prctl after final fence.i is called in process
|
||||
prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX_OFF, PR_RISCV_CTX_SW_FENCEI, PR_RISCV_SCOPE_PER_PROCESS);
|
||||
prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX, PR_RISCV_CTX_SW_FENCEI_OFF, PR_RISCV_SCOPE_PER_PROCESS);
|
||||
|
||||
value = get_value();
|
||||
printf("Value after cmodx: %d\n", value);
|
||||
|
||||
@ -192,6 +192,53 @@ The following keys are defined:
|
||||
supported as defined in the RISC-V ISA manual starting from commit
|
||||
d8ab5c78c207 ("Zihintpause is ratified").
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZVE32X`: The Vector sub-extension Zve32x is
|
||||
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZVE32F`: The Vector sub-extension Zve32f is
|
||||
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZVE64X`: The Vector sub-extension Zve64x is
|
||||
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZVE64F`: The Vector sub-extension Zve64f is
|
||||
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZVE64D`: The Vector sub-extension Zve64d is
|
||||
supported, as defined by version 1.0 of the RISC-V Vector extension manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZIMOP`: The Zimop May-Be-Operations extension is
|
||||
supported as defined in the RISC-V ISA manual starting from commit
|
||||
58220614a5f ("Zimop is ratified/1.0").
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZCA`: The Zca extension part of Zc* standard
|
||||
extensions for code size reduction, as ratified in commit 8be3419c1c0
|
||||
("Zcf doesn't exist on RV64 as it contains no instructions") of
|
||||
riscv-code-size-reduction.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZCB`: The Zcb extension part of Zc* standard
|
||||
extensions for code size reduction, as ratified in commit 8be3419c1c0
|
||||
("Zcf doesn't exist on RV64 as it contains no instructions") of
|
||||
riscv-code-size-reduction.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZCD`: The Zcd extension part of Zc* standard
|
||||
extensions for code size reduction, as ratified in commit 8be3419c1c0
|
||||
("Zcf doesn't exist on RV64 as it contains no instructions") of
|
||||
riscv-code-size-reduction.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZCF`: The Zcf extension part of Zc* standard
|
||||
extensions for code size reduction, as ratified in commit 8be3419c1c0
|
||||
("Zcf doesn't exist on RV64 as it contains no instructions") of
|
||||
riscv-code-size-reduction.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZCMOP`: The Zcmop May-Be-Operations extension is
|
||||
supported as defined in the RISC-V ISA manual starting from commit
|
||||
c732a4f39a4 ("Zcmop is ratified/1.0").
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZAWRS`: The Zawrs extension is supported as
|
||||
ratified in commit 98918c844281 ("Merge pull request #1217 from
|
||||
riscv/zawrs") of riscv-isa-manual.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
|
||||
information about the selected set of processors.
|
||||
|
||||
@ -214,3 +261,8 @@ The following keys are defined:
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
|
||||
represents the size of the Zicboz block in bytes.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_HIGHEST_VIRT_ADDRESS`: An unsigned long which
|
||||
represent the highest userspace virtual address usable.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_TIME_CSR_FREQ`: Frequency (in Hz) of `time CSR`.
|
||||
|
||||
@ -47,11 +47,12 @@ RISC-V Linux Kernel SV39
|
||||
| Kernel-space virtual memory, shared between all processes:
|
||||
____________________________________________________________|___________________________________________________________
|
||||
| | | |
|
||||
ffffffc6fea00000 | -228 GB | ffffffc6feffffff | 6 MB | fixmap
|
||||
ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io
|
||||
ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap
|
||||
ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space
|
||||
ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | direct mapping of all physical memory
|
||||
ffffffc4fea00000 | -236 GB | ffffffc4feffffff | 6 MB | fixmap
|
||||
ffffffc4ff000000 | -236 GB | ffffffc4ffffffff | 16 MB | PCI io
|
||||
ffffffc500000000 | -236 GB | ffffffc5ffffffff | 4 GB | vmemmap
|
||||
ffffffc600000000 | -232 GB | ffffffd5ffffffff | 64 GB | vmalloc/ioremap space
|
||||
ffffffd600000000 | -168 GB | fffffff5ffffffff | 128 GB | direct mapping of all physical memory
|
||||
| | | |
|
||||
fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan
|
||||
__________________|____________|__________________|_________|____________________________________________________________
|
||||
|
|
||||
|
||||
@ -130,4 +130,31 @@ SNP feature support.
|
||||
|
||||
More details in AMD64 APM[1] Vol 2: 15.34.10 SEV_STATUS MSR
|
||||
|
||||
[1] https://www.amd.com/content/dam/amd/en/documents/processor-tech-docs/programmer-references/24593.pdf
|
||||
Secure VM Service Module (SVSM)
|
||||
===============================
|
||||
SNP provides a feature called Virtual Machine Privilege Levels (VMPL) which
|
||||
defines four privilege levels at which guest software can run. The most
|
||||
privileged level is 0 and numerically higher numbers have lesser privileges.
|
||||
More details in the AMD64 APM Vol 2, section "15.35.7 Virtual Machine
|
||||
Privilege Levels", docID: 24593.
|
||||
|
||||
When using that feature, different services can run at different protection
|
||||
levels, apart from the guest OS but still within the secure SNP environment.
|
||||
They can provide services to the guest, like a vTPM, for example.
|
||||
|
||||
When a guest is not running at VMPL0, it needs to communicate with the software
|
||||
running at VMPL0 to perform privileged operations or to interact with secure
|
||||
services. An example fur such a privileged operation is PVALIDATE which is
|
||||
*required* to be executed at VMPL0.
|
||||
|
||||
In this scenario, the software running at VMPL0 is usually called a Secure VM
|
||||
Service Module (SVSM). Discovery of an SVSM and the API used to communicate
|
||||
with it is documented in "Secure VM Service Module for SEV-SNP Guests", docID:
|
||||
58019.
|
||||
|
||||
(Latest versions of the above-mentioned documents can be found by using
|
||||
a search engine like duckduckgo.com and typing in:
|
||||
|
||||
site:amd.com "Secure VM Service Module for SEV-SNP Guests", docID: 58019
|
||||
|
||||
for example.)
|
||||
|
||||
@ -112,7 +112,7 @@ conditions are met, the features are enabled by the set_cpu_cap or
|
||||
setup_force_cpu_cap macros. For example, if bit 5 is set in MSR_IA32_CORE_CAPS,
|
||||
the feature X86_FEATURE_SPLIT_LOCK_DETECT will be enabled and
|
||||
"split_lock_detect" will be displayed. The flag "ring3mwait" will be
|
||||
displayed only when running on INTEL_FAM6_XEON_PHI_[KNL|KNM] processors.
|
||||
displayed only when running on INTEL_XEON_PHI_[KNL|KNM] processors.
|
||||
|
||||
d: Flags can represent purely software features.
|
||||
------------------------------------------------
|
||||
|
||||
@ -297,7 +297,7 @@ vma occurs?
|
||||
c) execution continues at local label 2 (address of the
|
||||
instruction immediately after the faulting user access).
|
||||
|
||||
The steps 8a to 8c in a certain way emulate the faulting instruction.
|
||||
The steps a to c above in a certain way emulate the faulting instruction.
|
||||
|
||||
That's it, mostly. If you look at our example, you might ask why
|
||||
we set EAX to -EFAULT in the exception handler code. Well, the
|
||||
|
||||
@ -375,6 +375,10 @@ When monitoring is enabled all MON groups will also contain:
|
||||
all tasks in the group. In CTRL_MON groups these files provide
|
||||
the sum for all tasks in the CTRL_MON group and all tasks in
|
||||
MON groups. Please see example section for more details on usage.
|
||||
On systems with Sub-NUMA Cluster (SNC) enabled there are extra
|
||||
directories for each node (located within the "mon_L3_XX" directory
|
||||
for the L3 cache they occupy). These are named "mon_sub_L3_YY"
|
||||
where "YY" is the node number.
|
||||
|
||||
"mon_hw_id":
|
||||
Available only with debug option. The identifier used by hardware
|
||||
@ -484,6 +488,29 @@ if non-contiguous 1s value is supported. On a system with a 20-bit mask
|
||||
each bit represents 5% of the capacity of the cache. You could partition
|
||||
the cache into four equal parts with masks: 0x1f, 0x3e0, 0x7c00, 0xf8000.
|
||||
|
||||
Notes on Sub-NUMA Cluster mode
|
||||
==============================
|
||||
When SNC mode is enabled, Linux may load balance tasks between Sub-NUMA
|
||||
nodes much more readily than between regular NUMA nodes since the CPUs
|
||||
on Sub-NUMA nodes share the same L3 cache and the system may report
|
||||
the NUMA distance between Sub-NUMA nodes with a lower value than used
|
||||
for regular NUMA nodes.
|
||||
|
||||
The top-level monitoring files in each "mon_L3_XX" directory provide
|
||||
the sum of data across all SNC nodes sharing an L3 cache instance.
|
||||
Users who bind tasks to the CPUs of a specific Sub-NUMA node can read
|
||||
the "llc_occupancy", "mbm_total_bytes", and "mbm_local_bytes" in the
|
||||
"mon_sub_L3_YY" directories to get node local data.
|
||||
|
||||
Memory bandwidth allocation is still performed at the L3 cache
|
||||
level. I.e. throttling controls are applied to all SNC nodes.
|
||||
|
||||
L3 cache allocation bitmaps also apply to all SNC nodes. But note that
|
||||
the amount of L3 cache represented by each bit is divided by the number
|
||||
of SNC nodes per L3 cache. E.g. with a 100MB cache on a system with 10-bit
|
||||
allocation masks each bit normally represents 10MB. With SNC mode enabled
|
||||
with two SNC nodes per L3 cache, each bit only represents 5MB.
|
||||
|
||||
Memory bandwidth Allocation and monitoring
|
||||
==========================================
|
||||
|
||||
|
||||
@ -153,18 +153,11 @@ bio_free() will automatically free the bip.
|
||||
4.2 Block Device
|
||||
----------------
|
||||
|
||||
Because the format of the protection data is tied to the physical
|
||||
disk, each block device has been extended with a block integrity
|
||||
profile (struct blk_integrity). This optional profile is registered
|
||||
with the block layer using blk_integrity_register().
|
||||
|
||||
The profile contains callback functions for generating and verifying
|
||||
the protection data, as well as getting and setting application tags.
|
||||
The profile also contains a few constants to aid in completing,
|
||||
merging and splitting the integrity metadata.
|
||||
Block devices can set up the integrity information in the integrity
|
||||
sub-struture of the queue_limits structure.
|
||||
|
||||
Layered block devices will need to pick a profile that's appropriate
|
||||
for all subdevices. blk_integrity_compare() can help with that. DM
|
||||
for all subdevices. queue_limits_stack_integrity() can help with that. DM
|
||||
and MD linear, RAID0 and RAID1 are currently supported. RAID4/5/6
|
||||
will require extra work due to the application tag.
|
||||
|
||||
@ -250,42 +243,6 @@ will require extra work due to the application tag.
|
||||
integrity upon completion.
|
||||
|
||||
|
||||
5.4 Registering A Block Device As Capable Of Exchanging Integrity Metadata
|
||||
--------------------------------------------------------------------------
|
||||
|
||||
To enable integrity exchange on a block device the gendisk must be
|
||||
registered as capable:
|
||||
|
||||
`int blk_integrity_register(gendisk, blk_integrity);`
|
||||
|
||||
The blk_integrity struct is a template and should contain the
|
||||
following::
|
||||
|
||||
static struct blk_integrity my_profile = {
|
||||
.name = "STANDARDSBODY-TYPE-VARIANT-CSUM",
|
||||
.generate_fn = my_generate_fn,
|
||||
.verify_fn = my_verify_fn,
|
||||
.tuple_size = sizeof(struct my_tuple_size),
|
||||
.tag_size = <tag bytes per hw sector>,
|
||||
};
|
||||
|
||||
'name' is a text string which will be visible in sysfs. This is
|
||||
part of the userland API so chose it carefully and never change
|
||||
it. The format is standards body-type-variant.
|
||||
E.g. T10-DIF-TYPE1-IP or T13-EPP-0-CRC.
|
||||
|
||||
'generate_fn' generates appropriate integrity metadata (for WRITE).
|
||||
|
||||
'verify_fn' verifies that the data buffer matches the integrity
|
||||
metadata.
|
||||
|
||||
'tuple_size' must be set to match the size of the integrity
|
||||
metadata per sector. I.e. 8 for DIF and EPP.
|
||||
|
||||
'tag_size' must be set to identify how many bytes of tag space
|
||||
are available per hardware sector. For DIF this is either 2 or
|
||||
0 depending on the value of the Control Mode Page ATO bit.
|
||||
|
||||
----------------------------------------------------------------------
|
||||
|
||||
2007-12-24 Martin K. Petersen <martin.petersen@oracle.com>
|
||||
|
||||
@ -46,41 +46,50 @@ worry if the underlying devices need any explicit cache flushing and how
|
||||
the Forced Unit Access is implemented. The REQ_PREFLUSH and REQ_FUA flags
|
||||
may both be set on a single bio.
|
||||
|
||||
|
||||
Implementation details for bio based block drivers
|
||||
--------------------------------------------------------------
|
||||
|
||||
These drivers will always see the REQ_PREFLUSH and REQ_FUA bits as they sit
|
||||
directly below the submit_bio interface. For remapping drivers the REQ_FUA
|
||||
bits need to be propagated to underlying devices, and a global flush needs
|
||||
to be implemented for bios with the REQ_PREFLUSH bit set. For real device
|
||||
drivers that do not have a volatile cache the REQ_PREFLUSH and REQ_FUA bits
|
||||
on non-empty bios can simply be ignored, and REQ_PREFLUSH requests without
|
||||
data can be completed successfully without doing any work. Drivers for
|
||||
devices with volatile caches need to implement the support for these
|
||||
flags themselves without any help from the block layer.
|
||||
|
||||
|
||||
Implementation details for request_fn based block drivers
|
||||
---------------------------------------------------------
|
||||
Feature settings for block drivers
|
||||
----------------------------------
|
||||
|
||||
For devices that do not support volatile write caches there is no driver
|
||||
support required, the block layer completes empty REQ_PREFLUSH requests before
|
||||
entering the driver and strips off the REQ_PREFLUSH and REQ_FUA bits from
|
||||
requests that have a payload. For devices with volatile write caches the
|
||||
driver needs to tell the block layer that it supports flushing caches by
|
||||
doing::
|
||||
requests that have a payload.
|
||||
|
||||
blk_queue_write_cache(sdkp->disk->queue, true, false);
|
||||
For devices with volatile write caches the driver needs to tell the block layer
|
||||
that it supports flushing caches by setting the
|
||||
|
||||
and handle empty REQ_OP_FLUSH requests in its prep_fn/request_fn. Note that
|
||||
REQ_PREFLUSH requests with a payload are automatically turned into a sequence
|
||||
of an empty REQ_OP_FLUSH request followed by the actual write by the block
|
||||
layer. For devices that also support the FUA bit the block layer needs
|
||||
to be told to pass through the REQ_FUA bit using::
|
||||
BLK_FEAT_WRITE_CACHE
|
||||
|
||||
blk_queue_write_cache(sdkp->disk->queue, true, true);
|
||||
flag in the queue_limits feature field. For devices that also support the FUA
|
||||
bit the block layer needs to be told to pass on the REQ_FUA bit by also setting
|
||||
the
|
||||
|
||||
and the driver must handle write requests that have the REQ_FUA bit set
|
||||
in prep_fn/request_fn. If the FUA bit is not natively supported the block
|
||||
layer turns it into an empty REQ_OP_FLUSH request after the actual write.
|
||||
BLK_FEAT_FUA
|
||||
|
||||
flag in the features field of the queue_limits structure.
|
||||
|
||||
Implementation details for bio based block drivers
|
||||
--------------------------------------------------
|
||||
|
||||
For bio based drivers the REQ_PREFLUSH and REQ_FUA bit are simply passed on to
|
||||
the driver if the driver sets the BLK_FEAT_WRITE_CACHE flag and the driver
|
||||
needs to handle them.
|
||||
|
||||
*NOTE*: The REQ_FUA bit also gets passed on when the BLK_FEAT_FUA flags is
|
||||
_not_ set. Any bio based driver that sets BLK_FEAT_WRITE_CACHE also needs to
|
||||
handle REQ_FUA.
|
||||
|
||||
For remapping drivers the REQ_FUA bits need to be propagated to underlying
|
||||
devices, and a global flush needs to be implemented for bios with the
|
||||
REQ_PREFLUSH bit set.
|
||||
|
||||
Implementation details for blk-mq drivers
|
||||
-----------------------------------------
|
||||
|
||||
When the BLK_FEAT_WRITE_CACHE flag is set, REQ_OP_WRITE | REQ_PREFLUSH requests
|
||||
with a payload are automatically turned into a sequence of a REQ_OP_FLUSH
|
||||
request followed by the actual write by the block layer.
|
||||
|
||||
When the BLK_FEAT_FUA flags is set, the REQ_FUA bit is simply passed on for the
|
||||
REQ_OP_WRITE request, else a REQ_OP_FLUSH request is sent by the block layer
|
||||
after the completion of the write request for bio submissions with the REQ_FUA
|
||||
bit set.
|
||||
|
||||
@ -219,6 +219,14 @@ compilation and skeleton generation. Using Libbpf-rs will make building user
|
||||
space part of the BPF application easier. Note that the BPF program themselves
|
||||
must still be written in plain C.
|
||||
|
||||
libbpf logging
|
||||
==============
|
||||
|
||||
By default, libbpf logs informational and warning messages to stderr. The
|
||||
verbosity of these messages can be controlled by setting the environment
|
||||
variable LIBBPF_LOG_LEVEL to either warn, info, or debug. A custom log
|
||||
callback can be set using ``libbpf_set_print()``.
|
||||
|
||||
Additional Documentation
|
||||
========================
|
||||
|
||||
|
||||
@ -23,3 +23,6 @@ The BPF calling convention is defined as:
|
||||
|
||||
R0 - R5 are scratch registers and BPF programs needs to spill/fill them if
|
||||
necessary across calls.
|
||||
|
||||
The BPF program needs to store the return value into register R0 before doing an
|
||||
``EXIT``.
|
||||
|
||||
@ -5,15 +5,29 @@
|
||||
BPF Instruction Set Architecture (ISA)
|
||||
======================================
|
||||
|
||||
eBPF (which is no longer an acronym for anything), also commonly
|
||||
eBPF, also commonly
|
||||
referred to as BPF, is a technology with origins in the Linux kernel
|
||||
that can run untrusted programs in a privileged context such as an
|
||||
operating system kernel. This document specifies the BPF instruction
|
||||
set architecture (ISA).
|
||||
|
||||
As a historical note, BPF originally stood for Berkeley Packet Filter,
|
||||
but now that it can do so much more than packet filtering, the acronym
|
||||
no longer makes sense. BPF is now considered a standalone term that
|
||||
does not stand for anything. The original BPF is sometimes referred to
|
||||
as cBPF (classic BPF) to distinguish it from the now widely deployed
|
||||
eBPF (extended BPF).
|
||||
|
||||
Documentation conventions
|
||||
=========================
|
||||
|
||||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
||||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
||||
"OPTIONAL" in this document are to be interpreted as described in
|
||||
BCP 14 `<https://www.rfc-editor.org/info/rfc2119>`_
|
||||
`<https://www.rfc-editor.org/info/rfc8174>`_
|
||||
when, and only when, they appear in all capitals, as shown here.
|
||||
|
||||
For brevity and consistency, this document refers to families
|
||||
of types using a shorthand syntax and refers to several expository,
|
||||
mnemonic functions when describing the semantics of instructions.
|
||||
@ -25,7 +39,7 @@ Types
|
||||
This document refers to integer types with the notation `SN` to specify
|
||||
a type's signedness (`S`) and bit width (`N`), respectively.
|
||||
|
||||
.. table:: Meaning of signedness notation.
|
||||
.. table:: Meaning of signedness notation
|
||||
|
||||
==== =========
|
||||
S Meaning
|
||||
@ -34,7 +48,7 @@ a type's signedness (`S`) and bit width (`N`), respectively.
|
||||
s signed
|
||||
==== =========
|
||||
|
||||
.. table:: Meaning of bit-width notation.
|
||||
.. table:: Meaning of bit-width notation
|
||||
|
||||
===== =========
|
||||
N Bit width
|
||||
@ -52,24 +66,18 @@ numbers.
|
||||
|
||||
Functions
|
||||
---------
|
||||
* htobe16: Takes an unsigned 16-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 16-bit number in big-endian
|
||||
format.
|
||||
* htobe32: Takes an unsigned 32-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 32-bit number in big-endian
|
||||
format.
|
||||
* htobe64: Takes an unsigned 64-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 64-bit number in big-endian
|
||||
format.
|
||||
* htole16: Takes an unsigned 16-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 16-bit number in little-endian
|
||||
format.
|
||||
* htole32: Takes an unsigned 32-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 32-bit number in little-endian
|
||||
format.
|
||||
* htole64: Takes an unsigned 64-bit number in host-endian format and
|
||||
returns the equivalent number as an unsigned 64-bit number in little-endian
|
||||
format.
|
||||
|
||||
The following byteswap functions are direction-agnostic. That is,
|
||||
the same function is used for conversion in either direction discussed
|
||||
below.
|
||||
|
||||
* be16: Takes an unsigned 16-bit number and converts it between
|
||||
host byte order and big-endian
|
||||
(`IEN137 <https://www.rfc-editor.org/ien/ien137.txt>`_) byte order.
|
||||
* be32: Takes an unsigned 32-bit number and converts it between
|
||||
host byte order and big-endian byte order.
|
||||
* be64: Takes an unsigned 64-bit number and converts it between
|
||||
host byte order and big-endian byte order.
|
||||
* bswap16: Takes an unsigned 16-bit number in either big- or little-endian
|
||||
format and returns the equivalent number with the same bit width but
|
||||
opposite endianness.
|
||||
@ -79,7 +87,12 @@ Functions
|
||||
* bswap64: Takes an unsigned 64-bit number in either big- or little-endian
|
||||
format and returns the equivalent number with the same bit width but
|
||||
opposite endianness.
|
||||
|
||||
* le16: Takes an unsigned 16-bit number and converts it between
|
||||
host byte order and little-endian byte order.
|
||||
* le32: Takes an unsigned 32-bit number and converts it between
|
||||
host byte order and little-endian byte order.
|
||||
* le64: Takes an unsigned 64-bit number and converts it between
|
||||
host byte order and little-endian byte order.
|
||||
|
||||
Definitions
|
||||
-----------
|
||||
@ -106,9 +119,9 @@ Conformance groups
|
||||
|
||||
An implementation does not need to support all instructions specified in this
|
||||
document (e.g., deprecated instructions). Instead, a number of conformance
|
||||
groups are specified. An implementation must support the base32 conformance
|
||||
group and may support additional conformance groups, where supporting a
|
||||
conformance group means it must support all instructions in that conformance
|
||||
groups are specified. An implementation MUST support the base32 conformance
|
||||
group and MAY support additional conformance groups, where supporting a
|
||||
conformance group means it MUST support all instructions in that conformance
|
||||
group.
|
||||
|
||||
The use of named conformance groups enables interoperability between a runtime
|
||||
@ -209,7 +222,7 @@ For example::
|
||||
07 1 0 00 00 11 22 33 44 r1 += 0x11223344 // big
|
||||
|
||||
Note that most instructions do not use all of the fields.
|
||||
Unused fields shall be cleared to zero.
|
||||
Unused fields SHALL be cleared to zero.
|
||||
|
||||
Wide instruction encoding
|
||||
--------------------------
|
||||
@ -256,18 +269,20 @@ Instruction classes
|
||||
|
||||
The three least significant bits of the 'opcode' field store the instruction class:
|
||||
|
||||
===== ===== =============================== ===================================
|
||||
class value description reference
|
||||
===== ===== =============================== ===================================
|
||||
LD 0x0 non-standard load operations `Load and store instructions`_
|
||||
LDX 0x1 load into register operations `Load and store instructions`_
|
||||
ST 0x2 store from immediate operations `Load and store instructions`_
|
||||
STX 0x3 store from register operations `Load and store instructions`_
|
||||
ALU 0x4 32-bit arithmetic operations `Arithmetic and jump instructions`_
|
||||
JMP 0x5 64-bit jump operations `Arithmetic and jump instructions`_
|
||||
JMP32 0x6 32-bit jump operations `Arithmetic and jump instructions`_
|
||||
ALU64 0x7 64-bit arithmetic operations `Arithmetic and jump instructions`_
|
||||
===== ===== =============================== ===================================
|
||||
.. table:: Instruction class
|
||||
|
||||
===== ===== =============================== ===================================
|
||||
class value description reference
|
||||
===== ===== =============================== ===================================
|
||||
LD 0x0 non-standard load operations `Load and store instructions`_
|
||||
LDX 0x1 load into register operations `Load and store instructions`_
|
||||
ST 0x2 store from immediate operations `Load and store instructions`_
|
||||
STX 0x3 store from register operations `Load and store instructions`_
|
||||
ALU 0x4 32-bit arithmetic operations `Arithmetic and jump instructions`_
|
||||
JMP 0x5 64-bit jump operations `Arithmetic and jump instructions`_
|
||||
JMP32 0x6 32-bit jump operations `Arithmetic and jump instructions`_
|
||||
ALU64 0x7 64-bit arithmetic operations `Arithmetic and jump instructions`_
|
||||
===== ===== =============================== ===================================
|
||||
|
||||
Arithmetic and jump instructions
|
||||
================================
|
||||
@ -285,12 +300,14 @@ For arithmetic and jump instructions (``ALU``, ``ALU64``, ``JMP`` and
|
||||
**s (source)**
|
||||
the source operand location, which unless otherwise specified is one of:
|
||||
|
||||
====== ===== ==============================================
|
||||
source value description
|
||||
====== ===== ==============================================
|
||||
K 0 use 32-bit 'imm' value as source operand
|
||||
X 1 use 'src_reg' register value as source operand
|
||||
====== ===== ==============================================
|
||||
.. table:: Source operand location
|
||||
|
||||
====== ===== ==============================================
|
||||
source value description
|
||||
====== ===== ==============================================
|
||||
K 0 use 32-bit 'imm' value as source operand
|
||||
X 1 use 'src_reg' register value as source operand
|
||||
====== ===== ==============================================
|
||||
|
||||
**instruction class**
|
||||
the instruction class (see `Instruction classes`_)
|
||||
@ -305,27 +322,29 @@ The 'code' field encodes the operation as below, where 'src' refers to the
|
||||
the source operand and 'dst' refers to the value of the destination
|
||||
register.
|
||||
|
||||
===== ===== ======= ==========================================================
|
||||
name code offset description
|
||||
===== ===== ======= ==========================================================
|
||||
ADD 0x0 0 dst += src
|
||||
SUB 0x1 0 dst -= src
|
||||
MUL 0x2 0 dst \*= src
|
||||
DIV 0x3 0 dst = (src != 0) ? (dst / src) : 0
|
||||
SDIV 0x3 1 dst = (src != 0) ? (dst s/ src) : 0
|
||||
OR 0x4 0 dst \|= src
|
||||
AND 0x5 0 dst &= src
|
||||
LSH 0x6 0 dst <<= (src & mask)
|
||||
RSH 0x7 0 dst >>= (src & mask)
|
||||
NEG 0x8 0 dst = -dst
|
||||
MOD 0x9 0 dst = (src != 0) ? (dst % src) : dst
|
||||
SMOD 0x9 1 dst = (src != 0) ? (dst s% src) : dst
|
||||
XOR 0xa 0 dst ^= src
|
||||
MOV 0xb 0 dst = src
|
||||
MOVSX 0xb 8/16/32 dst = (s8,s16,s32)src
|
||||
ARSH 0xc 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask)
|
||||
END 0xd 0 byte swap operations (see `Byte swap instructions`_ below)
|
||||
===== ===== ======= ==========================================================
|
||||
.. table:: Arithmetic instructions
|
||||
|
||||
===== ===== ======= ==========================================================
|
||||
name code offset description
|
||||
===== ===== ======= ==========================================================
|
||||
ADD 0x0 0 dst += src
|
||||
SUB 0x1 0 dst -= src
|
||||
MUL 0x2 0 dst \*= src
|
||||
DIV 0x3 0 dst = (src != 0) ? (dst / src) : 0
|
||||
SDIV 0x3 1 dst = (src != 0) ? (dst s/ src) : 0
|
||||
OR 0x4 0 dst \|= src
|
||||
AND 0x5 0 dst &= src
|
||||
LSH 0x6 0 dst <<= (src & mask)
|
||||
RSH 0x7 0 dst >>= (src & mask)
|
||||
NEG 0x8 0 dst = -dst
|
||||
MOD 0x9 0 dst = (src != 0) ? (dst % src) : dst
|
||||
SMOD 0x9 1 dst = (src != 0) ? (dst s% src) : dst
|
||||
XOR 0xa 0 dst ^= src
|
||||
MOV 0xb 0 dst = src
|
||||
MOVSX 0xb 8/16/32 dst = (s8,s16,s32)src
|
||||
ARSH 0xc 0 :term:`sign extending<Sign Extend>` dst >>= (src & mask)
|
||||
END 0xd 0 byte swap operations (see `Byte swap instructions`_ below)
|
||||
===== ===== ======= ==========================================================
|
||||
|
||||
Underflow and overflow are allowed during arithmetic operations, meaning
|
||||
the 64-bit or 32-bit value will wrap. If BPF program execution would
|
||||
@ -374,7 +393,7 @@ interpreted as a 64-bit signed value.
|
||||
Note that there are varying definitions of the signed modulo operation
|
||||
when the dividend or divisor are negative, where implementations often
|
||||
vary by language such that Python, Ruby, etc. differ from C, Go, Java,
|
||||
etc. This specification requires that signed modulo use truncated division
|
||||
etc. This specification requires that signed modulo MUST use truncated division
|
||||
(where -13 % 3 == -1) as implemented in C, Go, etc.::
|
||||
|
||||
a % n = a - n * trunc(a / n)
|
||||
@ -386,6 +405,19 @@ The ``MOVSX`` instruction does a move operation with sign extension.
|
||||
operands into 64-bit operands. Unlike other arithmetic instructions,
|
||||
``MOVSX`` is only defined for register source operands (``X``).
|
||||
|
||||
``{MOV, K, ALU64}`` means::
|
||||
|
||||
dst = (s64)imm
|
||||
|
||||
``{MOV, X, ALU}`` means::
|
||||
|
||||
dst = (u32)src
|
||||
|
||||
``{MOVSX, X, ALU}`` with 'offset' 8 means::
|
||||
|
||||
dst = (u32)(s32)(s8)src
|
||||
|
||||
|
||||
The ``NEG`` instruction is only defined when the source bit is clear
|
||||
(``K``).
|
||||
|
||||
@ -404,15 +436,17 @@ only and do not use a separate source register or immediate value.
|
||||
For ``ALU``, the 1-bit source operand field in the opcode is used to
|
||||
select what byte order the operation converts from or to. For
|
||||
``ALU64``, the 1-bit source operand field in the opcode is reserved
|
||||
and must be set to 0.
|
||||
and MUST be set to 0.
|
||||
|
||||
===== ======== ===== =================================================
|
||||
class source value description
|
||||
===== ======== ===== =================================================
|
||||
ALU TO_LE 0 convert between host byte order and little endian
|
||||
ALU TO_BE 1 convert between host byte order and big endian
|
||||
ALU64 Reserved 0 do byte swap unconditionally
|
||||
===== ======== ===== =================================================
|
||||
.. table:: Byte swap instructions
|
||||
|
||||
===== ======== ===== =================================================
|
||||
class source value description
|
||||
===== ======== ===== =================================================
|
||||
ALU LE 0 convert between host byte order and little endian
|
||||
ALU BE 1 convert between host byte order and big endian
|
||||
ALU64 Reserved 0 do byte swap unconditionally
|
||||
===== ======== ===== =================================================
|
||||
|
||||
The 'imm' field encodes the width of the swap operations. The following widths
|
||||
are supported: 16, 32 and 64. Width 64 operations belong to the base64
|
||||
@ -421,19 +455,19 @@ conformance group.
|
||||
|
||||
Examples:
|
||||
|
||||
``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means::
|
||||
``{END, LE, ALU}`` with 'imm' = 16/32/64 means::
|
||||
|
||||
dst = htole16(dst)
|
||||
dst = htole32(dst)
|
||||
dst = htole64(dst)
|
||||
dst = le16(dst)
|
||||
dst = le32(dst)
|
||||
dst = le64(dst)
|
||||
|
||||
``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means::
|
||||
``{END, BE, ALU}`` with 'imm' = 16/32/64 means::
|
||||
|
||||
dst = htobe16(dst)
|
||||
dst = htobe32(dst)
|
||||
dst = htobe64(dst)
|
||||
dst = be16(dst)
|
||||
dst = be32(dst)
|
||||
dst = be64(dst)
|
||||
|
||||
``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means::
|
||||
``{END, TO, ALU64}`` with 'imm' = 16/32/64 means::
|
||||
|
||||
dst = bswap16(dst)
|
||||
dst = bswap32(dst)
|
||||
@ -448,27 +482,29 @@ otherwise identical operations, and indicates the base64 conformance
|
||||
group unless otherwise specified.
|
||||
The 'code' field encodes the operation as below:
|
||||
|
||||
======== ===== ======= ================================= ===================================================
|
||||
code value src_reg description notes
|
||||
======== ===== ======= ================================= ===================================================
|
||||
JA 0x0 0x0 PC += offset {JA, K, JMP} only
|
||||
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
|
||||
JEQ 0x1 any PC += offset if dst == src
|
||||
JGT 0x2 any PC += offset if dst > src unsigned
|
||||
JGE 0x3 any PC += offset if dst >= src unsigned
|
||||
JSET 0x4 any PC += offset if dst & src
|
||||
JNE 0x5 any PC += offset if dst != src
|
||||
JSGT 0x6 any PC += offset if dst > src signed
|
||||
JSGE 0x7 any PC += offset if dst >= src signed
|
||||
CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_
|
||||
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
|
||||
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
|
||||
EXIT 0x9 0x0 return {CALL, K, JMP} only
|
||||
JLT 0xa any PC += offset if dst < src unsigned
|
||||
JLE 0xb any PC += offset if dst <= src unsigned
|
||||
JSLT 0xc any PC += offset if dst < src signed
|
||||
JSLE 0xd any PC += offset if dst <= src signed
|
||||
======== ===== ======= ================================= ===================================================
|
||||
.. table:: Jump instructions
|
||||
|
||||
======== ===== ======= ================================= ===================================================
|
||||
code value src_reg description notes
|
||||
======== ===== ======= ================================= ===================================================
|
||||
JA 0x0 0x0 PC += offset {JA, K, JMP} only
|
||||
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
|
||||
JEQ 0x1 any PC += offset if dst == src
|
||||
JGT 0x2 any PC += offset if dst > src unsigned
|
||||
JGE 0x3 any PC += offset if dst >= src unsigned
|
||||
JSET 0x4 any PC += offset if dst & src
|
||||
JNE 0x5 any PC += offset if dst != src
|
||||
JSGT 0x6 any PC += offset if dst > src signed
|
||||
JSGE 0x7 any PC += offset if dst >= src signed
|
||||
CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_
|
||||
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
|
||||
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
|
||||
EXIT 0x9 0x0 return {CALL, K, JMP} only
|
||||
JLT 0xa any PC += offset if dst < src unsigned
|
||||
JLE 0xb any PC += offset if dst <= src unsigned
|
||||
JSLT 0xc any PC += offset if dst < src signed
|
||||
JSLE 0xd any PC += offset if dst <= src signed
|
||||
======== ===== ======= ================================= ===================================================
|
||||
|
||||
where 'PC' denotes the program counter, and the offset to increment by
|
||||
is in units of 64-bit instructions relative to the instruction following
|
||||
@ -476,9 +512,6 @@ the jump instruction. Thus 'PC += 1' skips execution of the next
|
||||
instruction if it's a basic instruction or results in undefined behavior
|
||||
if the next instruction is a 128-bit wide instruction.
|
||||
|
||||
The BPF program needs to store the return value into register R0 before doing an
|
||||
``EXIT``.
|
||||
|
||||
Example:
|
||||
|
||||
``{JSGE, X, JMP32}`` means::
|
||||
@ -487,6 +520,10 @@ Example:
|
||||
|
||||
where 's>=' indicates a signed '>=' comparison.
|
||||
|
||||
``{JLE, K, JMP}`` means::
|
||||
|
||||
if dst <= (u64)(s64)imm goto +offset
|
||||
|
||||
``{JA, K, JMP32}`` means::
|
||||
|
||||
gotol +imm
|
||||
@ -510,19 +547,25 @@ Helper functions are a concept whereby BPF programs can call into a
|
||||
set of function calls exposed by the underlying platform.
|
||||
|
||||
Historically, each helper function was identified by a static ID
|
||||
encoded in the 'imm' field. The available helper functions may differ
|
||||
for each program type, but static IDs are unique across all program types.
|
||||
encoded in the 'imm' field. Further documentation of helper functions
|
||||
is outside the scope of this document and standardization is left for
|
||||
future work, but use is widely deployed and more information can be
|
||||
found in platform-specific documentation (e.g., Linux kernel documentation).
|
||||
|
||||
Platforms that support the BPF Type Format (BTF) support identifying
|
||||
a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID
|
||||
identifies the helper name and type.
|
||||
identifies the helper name and type. Further documentation of BTF
|
||||
is outside the scope of this document and standardization is left for
|
||||
future work, but use is widely deployed and more information can be
|
||||
found in platform-specific documentation (e.g., Linux kernel documentation).
|
||||
|
||||
Program-local functions
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Program-local functions are functions exposed by the same BPF program as the
|
||||
caller, and are referenced by offset from the call instruction, similar to
|
||||
``JA``. The offset is encoded in the 'imm' field of the call instruction.
|
||||
An ``EXIT`` within the program-local function will return to the caller.
|
||||
caller, and are referenced by offset from the instruction following the call
|
||||
instruction, similar to ``JA``. The offset is encoded in the 'imm' field of
|
||||
the call instruction. An ``EXIT`` within the program-local function will
|
||||
return to the caller.
|
||||
|
||||
Load and store instructions
|
||||
===========================
|
||||
@ -537,6 +580,8 @@ For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
|
||||
**mode**
|
||||
The mode modifier is one of:
|
||||
|
||||
.. table:: Mode modifier
|
||||
|
||||
============= ===== ==================================== =============
|
||||
mode modifier value description reference
|
||||
============= ===== ==================================== =============
|
||||
@ -551,6 +596,8 @@ For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
|
||||
**sz (size)**
|
||||
The size modifier is one of:
|
||||
|
||||
.. table:: Size modifier
|
||||
|
||||
==== ===== =====================
|
||||
size value description
|
||||
==== ===== =====================
|
||||
@ -619,14 +666,16 @@ The 'imm' field is used to encode the actual atomic operation.
|
||||
Simple atomic operation use a subset of the values defined to encode
|
||||
arithmetic operations in the 'imm' field to encode the atomic operation:
|
||||
|
||||
======== ===== ===========
|
||||
imm value description
|
||||
======== ===== ===========
|
||||
ADD 0x00 atomic add
|
||||
OR 0x40 atomic or
|
||||
AND 0x50 atomic and
|
||||
XOR 0xa0 atomic xor
|
||||
======== ===== ===========
|
||||
.. table:: Simple atomic operations
|
||||
|
||||
======== ===== ===========
|
||||
imm value description
|
||||
======== ===== ===========
|
||||
ADD 0x00 atomic add
|
||||
OR 0x40 atomic or
|
||||
AND 0x50 atomic and
|
||||
XOR 0xa0 atomic xor
|
||||
======== ===== ===========
|
||||
|
||||
|
||||
``{ATOMIC, W, STX}`` with 'imm' = ADD means::
|
||||
@ -640,13 +689,15 @@ XOR 0xa0 atomic xor
|
||||
In addition to the simple atomic operations, there also is a modifier and
|
||||
two complex atomic operations:
|
||||
|
||||
=========== ================ ===========================
|
||||
imm value description
|
||||
=========== ================ ===========================
|
||||
FETCH 0x01 modifier: return old value
|
||||
XCHG 0xe0 | FETCH atomic exchange
|
||||
CMPXCHG 0xf0 | FETCH atomic compare and exchange
|
||||
=========== ================ ===========================
|
||||
.. table:: Complex atomic operations
|
||||
|
||||
=========== ================ ===========================
|
||||
imm value description
|
||||
=========== ================ ===========================
|
||||
FETCH 0x01 modifier: return old value
|
||||
XCHG 0xe0 | FETCH atomic exchange
|
||||
CMPXCHG 0xf0 | FETCH atomic compare and exchange
|
||||
=========== ================ ===========================
|
||||
|
||||
The ``FETCH`` modifier is optional for simple atomic operations, and
|
||||
always set for the complex atomic operations. If the ``FETCH`` flag
|
||||
@ -673,17 +724,19 @@ The following table defines a set of ``{IMM, DW, LD}`` instructions
|
||||
with opcode subtypes in the 'src_reg' field, using new terms such as "map"
|
||||
defined further below:
|
||||
|
||||
======= ========================================= =========== ==============
|
||||
src_reg pseudocode imm type dst type
|
||||
======= ========================================= =========== ==============
|
||||
0x0 dst = (next_imm << 32) | imm integer integer
|
||||
0x1 dst = map_by_fd(imm) map fd map
|
||||
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address
|
||||
0x3 dst = var_addr(imm) variable id data address
|
||||
0x4 dst = code_addr(imm) integer code address
|
||||
0x5 dst = map_by_idx(imm) map index map
|
||||
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address
|
||||
======= ========================================= =========== ==============
|
||||
.. table:: 64-bit immediate instructions
|
||||
|
||||
======= ========================================= =========== ==============
|
||||
src_reg pseudocode imm type dst type
|
||||
======= ========================================= =========== ==============
|
||||
0x0 dst = (next_imm << 32) | imm integer integer
|
||||
0x1 dst = map_by_fd(imm) map fd map
|
||||
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address
|
||||
0x3 dst = var_addr(imm) variable id data address
|
||||
0x4 dst = code_addr(imm) integer code address
|
||||
0x5 dst = map_by_idx(imm) map index map
|
||||
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address
|
||||
======= ========================================= =========== ==============
|
||||
|
||||
where
|
||||
|
||||
@ -725,5 +778,5 @@ carried over from classic BPF. These instructions used an instruction
|
||||
class of ``LD``, a size modifier of ``W``, ``H``, or ``B``, and a
|
||||
mode modifier of ``ABS`` or ``IND``. The 'dst_reg' and 'offset' fields were
|
||||
set to zero, and 'src_reg' was set to zero for ``ABS``. However, these
|
||||
instructions are deprecated and should no longer be used. All legacy packet
|
||||
instructions are deprecated and SHOULD no longer be used. All legacy packet
|
||||
access instructions belong to the "packet" conformance group.
|
||||
|
||||
@ -210,7 +210,7 @@ implemented (simplified excerpt)::
|
||||
}
|
||||
}
|
||||
|
||||
noop(struct irq_data *data))
|
||||
noop(struct irq_data *data)
|
||||
{
|
||||
}
|
||||
|
||||
@ -410,6 +410,8 @@ which are used in the generic IRQ layer.
|
||||
.. kernel-doc:: include/linux/interrupt.h
|
||||
:internal:
|
||||
|
||||
.. kernel-doc:: include/linux/irqdomain.h
|
||||
|
||||
Public Functions Provided
|
||||
=========================
|
||||
|
||||
|
||||
@ -144,8 +144,10 @@ configuration, but it is a good practice to use `kmalloc` for objects
|
||||
smaller than page size.
|
||||
|
||||
The address of a chunk allocated with `kmalloc` is aligned to at least
|
||||
ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
|
||||
alignment is also guaranteed to be at least the respective size.
|
||||
ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the
|
||||
alignment is also guaranteed to be at least the respective size. For other
|
||||
sizes, the alignment is guaranteed to be at least the largest power-of-two
|
||||
divisor of the size.
|
||||
|
||||
Chunks allocated with kmalloc() can be resized with krealloc(). Similarly
|
||||
to kmalloc_array(): a helper for resizing arrays is provided in the form of
|
||||
|
||||
@ -132,7 +132,7 @@ CASE 1: Direct IO (DIO)
|
||||
-----------------------
|
||||
There are GUP references to pages that are serving
|
||||
as DIO buffers. These buffers are needed for a relatively short time (so they
|
||||
are not "long term"). No special synchronization with page_mkclean() or
|
||||
are not "long term"). No special synchronization with folio_mkclean() or
|
||||
munmap() is provided. Therefore, flags to set at the call site are: ::
|
||||
|
||||
FOLL_PIN
|
||||
@ -144,7 +144,7 @@ CASE 2: RDMA
|
||||
------------
|
||||
There are GUP references to pages that are serving as DMA
|
||||
buffers. These buffers are needed for a long time ("long term"). No special
|
||||
synchronization with page_mkclean() or munmap() is provided. Therefore, flags
|
||||
synchronization with folio_mkclean() or munmap() is provided. Therefore, flags
|
||||
to set at the call site are: ::
|
||||
|
||||
FOLL_PIN | FOLL_LONGTERM
|
||||
@ -170,7 +170,7 @@ callback, simply remove the range from the device's page tables.
|
||||
|
||||
Either way, as long as the driver unpins the pages upon mmu notifier callback,
|
||||
then there is proper synchronization with both filesystem and mm
|
||||
(page_mkclean(), munmap(), etc). Therefore, neither flag needs to be set.
|
||||
(folio_mkclean(), munmap(), etc). Therefore, neither flag needs to be set.
|
||||
|
||||
CASE 4: Pinning for struct page manipulation only
|
||||
-------------------------------------------------
|
||||
@ -196,20 +196,20 @@ INCORRECT (uses FOLL_GET calls):
|
||||
write to the data within the pages
|
||||
put_page()
|
||||
|
||||
page_maybe_dma_pinned(): the whole point of pinning
|
||||
===================================================
|
||||
folio_maybe_dma_pinned(): the whole point of pinning
|
||||
====================================================
|
||||
|
||||
The whole point of marking pages as "DMA-pinned" or "gup-pinned" is to be able
|
||||
to query, "is this page DMA-pinned?" That allows code such as page_mkclean()
|
||||
The whole point of marking folios as "DMA-pinned" or "gup-pinned" is to be able
|
||||
to query, "is this folio DMA-pinned?" That allows code such as folio_mkclean()
|
||||
(and file system writeback code in general) to make informed decisions about
|
||||
what to do when a page cannot be unmapped due to such pins.
|
||||
what to do when a folio cannot be unmapped due to such pins.
|
||||
|
||||
What to do in those cases is the subject of a years-long series of discussions
|
||||
and debates (see the References at the end of this document). It's a TODO item
|
||||
here: fill in the details once that's worked out. Meanwhile, it's safe to say
|
||||
that having this available: ::
|
||||
|
||||
static inline bool page_maybe_dma_pinned(struct page *page)
|
||||
static inline bool folio_maybe_dma_pinned(struct folio *folio)
|
||||
|
||||
...is a prerequisite to solving the long-running gup+DMA problem.
|
||||
|
||||
|
||||
@ -150,38 +150,38 @@ of an operation.
|
||||
Perform a xor->copy->xor operation where each operation depends on the
|
||||
result from the previous operation::
|
||||
|
||||
void callback(void *param)
|
||||
{
|
||||
struct completion *cmp = param;
|
||||
#include <linux/async_tx.h>
|
||||
|
||||
complete(cmp);
|
||||
static void callback(void *param)
|
||||
{
|
||||
complete(param);
|
||||
}
|
||||
|
||||
void run_xor_copy_xor(struct page **xor_srcs,
|
||||
int xor_src_cnt,
|
||||
struct page *xor_dest,
|
||||
size_t xor_len,
|
||||
struct page *copy_src,
|
||||
struct page *copy_dest,
|
||||
size_t copy_len)
|
||||
#define NDISKS 2
|
||||
|
||||
static void run_xor_copy_xor(struct page **xor_srcs,
|
||||
struct page *xor_dest,
|
||||
size_t xor_len,
|
||||
struct page *copy_src,
|
||||
struct page *copy_dest,
|
||||
size_t copy_len)
|
||||
{
|
||||
struct dma_async_tx_descriptor *tx;
|
||||
addr_conv_t addr_conv[xor_src_cnt];
|
||||
struct async_submit_ctl submit;
|
||||
addr_conv_t addr_conv[NDISKS];
|
||||
struct completion cmp;
|
||||
|
||||
init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST, NULL, NULL, NULL,
|
||||
addr_conv);
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit)
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, NDISKS, xor_len, &submit);
|
||||
|
||||
submit->depend_tx = tx;
|
||||
submit.depend_tx = tx;
|
||||
tx = async_memcpy(copy_dest, copy_src, 0, 0, copy_len, &submit);
|
||||
|
||||
init_completion(&cmp);
|
||||
init_async_submit(&submit, ASYNC_TX_XOR_DROP_DST | ASYNC_TX_ACK, tx,
|
||||
callback, &cmp, addr_conv);
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, xor_src_cnt, xor_len, &submit);
|
||||
tx = async_xor(xor_dest, xor_srcs, 0, NDISKS, xor_len, &submit);
|
||||
|
||||
async_tx_issue_pending_all();
|
||||
|
||||
|
||||
93
Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst
Normal file
93
Documentation/dev-tools/gpio-sloppy-logic-analyzer.rst
Normal file
@ -0,0 +1,93 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=============================================
|
||||
Linux Kernel GPIO based sloppy logic analyzer
|
||||
=============================================
|
||||
|
||||
:Author: Wolfram Sang
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
This document briefly describes how to run the GPIO based in-kernel sloppy
|
||||
logic analyzer running on an isolated CPU.
|
||||
|
||||
The sloppy logic analyzer will utilize a few GPIO lines in input mode on a
|
||||
system to rapidly sample these digital lines, which will, if the Nyquist
|
||||
criteria is met, result in a time series log with approximate waveforms as they
|
||||
appeared on these lines. One way to use it is to analyze external traffic
|
||||
connected to these GPIO lines with wires (i.e. digital probes), acting as a
|
||||
common logic analyzer.
|
||||
|
||||
Another feature is to snoop on on-chip peripherals if the I/O cells of these
|
||||
peripherals can be used in GPIO input mode at the same time as they are being
|
||||
used as inputs or outputs for the peripheral. That means you could e.g. snoop
|
||||
I2C traffic without any wiring (if your hardware supports it). In the pin
|
||||
control subsystem such pin controllers are called "non-strict": a certain pin
|
||||
can be used with a certain peripheral and as a GPIO input line at the same
|
||||
time.
|
||||
|
||||
Note that this is a last resort analyzer which can be affected by latencies,
|
||||
non-deterministic code paths and non-maskable interrupts. It is called 'sloppy'
|
||||
for a reason. However, for e.g. remote development, it may be useful to get a
|
||||
first view and aid further debugging.
|
||||
|
||||
Setup
|
||||
=====
|
||||
|
||||
Your kernel must have CONFIG_DEBUG_FS and CONFIG_CPUSETS enabled. Ideally, your
|
||||
runtime environment does not utilize cpusets otherwise, then isolation of a CPU
|
||||
core is easiest. If you do need cpusets, check that helper script for the
|
||||
sloppy logic analyzer does not interfere with your other settings.
|
||||
|
||||
Tell the kernel which GPIOs are used as probes. For a Device Tree based system,
|
||||
you need to use the following bindings. Because these bindings are only for
|
||||
debugging, there is no official schema::
|
||||
|
||||
i2c-analyzer {
|
||||
compatible = "gpio-sloppy-logic-analyzer";
|
||||
probe-gpios = <&gpio6 21 GPIO_OPEN_DRAIN>, <&gpio6 4 GPIO_OPEN_DRAIN>;
|
||||
probe-names = "SCL", "SDA";
|
||||
};
|
||||
|
||||
Note that you must provide a name for every GPIO specified. Currently a
|
||||
maximum of 8 probes are supported. 32 are likely possible but are not
|
||||
implemented yet.
|
||||
|
||||
Usage
|
||||
=====
|
||||
|
||||
The logic analyzer is configurable via files in debugfs. However, it is
|
||||
strongly recommended to not use them directly, but to use the script
|
||||
``tools/gpio/gpio-sloppy-logic-analyzer``. Besides checking parameters more
|
||||
extensively, it will isolate the CPU core so you will have the least
|
||||
disturbance while measuring.
|
||||
|
||||
The script has a help option explaining the parameters. For the above DT
|
||||
snippet which analyzes an I2C bus at 400kHz on a Renesas Salvator-XS board, the
|
||||
following settings are used: The isolated CPU shall be CPU1 because it is a big
|
||||
core in a big.LITTLE setup. Because CPU1 is the default, we don't need a
|
||||
parameter. The bus speed is 400kHz. So, the sampling theorem says we need to
|
||||
sample at least at 800kHz. However, falling edges of both signals in an I2C
|
||||
start condition happen faster, so we need a higher sampling frequency, e.g.
|
||||
``-s 1500000`` for 1.5MHz. Also, we don't want to sample right away but wait
|
||||
for a start condition on an idle bus. So, we need to set a trigger to a falling
|
||||
edge on SDA while SCL stays high, i.e. ``-t 1H+2F``. Last is the duration, let
|
||||
us assume 15ms here which results in the parameter ``-d 15000``. So,
|
||||
altogether::
|
||||
|
||||
gpio-sloppy-logic-analyzer -s 1500000 -t 1H+2F -d 15000
|
||||
|
||||
Note that the process will return you back to the prompt but a sub-process is
|
||||
still sampling in the background. Unless this has finished, you will not find a
|
||||
result file in the current or specified directory. For the above example, we
|
||||
will then need to trigger I2C communication::
|
||||
|
||||
i2cdetect -y -r <your bus number>
|
||||
|
||||
Result is a .sr file to be consumed with PulseView or sigrok-cli from the free
|
||||
`sigrok`_ project. It is a zip file which also contains the binary sample data
|
||||
which may be consumed by other software. The filename is the logic analyzer
|
||||
instance name plus a since-epoch timestamp.
|
||||
|
||||
.. _sigrok: https://sigrok.org/
|
||||
@ -16,6 +16,7 @@ Documentation/dev-tools/testing-overview.rst
|
||||
|
||||
testing-overview
|
||||
checkpatch
|
||||
clang-format
|
||||
coccinelle
|
||||
sparse
|
||||
kcov
|
||||
@ -32,6 +33,7 @@ Documentation/dev-tools/testing-overview.rst
|
||||
kunit/index
|
||||
ktap
|
||||
checkuapi
|
||||
gpio-sloppy-logic-analyzer
|
||||
|
||||
|
||||
.. only:: subproject and html
|
||||
|
||||
@ -110,6 +110,13 @@ in the Makefile. Think of this as applying ``__no_sanitize_memory`` to every
|
||||
function in the file or directory. Most users won't need KMSAN_SANITIZE, unless
|
||||
their code gets broken by KMSAN (e.g. runs at early boot time).
|
||||
|
||||
KMSAN checks can also be temporarily disabled for the current task using
|
||||
``kmsan_disable_current()`` and ``kmsan_enable_current()`` calls. Each
|
||||
``kmsan_enable_current()`` call must be preceded by a
|
||||
``kmsan_disable_current()`` call; these call pairs may be nested. One needs to
|
||||
be careful with these calls, keeping the regions short and preferring other
|
||||
ways to disable instrumentation, where possible.
|
||||
|
||||
Support
|
||||
=======
|
||||
|
||||
@ -338,11 +345,11 @@ Per-task KMSAN state
|
||||
~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Every task_struct has an associated KMSAN task state that holds the KMSAN
|
||||
context (see above) and a per-task flag disallowing KMSAN reports::
|
||||
context (see above) and a per-task counter disallowing KMSAN reports::
|
||||
|
||||
struct kmsan_context {
|
||||
...
|
||||
bool allow_reporting;
|
||||
unsigned int depth;
|
||||
struct kmsan_context_state cstate;
|
||||
...
|
||||
}
|
||||
|
||||
@ -228,6 +228,13 @@ In general, the rules for selftests are
|
||||
* Don't cause the top-level "make run_tests" to fail if your feature is
|
||||
unconfigured.
|
||||
|
||||
* The output of tests must conform to the TAP standard to ensure high
|
||||
testing quality and to capture failures/errors with specific details.
|
||||
The kselftest.h and kselftest_harness.h headers provide wrappers for
|
||||
outputting test results. These wrappers should be used for pass,
|
||||
fail, exit, and skip messages. CI systems can easily parse TAP output
|
||||
messages to detect test results.
|
||||
|
||||
Contributing new tests (details)
|
||||
================================
|
||||
|
||||
|
||||
@ -22,6 +22,10 @@ properties:
|
||||
- enum:
|
||||
- airoha,en7523-evb
|
||||
- const: airoha,en7523
|
||||
- items:
|
||||
- enum:
|
||||
- airoha,en7581-evb
|
||||
- const: airoha,en7581
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
|
||||
@ -91,6 +91,7 @@ properties:
|
||||
- libretech,aml-s905x-cc
|
||||
- libretech,aml-s905x-cc-v2
|
||||
- nexbox,a95x
|
||||
- osmc,vero4k
|
||||
- const: amlogic,s905x
|
||||
- const: amlogic,meson-gxl
|
||||
|
||||
@ -107,6 +108,13 @@ properties:
|
||||
- const: amlogic,s905d
|
||||
- const: amlogic,meson-gxl
|
||||
|
||||
- description: Boards with the Amlogic Meson GXLX S905L SoC
|
||||
items:
|
||||
- enum:
|
||||
- amlogic,p271
|
||||
- const: amlogic,s905l
|
||||
- const: amlogic,meson-gxlx
|
||||
|
||||
- description: Boards with the Amlogic Meson GXM S912 SoC
|
||||
items:
|
||||
- enum:
|
||||
@ -169,6 +177,8 @@ properties:
|
||||
- azw,gtking
|
||||
- azw,gtking-pro
|
||||
- bananapi,bpi-m2s
|
||||
- dream,dreambox-one
|
||||
- dream,dreambox-two
|
||||
- hardkernel,odroid-go-ultra
|
||||
- hardkernel,odroid-n2
|
||||
- hardkernel,odroid-n2l
|
||||
|
||||
@ -1,20 +0,0 @@
|
||||
Amlogic Meson8 and Meson8b "analog top" registers:
|
||||
--------------------------------------------------
|
||||
|
||||
The analog top registers contain information about the so-called
|
||||
"metal revision" (which encodes the "minor version") of the SoC.
|
||||
|
||||
Required properties:
|
||||
- reg: the register range of the analog top registers
|
||||
- compatible: depending on the SoC this should be one of:
|
||||
- "amlogic,meson8-analog-top"
|
||||
- "amlogic,meson8b-analog-top"
|
||||
along with "syscon"
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
analog_top: analog-top@81a8 {
|
||||
compatible = "amlogic,meson8-analog-top", "syscon";
|
||||
reg = <0x81a8 0x14>;
|
||||
};
|
||||
@ -1,17 +0,0 @@
|
||||
Amlogic Meson6/Meson8/Meson8b assist registers:
|
||||
-----------------------------------------------
|
||||
|
||||
The assist registers contain basic information about the SoC,
|
||||
for example the encoded SoC part number.
|
||||
|
||||
Required properties:
|
||||
- reg: the register range of the assist registers
|
||||
- compatible: should be "amlogic,meson-mx-assist" along with "syscon"
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
assist: assist@7c00 {
|
||||
compatible = "amlogic,meson-mx-assist", "syscon";
|
||||
reg = <0x7c00 0x200>;
|
||||
};
|
||||
@ -1,17 +0,0 @@
|
||||
Amlogic Meson6/Meson8/Meson8b bootrom:
|
||||
--------------------------------------
|
||||
|
||||
The bootrom register area can be used to access SoC specific
|
||||
information, such as the "misc version".
|
||||
|
||||
Required properties:
|
||||
- reg: the register range of the bootrom registers
|
||||
- compatible: should be "amlogic,meson-mx-bootrom" along with "syscon"
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
bootrom: bootrom@d9040000 {
|
||||
compatible = "amlogic,meson-mx-bootrom", "syscon";
|
||||
reg = <0xd9040000 0x10000>;
|
||||
};
|
||||
@ -1,18 +0,0 @@
|
||||
Amlogic Meson8 and Meson8b power-management-unit:
|
||||
-------------------------------------------------
|
||||
|
||||
The pmu is used to turn off and on different power domains of the SoCs
|
||||
This includes the power to the CPU cores.
|
||||
|
||||
Required node properties:
|
||||
- compatible value : depending on the SoC this should be one of:
|
||||
"amlogic,meson8-pmu"
|
||||
"amlogic,meson8b-pmu"
|
||||
- reg : physical base address and the size of the registers window
|
||||
|
||||
Example:
|
||||
|
||||
pmu@c81000e4 {
|
||||
compatible = "amlogic,meson8b-pmu", "syscon";
|
||||
reg = <0xc81000e0 0x18>;
|
||||
};
|
||||
@ -30,7 +30,7 @@ description: |
|
||||
maintainers:
|
||||
- Mike Leach <mike.leach@linaro.org>
|
||||
- Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
- James Clark <james.clark@arm.com>
|
||||
- James Clark <james.clark@linaro.org>
|
||||
- Mao Jinlong <quic_jinlmao@quicinc.com>
|
||||
- Hao Zhang <quic_hazha@quicinc.com>
|
||||
|
||||
|
||||
@ -29,7 +29,7 @@ description: |
|
||||
maintainers:
|
||||
- Mike Leach <mike.leach@linaro.org>
|
||||
- Suzuki K Poulose <suzuki.poulose@arm.com>
|
||||
- James Clark <james.clark@arm.com>
|
||||
- James Clark <james.clark@linaro.org>
|
||||
- Mao Jinlong <quic_jinlmao@quicinc.com>
|
||||
- Hao Zhang <quic_hazha@quicinc.com>
|
||||
|
||||
|
||||
@ -0,0 +1,61 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/arm,juno-fpga-apb-regs.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM Juno FPGA APB Registers
|
||||
|
||||
maintainers:
|
||||
- Sudeep Holla <sudeep.holla@arm.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: arm,juno-fpga-apb-regs
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
ranges: true
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 1
|
||||
|
||||
patternProperties:
|
||||
"^led@[0-9a-f]+,[0-9a-f]$":
|
||||
$ref: /schemas/leds/register-bit-led.yaml#
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- ranges
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
syscon@10000 {
|
||||
compatible = "arm,juno-fpga-apb-regs", "syscon", "simple-mfd";
|
||||
reg = <0x010000 0x1000>;
|
||||
ranges = <0x0 0x10000 0x1000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
led@8,0 {
|
||||
compatible = "register-bit-led";
|
||||
reg = <0x08 0x04>;
|
||||
offset = <0x08>;
|
||||
mask = <0x01>;
|
||||
label = "vexpress:0";
|
||||
linux,default-trigger = "heartbeat";
|
||||
default-state = "on";
|
||||
};
|
||||
};
|
||||
@ -41,35 +41,6 @@ Examples:
|
||||
reg = <0xffffe800 0x200>;
|
||||
};
|
||||
|
||||
RAMC PHY Controller required properties:
|
||||
- compatible: Should be "microchip,sama7g5-ddr3phy", "syscon"
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
Example:
|
||||
|
||||
ddr3phy: ddr3phy@e3804000 {
|
||||
compatible = "microchip,sama7g5-ddr3phy", "syscon";
|
||||
reg = <0xe3804000 0x1000>;
|
||||
};
|
||||
|
||||
Special Function Registers (SFR)
|
||||
|
||||
Special Function Registers (SFR) manage specific aspects of the integrated
|
||||
memory, bridge implementations, processor and other functionality not controlled
|
||||
elsewhere.
|
||||
|
||||
required properties:
|
||||
- compatible: Should be "atmel,<chip>-sfr", "syscon" or
|
||||
"atmel,<chip>-sfrbu", "syscon"
|
||||
<chip> can be "sama5d3", "sama5d4" or "sama5d2".
|
||||
It also can be "microchip,sam9x60-sfr", "syscon".
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
sfr@f0038000 {
|
||||
compatible = "atmel,sama5d3-sfr", "syscon";
|
||||
reg = <0xf0038000 0x60>;
|
||||
};
|
||||
|
||||
Security Module (SECUMOD)
|
||||
|
||||
The Security Module macrocell provides all necessary secure functions to avoid
|
||||
|
||||
@ -7,22 +7,6 @@ ARTPEC-6 ARM SoC
|
||||
Required root node properties:
|
||||
- compatible = "axis,artpec6";
|
||||
|
||||
ARTPEC-6 System Controller
|
||||
--------------------------
|
||||
|
||||
The ARTPEC-6 has a system controller with mixed functions controlling DMA, PCIe
|
||||
and resets.
|
||||
|
||||
Required properties:
|
||||
- compatible: "axis,artpec6-syscon", "syscon"
|
||||
- reg: Address and length of the register bank.
|
||||
|
||||
Example:
|
||||
syscon {
|
||||
compatible = "axis,artpec6-syscon", "syscon";
|
||||
reg = <0xf8000000 0x48>;
|
||||
};
|
||||
|
||||
ARTPEC-6 Development board:
|
||||
---------------------------
|
||||
Required root node properties:
|
||||
|
||||
@ -23,6 +23,12 @@ properties:
|
||||
- raspberrypi,4-model-b
|
||||
- const: brcm,bcm2711
|
||||
|
||||
- description: BCM2712 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- raspberrypi,5-model-b
|
||||
- const: brcm,bcm2712
|
||||
|
||||
- description: BCM2835 based Boards
|
||||
items:
|
||||
- enum:
|
||||
|
||||
@ -27,16 +27,6 @@ Properties:
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
|
||||
* Alpine System-Fabric Service Registers
|
||||
|
||||
The System-Fabric Service Registers allow various operation on CPU and
|
||||
system fabric, like powering CPUs off.
|
||||
|
||||
Properties:
|
||||
- compatible : Should contain "al,alpine-sysfabric-service" and "syscon".
|
||||
- reg : Offset and length of the register set for the device
|
||||
|
||||
|
||||
Example:
|
||||
|
||||
cpus {
|
||||
|
||||
@ -147,6 +147,7 @@ properties:
|
||||
- arm,cortex-a710
|
||||
- arm,cortex-a715
|
||||
- arm,cortex-a720
|
||||
- arm,cortex-a725
|
||||
- arm,cortex-m0
|
||||
- arm,cortex-m0+
|
||||
- arm,cortex-m1
|
||||
@ -161,10 +162,15 @@ properties:
|
||||
- arm,cortex-x2
|
||||
- arm,cortex-x3
|
||||
- arm,cortex-x4
|
||||
- arm,cortex-x925
|
||||
- arm,neoverse-e1
|
||||
- arm,neoverse-n1
|
||||
- arm,neoverse-n2
|
||||
- arm,neoverse-n3
|
||||
- arm,neoverse-v1
|
||||
- arm,neoverse-v2
|
||||
- arm,neoverse-v3
|
||||
- arm,neoverse-v3ae
|
||||
- brcm,brahma-b15
|
||||
- brcm,brahma-b53
|
||||
- brcm,vulcan
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user