dlan17/linux
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge drm/drm-next into drm-intel-next

Browse Source 
Backmerge to bring Xe driver to drm-intel-next.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>
This commit is contained in:
Jani Nikula
2024-01-15 09:38:05 +02:00
parent 78d49aaa36 205e18c135
commit 0ea5c948cb
14500 changed files with 980358 additions and 311196 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.gitignore
-1
View File
@@ -74,7 +74,6 @@ modules.order
#
# RPM spec file (make rpm-pkg)
#
/kernel.spec
/rpmbuild/
#
.mailmap
+9 -2
View File
@@ -87,6 +87,7 @@ Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@unisoc.com>
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang7@gmail.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
Bartosz Golaszewski <brgl@bgdev.pl> <bgolaszewski@baylibre.com>
Ben Dooks <ben-linux@fluff.org> <ben.dooks@simtec.co.uk>
Ben Dooks <ben-linux@fluff.org> <ben.dooks@sifive.com>
Ben Gardner <bgardner@wabtec.com>
@@ -94,6 +95,7 @@ Ben M Cahill <ben.m.cahill@intel.com>
Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net>
Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com>
Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com>
Benjamin Poirier <benjamin.poirier@gmail.com> <bpoirier@suse.de>
Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se>
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org>
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com>
@@ -115,6 +117,7 @@ Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
Chester Lin <chester62515@gmail.com> <clin@suse.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com>
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
Chris Lew <quic_clew@quicinc.com> <clew@codeaurora.org>
@@ -127,6 +130,7 @@ Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
Christian Marangi <ansuelsmth@gmail.com>
Christophe Ricard <christophe.ricard@gmail.com>
Christoph Hellwig <hch@lst.de>
Claudiu Beznea <claudiu.beznea@tuxon.dev> <claudiu.beznea@microchip.com>
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
@@ -377,6 +381,7 @@ Matthew Wilcox <willy@infradead.org> <willy@debian.org>
Matthew Wilcox <willy@infradead.org> <willy@linux.intel.com>
Matthew Wilcox <willy@infradead.org> <willy@parisc-linux.org>
Matthias Fuchs <socketcan@esd.eu> <matthias.fuchs@esd.eu>
Matthieu Baerts <matttbe@kernel.org> <matthieu.baerts@tessares.net>
Matthieu CASTET <castet.matthieu@free.fr>
Matti Vaittinen <mazziesaccount@gmail.com> <matti.vaittinen@fi.rohmeurope.com>
Matt Ranostay <matt.ranostay@konsulko.com> <matt@ranostay.consulting>
@@ -449,9 +454,10 @@ Oleksandr Natalenko <oleksandr@natalenko.name> <oleksandr@redhat.com>
Oleksij Rempel <linux@rempel-privat.de> <bug-track@fisher-privat.net>
Oleksij Rempel <linux@rempel-privat.de> <external.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <fixed-term.Oleksij.Rempel@de.bosch.com>
Oleksij Rempel <linux@rempel-privat.de> <o.rempel@pengutronix.de>
Oleksij Rempel <linux@rempel-privat.de> <ore@pengutronix.de>
Oleksij Rempel <o.rempel@pengutronix.de>
Oleksij Rempel <o.rempel@pengutronix.de> <ore@pengutronix.de>
Oliver Upton <oliver.upton@linux.dev> <oupton@google.com>
Ondřej Jirman <megi@xff.cz> <megous@megous.com>
Oza Pawandeep <quic_poza@quicinc.com> <poza@codeaurora.org>
Pali Rohár <pali@kernel.org> <pali.rohar@gmail.com>
Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
@@ -565,6 +571,7 @@ Takashi YOSHII <takashi.yoshii.zj@renesas.com>
Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> <tamizhr@codeaurora.org>
Taniya Das <quic_tdas@quicinc.com> <tdas@codeaurora.org>
Tejun Heo <htejun@gmail.com>
Tomeu Vizoso <tomeu@tomeuvizoso.net> <tomeu.vizoso@collabora.com>
Thomas Graf <tgraf@suug.ch>
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
Thomas Pedersen <twp@codeaurora.org>
CREDITS
+8
View File
@@ -2944,6 +2944,14 @@ D: IPX development and support
N: Venkatesh Pallipadi (Venki)
D: x86/HPET
N: Antti Palosaari
E: crope@iki.fi
D: Various DVB drivers
W: https://palosaari.fi/linux/
S: Yliopistokatu 1 D 513
S: FI-90570 Oulu
S: FINLAND
N: Kyungmin Park
E: kyungmin.park@samsung.com
D: Samsung S5Pv210 and Exynos4210 mobile platforms
Documentation/ABI/stable/sysfs-driver-dma-idxd
+6
View File
@@ -270,6 +270,12 @@ Description: Shows the operation capability bits displayed in bitmap format
correlates to the operations allowed. It's visible only
on platforms that support the capability.
What: /sys/bus/dsa/devices/wq<m>.<n>/driver_name
Date: Sept 8, 2023
KernelVersion: 6.7.0
Contact: dmaengine@vger.kernel.org
Description: Name of driver to be bounded to the wq.
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
Date: Oct 25, 2019
KernelVersion: 5.6.0
Documentation/ABI/testing/configfs-tsm
+82
View File
@@ -0,0 +1,82 @@
What: /sys/kernel/config/tsm/report/$name/inblob
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(WO) Up to 64 bytes of user specified binary data. For replay
protection this should include a nonce, but the kernel does not
place any restrictions on the content.
What: /sys/kernel/config/tsm/report/$name/outblob
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) Binary attestation report generated from @inblob and other
options The format of the report is implementation specific
where the implementation is conveyed via the @provider
attribute.
What: /sys/kernel/config/tsm/report/$name/auxblob
Date: October, 2023
KernelVersion: v6.7
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
auxiliary data is available.
When @provider is "sev_guest" this file contains the
"cert_table" from SEV-ES Guest-Hypervisor Communication Block
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/provider
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) A name for the format-specification of @outblob like
"sev_guest" [1] or "tdx_guest" [2] in the near term, or a
common standard format in the future.
[1]: SEV Secure Nested Paging Firmware ABI Specification
Revision 1.55 Table 22
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
[2]: Intel® Trust Domain Extensions Data Center Attestation
Primitives : Quote Generation Library and Quote Verification
Library Revision 0.8 Appendix 4,5
https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
What: /sys/kernel/config/tsm/report/$name/generation
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) The value in this attribute increments each time @inblob or
any option is written. Userspace can detect conflicts by
checking generation before writing to any attribute and making
sure the number of writes matches expectations after reading
@outblob, or it can prevent conflicts by creating a report
instance per requesting context.
What: /sys/kernel/config/tsm/report/$name/privlevel
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(WO) Attribute is visible if a TSM implementation provider
supports the concept of attestation reports for TVMs running at
different privilege levels, like SEV-SNP "VMPL", specify the
privilege level via this attribute. The minimum acceptable
value is conveyed via @privlevel_floor and the maximum
acceptable value is TSM_PRIVLEVEL_MAX (3).
What: /sys/kernel/config/tsm/report/$name/privlevel_floor
Date: September, 2023
KernelVersion: v6.7
Contact: linux-coco@lists.linux.dev
Description:
(RO) Indicates the minimum permissible value that can be written
to @privlevel.
Documentation/ABI/testing/configfs-usb-gadget-uac2
+2
View File
@@ -35,4 +35,6 @@ Description:
req_number the number of pre-allocated requests
for both capture and playback
function_name name of the interface
c_terminal_type code of the capture terminal type
p_terminal_type code of the playback terminal type
===================== =======================================
Documentation/ABI/testing/debugfs-driver-habanalabs
+41 -41
View File
@@ -1,4 +1,4 @@
What: /sys/kernel/debug/habanalabs/hl<n>/addr
What: /sys/kernel/debug/accel/<parent_device>/addr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -8,34 +8,34 @@ Description: Sets the device address to be used for read or write through
only when the IOMMU is disabled.
The acceptable value is a string that starts with "0x"
What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate
What: /sys/kernel/debug/accel/<parent_device>/clk_gate
Date: May 2020
KernelVersion: 5.8
Contact: ogabbay@kernel.org
Description: This setting is now deprecated as clock gating is handled solely by the f/w
What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers
What: /sys/kernel/debug/accel/<parent_device>/command_buffers
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently allocated
command buffers
What: /sys/kernel/debug/habanalabs/hl<n>/command_submission
What: /sys/kernel/debug/accel/<parent_device>/command_submission
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently active
command submissions
What: /sys/kernel/debug/habanalabs/hl<n>/command_submission_jobs
What: /sys/kernel/debug/accel/<parent_device>/command_submission_jobs
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays a list with detailed information about each JOB (CB) of
each active command submission
What: /sys/kernel/debug/habanalabs/hl<n>/data32
What: /sys/kernel/debug/accel/<parent_device>/data32
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -50,7 +50,7 @@ Description: Allows the root user to read or write directly through the
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/data64
What: /sys/kernel/debug/accel/<parent_device>/data64
Date: Jan 2020
KernelVersion: 5.6
Contact: ogabbay@kernel.org
@@ -65,7 +65,7 @@ Description: Allows the root user to read or write 64 bit data directly
If the IOMMU is disabled, it also allows the root user to read
or write from the host a device VA of a host mapped memory
What: /sys/kernel/debug/habanalabs/hl<n>/data_dma
What: /sys/kernel/debug/accel/<parent_device>/data_dma
Date: Apr 2021
KernelVersion: 5.13
Contact: ogabbay@kernel.org
@@ -79,11 +79,11 @@ Description: Allows the root user to read from the device's internal
a very long time.
This interface doesn't support concurrency in the same device.
In GAUDI and GOYA, this action can cause undefined behavior
in case the it is done while the device is executing user
in case it is done while the device is executing user
workloads.
Only supported on GAUDI at this stage.
What: /sys/kernel/debug/habanalabs/hl<n>/device
What: /sys/kernel/debug/accel/<parent_device>/device
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -91,14 +91,14 @@ Description: Enables the root user to set the device to specific state.
Valid values are "disable", "enable", "suspend", "resume".
User can read this property to see the valid values
What: /sys/kernel/debug/habanalabs/hl<n>/device_release_watchdog_timeout
What: /sys/kernel/debug/accel/<parent_device>/device_release_watchdog_timeout
Date: Oct 2022
KernelVersion: 6.2
Contact: ttayar@habana.ai
Description: The watchdog timeout value in seconds for a device release upon
certain error cases, after which the device is reset.
What: /sys/kernel/debug/habanalabs/hl<n>/dma_size
What: /sys/kernel/debug/accel/<parent_device>/dma_size
Date: Apr 2021
KernelVersion: 5.13
Contact: ogabbay@kernel.org
@@ -108,7 +108,7 @@ Description: Specify the size of the DMA transaction when using DMA to read
When the write is finished, the user can read the "data_dma"
blob
What: /sys/kernel/debug/habanalabs/hl<n>/dump_razwi_events
What: /sys/kernel/debug/accel/<parent_device>/dump_razwi_events
Date: Aug 2022
KernelVersion: 5.20
Contact: fkassabri@habana.ai
@@ -117,7 +117,7 @@ Description: Dumps all razwi events to dmesg if exist.
the routine will clear the status register.
Usage: cat dump_razwi_events
What: /sys/kernel/debug/habanalabs/hl<n>/dump_security_violations
What: /sys/kernel/debug/accel/<parent_device>/dump_security_violations
Date: Jan 2021
KernelVersion: 5.12
Contact: ogabbay@kernel.org
@@ -125,14 +125,14 @@ Description: Dumps all security violations to dmesg. This will also ack
all security violations meanings those violations will not be
dumped next time user calls this API
What: /sys/kernel/debug/habanalabs/hl<n>/engines
What: /sys/kernel/debug/accel/<parent_device>/engines
Date: Jul 2019
KernelVersion: 5.3
Contact: ogabbay@kernel.org
Description: Displays the status registers values of the device engines and
their derived idle status
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_addr
What: /sys/kernel/debug/accel/<parent_device>/i2c_addr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -140,7 +140,7 @@ Description: Sets I2C device address for I2C transaction that is generated
by the device's CPU, Not available when device is loaded with secured
firmware
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_bus
What: /sys/kernel/debug/accel/<parent_device>/i2c_bus
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -148,7 +148,7 @@ Description: Sets I2C bus address for I2C transaction that is generated by
the device's CPU, Not available when device is loaded with secured
firmware
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_data
What: /sys/kernel/debug/accel/<parent_device>/i2c_data
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -157,7 +157,7 @@ Description: Triggers an I2C transaction that is generated by the device's
reading from the file generates a read transaction, Not available
when device is loaded with secured firmware
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_len
What: /sys/kernel/debug/accel/<parent_device>/i2c_len
Date: Dec 2021
KernelVersion: 5.17
Contact: obitton@habana.ai
@@ -165,7 +165,7 @@ Description: Sets I2C length in bytes for I2C transaction that is generated b
the device's CPU, Not available when device is loaded with secured
firmware
What: /sys/kernel/debug/habanalabs/hl<n>/i2c_reg
What: /sys/kernel/debug/accel/<parent_device>/i2c_reg
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -173,35 +173,35 @@ Description: Sets I2C register id for I2C transaction that is generated by
the device's CPU, Not available when device is loaded with secured
firmware
What: /sys/kernel/debug/habanalabs/hl<n>/led0
What: /sys/kernel/debug/accel/<parent_device>/led0
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the state of the first S/W led on the device, Not available
when device is loaded with secured firmware
What: /sys/kernel/debug/habanalabs/hl<n>/led1
What: /sys/kernel/debug/accel/<parent_device>/led1
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the state of the second S/W led on the device, Not available
when device is loaded with secured firmware
What: /sys/kernel/debug/habanalabs/hl<n>/led2
What: /sys/kernel/debug/accel/<parent_device>/led2
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the state of the third S/W led on the device, Not available
when device is loaded with secured firmware
What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub
What: /sys/kernel/debug/accel/<parent_device>/memory_scrub
Date: May 2022
KernelVersion: 5.19
Contact: dhirschfeld@habana.ai
Description: Allows the root user to scrub the dram memory. The scrubbing
value can be set using the debugfs file memory_scrub_val.
What: /sys/kernel/debug/habanalabs/hl<n>/memory_scrub_val
What: /sys/kernel/debug/accel/<parent_device>/memory_scrub_val
Date: May 2022
KernelVersion: 5.19
Contact: dhirschfeld@habana.ai
@@ -209,7 +209,7 @@ Description: The value to which the dram will be set to when the user
scrubs the dram using 'memory_scrub' debugfs file and
the scrubbing value when using module param 'memory_scrub'
What: /sys/kernel/debug/habanalabs/hl<n>/mmu
What: /sys/kernel/debug/accel/<parent_device>/mmu
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -217,19 +217,19 @@ Description: Displays the hop values and physical address for a given ASID
and virtual address. The user should write the ASID and VA into
the file and then read the file to get the result.
e.g. to display info about VA 0x1000 for ASID 1 you need to do:
echo "1 0x1000" > /sys/kernel/debug/habanalabs/hl0/mmu
echo "1 0x1000" > /sys/kernel/debug/accel/0/mmu
What: /sys/kernel/debug/habanalabs/hl<n>/mmu_error
What: /sys/kernel/debug/accel/<parent_device>/mmu_error
Date: Mar 2021
KernelVersion: 5.12
Contact: fkassabri@habana.ai
Description: Check and display page fault or access violation mmu errors for
all MMUs specified in mmu_cap_mask.
e.g. to display error info for MMU hw cap bit 9, you need to do:
echo "0x200" > /sys/kernel/debug/habanalabs/hl0/mmu_error
cat /sys/kernel/debug/habanalabs/hl0/mmu_error
echo "0x200" > /sys/kernel/debug/accel/0/mmu_error
cat /sys/kernel/debug/accel/0/mmu_error
What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump
What: /sys/kernel/debug/accel/<parent_device>/monitor_dump
Date: Mar 2022
KernelVersion: 5.19
Contact: osharabi@habana.ai
@@ -243,7 +243,7 @@ Description: Allows the root user to dump monitors status from the device's
This interface doesn't support concurrency in the same device.
Only supported on GAUDI.
What: /sys/kernel/debug/habanalabs/hl<n>/monitor_dump_trig
What: /sys/kernel/debug/accel/<parent_device>/monitor_dump_trig
Date: Mar 2022
KernelVersion: 5.19
Contact: osharabi@habana.ai
@@ -253,14 +253,14 @@ Description: Triggers dump of monitor data. The value to trigger the operatio
When the write is finished, the user can read the "monitor_dump"
blob
What: /sys/kernel/debug/habanalabs/hl<n>/set_power_state
What: /sys/kernel/debug/accel/<parent_device>/set_power_state
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Sets the PCI power state. Valid values are "1" for D0 and "2"
for D3Hot
What: /sys/kernel/debug/habanalabs/hl<n>/skip_reset_on_timeout
What: /sys/kernel/debug/accel/<parent_device>/skip_reset_on_timeout
Date: Jun 2021
KernelVersion: 5.13
Contact: ynudelman@habana.ai
@@ -268,7 +268,7 @@ Description: Sets the skip reset on timeout option for the device. Value of
"0" means device will be reset in case some CS has timed out,
otherwise it will not be reset.
What: /sys/kernel/debug/habanalabs/hl<n>/state_dump
What: /sys/kernel/debug/accel/<parent_device>/state_dump
Date: Oct 2021
KernelVersion: 5.15
Contact: ynudelman@habana.ai
@@ -279,7 +279,7 @@ Description: Gets the state dump occurring on a CS timeout or failure.
Writing an integer X discards X state dumps, so that the
next read would return X+1-st newest state dump.
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
What: /sys/kernel/debug/accel/<parent_device>/stop_on_err
Date: Mar 2020
KernelVersion: 5.6
Contact: ogabbay@kernel.org
@@ -287,21 +287,21 @@ Description: Sets the stop-on_error option for the device engines. Value of
"0" is for disable, otherwise enable.
Relevant only for GOYA and GAUDI.
What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked
What: /sys/kernel/debug/accel/<parent_device>/timeout_locked
Date: Sep 2021
KernelVersion: 5.16
Contact: obitton@habana.ai
Description: Sets the command submission timeout value in seconds.
What: /sys/kernel/debug/habanalabs/hl<n>/userptr
What: /sys/kernel/debug/accel/<parent_device>/userptr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays a list with information about the currently user
Description: Displays a list with information about the current user
pointers (user virtual addresses) that are pinned and mapped
to DMA addresses
What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
What: /sys/kernel/debug/accel/<parent_device>/userptr_lookup
Date: Oct 2021
KernelVersion: 5.15
Contact: ogabbay@kernel.org
@@ -309,7 +309,7 @@ Description: Allows to search for specific user pointers (user virtual
addresses) that are pinned and mapped to DMA addresses, and see
their resolution to the specific dma address.
What: /sys/kernel/debug/habanalabs/hl<n>/vm
What: /sys/kernel/debug/accel/<parent_device>/vm
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Documentation/ABI/testing/debugfs-driver-qat
+23 -1
View File
@@ -1,4 +1,4 @@
What: /sys/kernel/debug/qat_<device>_<BDF>/qat/fw_counters
What: /sys/kernel/debug/qat_<device>_<BDF>/fw_counters
Date: November 2023
KernelVersion: 6.6
Contact: qat-linux@intel.com
@@ -59,3 +59,25 @@ Description: (RO) Read returns the device health status.
The driver does not monitor for Heartbeat. It is left for a user
to poll the status periodically.
What: /sys/kernel/debug/qat_<device>_<BDF>/pm_status
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Read returns power management information specific to the
QAT device.
This attribute is only available for qat_4xxx devices.
What: /sys/kernel/debug/qat_<device>_<BDF>/cnv_errors
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Read returns, for each Acceleration Engine (AE), the number
of errors and the type of the last error detected by the device
when performing verified compression.
Reported counters::
<N>: Number of Compress and Verify (CnV) errors and type
of the last CnV error detected by Acceleration
Engine N.
Documentation/ABI/testing/sysfs-bus-cdx
+62 -4
View File
@@ -28,14 +28,57 @@ Description:
of a device manufacturer.
Combination of Vendor ID and Device ID identifies a device.
What: /sys/bus/cdx/devices/.../subsystem_vendor
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
Subsystem Vendor ID for this CDX device, in hexadecimal.
Subsystem Vendor ID is 16 bit identifier specific to the
card manufacturer.
What: /sys/bus/cdx/devices/.../subsystem_device
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
Subsystem Device ID for this CDX device, in hexadecimal
Subsystem Device ID is 16 bit identifier specific to the
card manufacturer.
What: /sys/bus/cdx/devices/.../class
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
This file contains the class of the CDX device, in hexadecimal.
Class is 24 bit identifier specifies the functionality of the device.
What: /sys/bus/cdx/devices/.../revision
Date: July 2023
Contact: puneet.gupta@amd.com
Description:
This file contains the revision field of the CDX device, in hexadecimal.
Revision is 8 bit revision identifier of the device.
What: /sys/bus/cdx/devices/.../enable
Date: October 2023
Contact: abhijit.gangurde@amd.com
Description:
CDX bus should be disabled before updating the devices in FPGA.
Writing n/0/off will attempt to disable the CDX bus and.
writing y/1/on will attempt to enable the CDX bus. Reading this file
gives the current state of the bus, 1 for enabled and 0 for disabled.
For example::
# echo 1 > /sys/bus/cdx/.../enable
What: /sys/bus/cdx/devices/.../reset
Date: March 2023
Contact: nipun.gupta@amd.com
Description:
Writing y/1/on to this file resets the CDX device.
On resetting the device, the corresponding driver is notified
twice, once before the device is being reset, and again after
the reset has been complete.
Writing y/1/on to this file resets the CDX device or all devices
on the bus. On resetting the device, the corresponding driver is
notified twice, once before the device is being reset, and again
after the reset has been complete.
For example::
@@ -54,3 +97,18 @@ Description:
For example::
# echo 1 > /sys/bus/cdx/devices/.../remove
What: /sys/bus/cdx/devices/.../modalias
Date: July 2023
Contact: nipun.gupta@amd.com
Description:
This attribute indicates the CDX ID of the device.
That is in the format:
cdx:vXXXXdXXXXsvXXXXsdXXXXcXXXXXX,
where:
- vXXXX contains the vendor ID;
- dXXXX contains the device ID;
- svXXXX contains the subsystem vendor ID;
- sdXXXX contains the subsystem device ID;
- cXXXXXX contains the device class.
Documentation/ABI/testing/sysfs-bus-cxl
+30
View File
@@ -178,6 +178,21 @@ Description:
hardware decoder target list.
What: /sys/bus/cxl/devices/portX/decoders_committed
Date: October, 2023
KernelVersion: v6.7
Contact: linux-cxl@vger.kernel.org
Description:
(RO) A memory device is considered active when any of its
decoders are in the "committed" state (See CXL 3.0 8.2.4.19.7
CXL HDM Decoder n Control Register). Hotplug and destructive
operations like "sanitize" are blocked while device is actively
decoding a Host Physical Address range. Note that this number
may be elevated without any regionX objects active or even
enumerated, as this may be due to decoders established by
platform firwmare or a previous kernel (kexec).
What: /sys/bus/cxl/devices/decoderX.Y
Date: June, 2021
KernelVersion: v5.14
@@ -369,6 +384,21 @@ Description:
provided it is currently idle / not bound to a driver.
What: /sys/bus/cxl/devices/decoderX.Y/qos_class
Date: May, 2023
KernelVersion: v6.5
Contact: linux-cxl@vger.kernel.org
Description:
(RO) For CXL host platforms that support "QoS Telemmetry" this
root-decoder-only attribute conveys a platform specific cookie
that identifies a QoS performance class for the CXL Window.
This class-id can be compared against a similar "qos_class"
published for each memory-type that an endpoint supports. While
it is not required that endpoints map their local memory-class
to a matching platform class, mismatches are not recommended and
there are platform specific side-effects that may result.
What: /sys/bus/cxl/devices/regionZ/uuid
Date: May, 2022
KernelVersion: v6.0
Documentation/ABI/testing/sysfs-bus-i3c
+2 -2
View File
@@ -67,7 +67,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/pid
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org
Description:
PID stands for Provisional ID and is used to uniquely identify
PID stands for Provisioned ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.
@@ -123,7 +123,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/pid
KernelVersion: 5.0
Contact: linux-i3c@vger.kernel.org
Description:
PID stands for Provisional ID and is used to uniquely identify
PID stands for Provisioned ID and is used to uniquely identify
a device on a bus. This PID contains information about the
vendor, the part and an instance ID so that several devices of
the same type can be connected on the same bus.
Documentation/ABI/testing/sysfs-bus-iio
+75
View File
@@ -279,6 +279,35 @@ Description:
but should match other such assignments on device).
Units after application of scale and offset are m/s^2.
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_z_raw
KernelVersion: 6.5
Contact: linux-iio@vger.kernel.org
Description:
Angular displacement between two consecutive samples on x, y or
z (may be arbitrarily assigned but should match other such
assignments on device).
In order to compute the total angular displacement during a
desired period of time, the application should sum-up the delta
angle samples acquired during that time.
Units after application of scale and offset are radians.
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_y_raw
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_z_raw
KernelVersion: 6.5
Contact: linux-iio@vger.kernel.org
Description:
The linear velocity change between two consecutive samples on x,
y or z (may be arbitrarily assigned but should match other such
assignments on device).
In order to compute the total linear velocity change during a
desired period of time, the application should sum-up the delta
velocity samples acquired during that time.
Units after application of scale and offset are meters per
second.
What: /sys/bus/iio/devices/iio:deviceX/in_angl_raw
What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
KernelVersion: 4.17
@@ -461,6 +490,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
What: /sys/bus/iio/devices/iio:deviceX/in_countY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_scale
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_scale
What: /sys/bus/iio/devices/iio:deviceX/in_angl_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale
@@ -1332,6 +1363,12 @@ Description:
What: /sys/.../iio:deviceX/bufferY/in_accel_x_en
What: /sys/.../iio:deviceX/bufferY/in_accel_y_en
What: /sys/.../iio:deviceX/bufferY/in_accel_z_en
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_en
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_en
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_en
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_en
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_en
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_en
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_en
@@ -1362,6 +1399,8 @@ Description:
Scan element control for triggered data capture.
What: /sys/.../iio:deviceX/bufferY/in_accel_type
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_type
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_type
What: /sys/.../iio:deviceX/bufferY/in_anglvel_type
What: /sys/.../iio:deviceX/bufferY/in_magn_type
What: /sys/.../iio:deviceX/bufferY/in_incli_type
@@ -1416,6 +1455,12 @@ What: /sys/.../iio:deviceX/bufferY/in_voltage_q_index
What: /sys/.../iio:deviceX/bufferY/in_accel_x_index
What: /sys/.../iio:deviceX/bufferY/in_accel_y_index
What: /sys/.../iio:deviceX/bufferY/in_accel_z_index
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_index
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_index
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_index
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_index
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_index
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_index
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_index
@@ -2179,3 +2224,33 @@ Contact: linux-iio@vger.kernel.org
Description:
Number of conditions that must occur, during a running
period, before an event is generated.
What: /sys/bus/iio/devices/iio:deviceX/in_colortemp_raw
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Represents light color temperature, which measures light color
temperature in Kelvin.
What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_x_raw
What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_y_raw
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
The x and y light color coordinate on the CIE 1931 chromaticity
diagram.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_either_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_falling_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_anglvelY_mag_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_anglY_thresh_rising_label
What: /sys/bus/iio/devices/iio:deviceX/events/in_phaseY_mag_rising_label
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Optional symbolic label to a device channel event.
If a label is defined for this event add that to the event
specific attributes. This is useful for userspace to be able to
better identify an individual event.
Documentation/ABI/testing/sysfs-bus-iio-adc-mcp3564
+53
View File
@@ -0,0 +1,53 @@
What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to set the gain of the biasing current
circuit of the Delta-Sigma modulator. The different BOOST
settings are applied to the entire modulator circuit, including
the voltage reference buffers.
What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain_available
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
Reading returns a list with the possible gain values for
the current biasing circuit of the Delta-Sigma modulator.
What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_mux_enable
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to enable the analog input multiplexer
auto-zeroing algorithm (the input multiplexer and the ADC
include an offset cancellation algorithm that cancels the offset
contribution of the ADC). When the offset cancellation algorithm
is enabled, ADC takes two conversions, one with the differential
input as VIN+/VIN-, one with VIN+/VIN- inverted. In this case the
conversion time is multiplied by two compared to the default
case where the algorithm is disabled. This technique allows the
cancellation of the ADC offset error and the achievement of
ultra-low offset without any digital calibration. The resulting
offset is the residue of the difference between the two
conversions, which is on the order of magnitude of the noise
floor. This offset is effectively canceled at every conversion,
so the residual offset error temperature drift is extremely low.
Write '1' to enable it, write '0' to disable it.
What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_ref_enable
KernelVersion: 6.4
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to enable the chopping algorithm for the
internal voltage reference buffer. This setting has no effect
when external voltage reference is selected.
Internal voltage reference buffer injects a certain quantity of
1/f noise into the system that can be modulated with the
incoming input signals and can limit the SNR performance at
higher Oversampling Ratio values (over 256). To overcome this
limitation, the buffer includes an auto-zeroing algorithm that
greatly reduces (cancels out) the 1/f noise and cancels the
offset value of the reference buffer. As a result, the SNR of
the system is not affected by this 1/f noise component of the
reference buffer, even at maximum oversampling ratio values.
Write '1' to enable it, write '0' to disable it.
Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s1210
+27
View File
@@ -0,0 +1,27 @@
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the current Degradation of Signal Reset Maximum
Threshold value in millivolts. Writing sets the value.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max_available
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the allowable voltage range for
in_altvoltage0_mag_rising_reset_max.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the current Degradation of Signal Reset Minimum
Threshold value in millivolts. Writing sets the value.
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min_available
KernelVersion: 6.7
Contact: linux-iio@vger.kernel.org
Description:
Reading returns the allowable voltage range for
in_altvoltage0_mag_rising_reset_min.
Documentation/ABI/testing/sysfs-bus-optee-devices
+9
View File
@@ -6,3 +6,12 @@ Description:
OP-TEE bus provides reference to registered drivers under this directory. The <uuid>
matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers
are free to create needed API under optee-ta-<uuid> directory.
What: /sys/bus/tee/devices/optee-ta-<uuid>/need_supplicant
Date: November 2023
KernelVersion: 6.7
Contact: op-tee@lists.trustedfirmware.org
Description:
Allows to distinguish whether an OP-TEE based TA/device requires user-space
tee-supplicant to function properly or not. This attribute will be present for
devices which depend on tee-supplicant to be running.
Documentation/ABI/testing/sysfs-bus-papr-pmem
+1 -1
View File
@@ -8,7 +8,7 @@ Description:
more bits set in the dimm-health-bitmap retrieved in
response to H_SCM_HEALTH hcall. The details of the bit
flags returned in response to this hcall is available
at 'Documentation/powerpc/papr_hcalls.rst' . Below are
at 'Documentation/arch/powerpc/papr_hcalls.rst' . Below are
the flags reported in this sysfs file:
* "not_armed"
Documentation/ABI/testing/sysfs-bus-usb
+9
View File
@@ -313,6 +313,15 @@ Description:
Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
direction. Devices before USB 3.2 are single lane (tx_lanes = 1)
What: /sys/bus/usb/devices/.../typec
Date: November 2023
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
Symlink to the USB Type-C partner device. USB Type-C partner
represents the component that communicates over the
Configuration Channel (CC signal on USB Type-C connectors and
cables) with the local port.
What: /sys/bus/usb/devices/usbX/bAlternateSetting
Description:
The current interface alternate setting number, in decimal.
Documentation/ABI/testing/sysfs-bus-vdpa
+2 -2
View File
@@ -1,4 +1,4 @@
What: /sys/bus/vdpa/driver_autoprobe
What: /sys/bus/vdpa/drivers_autoprobe
Date: March 2020
Contact: virtualization@lists.linux-foundation.org
Description:
@@ -17,7 +17,7 @@ Description:
Writing a device name to this file will cause the kernel binds
devices to a compatible driver.
This can be useful when /sys/bus/vdpa/driver_autoprobe is
This can be useful when /sys/bus/vdpa/drivers_autoprobe is
disabled.
What: /sys/bus/vdpa/drivers/.../bind
Documentation/ABI/testing/sysfs-class-firmware
+7 -7
View File
@@ -1,7 +1,7 @@
What: /sys/class/firmware/.../data
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Russ Weight <russ.weight@linux.dev>
Description: The data sysfs file is used for firmware-fallback and for
firmware uploads. Cat a firmware image to this sysfs file
after you echo 1 to the loading sysfs file. When the firmware
@@ -13,7 +13,7 @@ Description: The data sysfs file is used for firmware-fallback and for
What: /sys/class/firmware/.../cancel
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Russ Weight <russ.weight@linux.dev>
Description: Write-only. For firmware uploads, write a "1" to this file to
request that the transfer of firmware data to the lower-level
device be canceled. This request will be rejected (EBUSY) if
@@ -23,7 +23,7 @@ Description: Write-only. For firmware uploads, write a "1" to this file to
What: /sys/class/firmware/.../error
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Russ Weight <russ.weight@linux.dev>
Description: Read-only. Returns a string describing a failed firmware
upload. This string will be in the form of <STATUS>:<ERROR>,
where <STATUS> will be one of the status strings described
@@ -37,7 +37,7 @@ Description: Read-only. Returns a string describing a failed firmware
What: /sys/class/firmware/.../loading
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Russ Weight <russ.weight@linux.dev>
Description: The loading sysfs file is used for both firmware-fallback and
for firmware uploads. Echo 1 onto the loading file to indicate
you are writing a firmware file to the data sysfs node. Echo
@@ -49,7 +49,7 @@ Description: The loading sysfs file is used for both firmware-fallback and
What: /sys/class/firmware/.../remaining_size
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Russ Weight <russ.weight@linux.dev>
Description: Read-only. For firmware upload, this file contains the size
of the firmware data that remains to be transferred to the
lower-level device driver. The size value is initialized to
@@ -62,7 +62,7 @@ Description: Read-only. For firmware upload, this file contains the size
What: /sys/class/firmware/.../status
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Russ Weight <russ.weight@linux.dev>
Description: Read-only. Returns a string describing the current status of
a firmware upload. The string will be one of the following:
idle, "receiving", "preparing", "transferring", "programming".
@@ -70,7 +70,7 @@ Description: Read-only. Returns a string describing the current status of
What: /sys/class/firmware/.../timeout
Date: July 2022
KernelVersion: 5.19
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Russ Weight <russ.weight@linux.dev>
Description: This file supports the timeout mechanism for firmware
fallback. This file has no affect on firmware uploads. For
more information on timeouts please see the documentation
Documentation/ABI/testing/sysfs-class-firmware-attributes
+30
View File
@@ -383,6 +383,36 @@ Description:
Note that any changes to this attribute requires a reboot
for changes to take effect.
What: /sys/class/firmware-attributes/*/attributes/save_settings
Date: August 2023
KernelVersion: 6.6
Contact: Mark Pearson <mpearson-lenovo@squebb.ca>
Description:
On Lenovo platforms there is a limitation in the number of times an attribute can be
saved. This is an architectural limitation and it limits the number of attributes
that can be modified to 48.
A solution for this is instead of the attribute being saved after every modification,
to allow a user to bulk set the attributes, and then trigger a final save. This allows
unlimited attributes.
Read the attribute to check what save mode is enabled (single or bulk).
E.g:
# cat /sys/class/firmware-attributes/thinklmi/attributes/save_settings
single
Write the attribute with 'bulk' to enable bulk save mode.
Write the attribute with 'single' to enable saving, after every attribute set.
The default setting is single mode.
E.g:
# echo bulk > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
When in bulk mode write 'save' to trigger a save of all currently modified attributes.
Note, once a save has been triggered, in bulk mode, attributes can no longer be set and
will return a permissions error. This is to prevent users hitting the 48+ save limitation
(which requires entering the BIOS to clear the error condition)
E.g:
# echo save > /sys/class/firmware-attributes/thinklmi/attributes/save_settings
What: /sys/class/firmware-attributes/*/attributes/debug_cmd
Date: July 2021
KernelVersion: 5.14
Documentation/ABI/testing/sysfs-class-led
-9
View File
@@ -59,15 +59,6 @@ Description:
brightness. Reading this file when no hw brightness change
event has happened will return an ENODATA error.
What: /sys/class/leds/<led>/color
Date: June 2023
KernelVersion: 6.5
Description:
Color of the LED.
This is a read-only file. Reading this file returns the color
of the LED as a string (e.g: "red", "green", "multicolor").
What: /sys/class/leds/<led>/trigger
Date: March 2006
KernelVersion: 2.6.17
Documentation/ABI/testing/sysfs-class-led-driver-turris-omnia
+14
View File
@@ -12,3 +12,17 @@ Description: (RW) On the front panel of the Turris Omnia router there is also
able to change this setting from software.
Format: %i
What: /sys/class/leds/<led>/device/gamma_correction
Date: August 2023
KernelVersion: 6.6
Contact: Marek Behún <kabel@kernel.org>
Description: (RW) Newer versions of the microcontroller firmware of the
Turris Omnia router support gamma correction for the RGB LEDs.
This feature can be enabled/disabled by writing to this file.
If the feature is not supported because the MCU firmware is too
old, the file always reads as 0, and writing to the file results
in the EOPNOTSUPP error.
Format: %i
Documentation/ABI/testing/sysfs-class-usb_power_delivery
+7
View File
@@ -124,6 +124,13 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
The voltage the supply supports in millivolts.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/peak_current
Date: October 2023
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Description:
This file shows the value of the Fixed Power Source Peak Current
Capability field.
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current
Date: May 2022
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Documentation/ABI/testing/sysfs-devices-system-cpu
-3
View File
@@ -354,9 +354,6 @@ Description: Parameters for the CPU cache attributes
- ReadWriteAllocate:
both writeallocate and readallocate
attributes:
LEGACY used only on IA64 and is same as write_policy
coherency_line_size:
the minimum amount of data in bytes that gets
transferred from memory to cache
Documentation/ABI/testing/sysfs-driver-habanalabs
+44 -32
View File
@@ -1,4 +1,4 @@
What: /sys/class/habanalabs/hl<n>/armcp_kernel_ver
What: /sys/class/accel/accel<n>/device/armcp_kernel_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -6,7 +6,7 @@ Description: Version of the Linux kernel running on the device's CPU.
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_kernel_ver
What: /sys/class/habanalabs/hl<n>/armcp_ver
What: /sys/class/accel/accel<n>/device/armcp_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -14,7 +14,7 @@ Description: Version of the application running on the device's CPU
Will be DEPRECATED in Linux kernel version 5.10, and be
replaced with cpucp_ver
What: /sys/class/habanalabs/hl<n>/clk_max_freq_mhz
What: /sys/class/accel/accel<n>/device/clk_max_freq_mhz
Date: Jun 2019
KernelVersion: 5.7
Contact: ogabbay@kernel.org
@@ -24,58 +24,58 @@ Description: Allows the user to set the maximum clock frequency, in MHz.
frequency value of the device clock. This property is valid
only for the Gaudi ASIC family
What: /sys/class/habanalabs/hl<n>/clk_cur_freq_mhz
What: /sys/class/accel/accel<n>/device/clk_cur_freq_mhz
Date: Jun 2019
KernelVersion: 5.7
Contact: ogabbay@kernel.org
Description: Displays the current frequency, in MHz, of the device clock.
This property is valid only for the Gaudi ASIC family
What: /sys/class/habanalabs/hl<n>/cpld_ver
What: /sys/class/accel/accel<n>/device/cpld_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the Device's CPLD F/W
What: /sys/class/habanalabs/hl<n>/cpucp_kernel_ver
What: /sys/class/accel/accel<n>/device/cpucp_kernel_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: ogabbay@kernel.org
Description: Version of the Linux kernel running on the device's CPU
What: /sys/class/habanalabs/hl<n>/cpucp_ver
What: /sys/class/accel/accel<n>/device/cpucp_ver
Date: Oct 2020
KernelVersion: 5.10
Contact: ogabbay@kernel.org
Description: Version of the application running on the device's CPU
What: /sys/class/habanalabs/hl<n>/device_type
What: /sys/class/accel/accel<n>/device/device_type
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the code name of the device according to its type.
The supported values are: "GOYA"
What: /sys/class/habanalabs/hl<n>/eeprom
What: /sys/class/accel/accel<n>/device/eeprom
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: A binary file attribute that contains the contents of the
on-board EEPROM
What: /sys/class/habanalabs/hl<n>/fuse_ver
What: /sys/class/accel/accel<n>/device/fuse_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the device's version from the eFuse
What: /sys/class/habanalabs/hl<n>/fw_os_ver
What: /sys/class/accel/accel<n>/device/fw_os_ver
Date: Dec 2021
KernelVersion: 5.18
Contact: ogabbay@kernel.org
Description: Version of the firmware OS running on the device's CPU
What: /sys/class/habanalabs/hl<n>/hard_reset
What: /sys/class/accel/accel<n>/device/hard_reset
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -83,14 +83,14 @@ Description: Interface to trigger a hard-reset operation for the device.
Hard-reset will reset ALL internal components of the device
except for the PCI interface and the internal PLLs
What: /sys/class/habanalabs/hl<n>/hard_reset_cnt
What: /sys/class/accel/accel<n>/device/hard_reset_cnt
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays how many times the device have undergone a hard-reset
operation since the driver was loaded
What: /sys/class/habanalabs/hl<n>/high_pll
What: /sys/class/accel/accel<n>/device/high_pll
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -98,7 +98,7 @@ Description: Allows the user to set the maximum clock frequency for MME, TPC
and IC when the power management profile is set to "automatic".
This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/ic_clk
What: /sys/class/accel/accel<n>/device/ic_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -110,27 +110,27 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
frequency value of the IC. This property is valid only for the
Goya ASIC family
What: /sys/class/habanalabs/hl<n>/ic_clk_curr
What: /sys/class/accel/accel<n>/device/ic_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the Interconnect
fabric. This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/infineon_ver
What: /sys/class/accel/accel<n>/device/infineon_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the Device's power supply F/W code. Relevant only to GOYA and GAUDI
What: /sys/class/habanalabs/hl<n>/max_power
What: /sys/class/accel/accel<n>/device/max_power
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Allows the user to set the maximum power consumption of the
device in milliwatts.
What: /sys/class/habanalabs/hl<n>/mme_clk
What: /sys/class/accel/accel<n>/device/mme_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -142,21 +142,33 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
frequency value of the MME. This property is valid only for the
Goya ASIC family
What: /sys/class/habanalabs/hl<n>/mme_clk_curr
What: /sys/class/accel/accel<n>/device/mme_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the MME compute
engine. This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/pci_addr
What: /sys/class/accel/accel<n>/device/module_id
Date: Nov 2023
KernelVersion: not yet upstreamed
Contact: ogabbay@kernel.org
Description: Displays the device's module id
What: /sys/class/accel/accel<n>/device/parent_device
Date: Nov 2023
KernelVersion: 6.8
Contact: ttayar@habana.ai
Description: Displays the name of the parent device of the accel device
What: /sys/class/accel/accel<n>/device/pci_addr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the PCI address of the device. This is needed so the
user would be able to open a device based on its PCI address
What: /sys/class/habanalabs/hl<n>/pm_mng_profile
What: /sys/class/accel/accel<n>/device/pm_mng_profile
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -170,19 +182,19 @@ Description: Power management profile. Values are "auto", "manual". In "auto"
ic_clk, mme_clk and tpc_clk. This property is valid only for
the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/preboot_btl_ver
What: /sys/class/accel/accel<n>/device/preboot_btl_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the device's preboot F/W code
What: /sys/class/habanalabs/hl<n>/security_enabled
What: /sys/class/accel/accel<n>/device/security_enabled
Date: Oct 2022
KernelVersion: 6.1
Contact: obitton@habana.ai
Description: Displays the device's security status
What: /sys/class/habanalabs/hl<n>/soft_reset
What: /sys/class/accel/accel<n>/device/soft_reset
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -190,14 +202,14 @@ Description: Interface to trigger a soft-reset operation for the device.
Soft-reset will reset only the compute and DMA engines of the
device
What: /sys/class/habanalabs/hl<n>/soft_reset_cnt
What: /sys/class/accel/accel<n>/device/soft_reset_cnt
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays how many times the device have undergone a soft-reset
operation since the driver was loaded
What: /sys/class/habanalabs/hl<n>/status
What: /sys/class/accel/accel<n>/device/status
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -215,13 +227,13 @@ Description: Status of the card:
a compute-reset which is executed after a device release
(relevant for Gaudi2 only).
What: /sys/class/habanalabs/hl<n>/thermal_ver
What: /sys/class/accel/accel<n>/device/thermal_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the Device's thermal daemon
What: /sys/class/habanalabs/hl<n>/tpc_clk
What: /sys/class/accel/accel<n>/device/tpc_clk
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
@@ -233,20 +245,20 @@ Description: Allows the user to set the maximum clock frequency, in Hz, of
frequency value of the TPC. This property is valid only for
Goya ASIC family
What: /sys/class/habanalabs/hl<n>/tpc_clk_curr
What: /sys/class/accel/accel<n>/device/tpc_clk_curr
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Displays the current clock frequency, in Hz, of the TPC compute
engines. This property is valid only for the Goya ASIC family
What: /sys/class/habanalabs/hl<n>/uboot_ver
What: /sys/class/accel/accel<n>/device/uboot_ver
Date: Jan 2019
KernelVersion: 5.1
Contact: ogabbay@kernel.org
Description: Version of the u-boot running on the device's CPU
What: /sys/class/habanalabs/hl<n>/vrm_ver
What: /sys/class/accel/accel<n>/device/vrm_ver
Date: Jan 2022
KernelVersion: 5.17
Contact: ogabbay@kernel.org
Documentation/ABI/testing/sysfs-driver-intel-m10-bmc
+2 -2
View File
@@ -17,7 +17,7 @@ Description: Read only. Returns the firmware version of Intel MAX10
What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_address
Date: January 2021
KernelVersion: 5.12
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns the first MAC address in a block
of sequential MAC addresses assigned to the board
that is managed by the Intel MAX10 BMC. It is stored in
@@ -28,7 +28,7 @@ Description: Read only. Returns the first MAC address in a block
What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_count
Date: January 2021
KernelVersion: 5.12
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns the number of sequential MAC
addresses assigned to the board managed by the Intel
MAX10 BMC. This value is stored in FLASH and is mirrored
Documentation/ABI/testing/sysfs-driver-intel-m10-bmc-sec-update
+7 -7
View File
@@ -1,7 +1,7 @@
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns the root entry hash for the static
region if one is programmed, else it returns the
string: "hash not programmed". This file is only
@@ -11,7 +11,7 @@ Description: Read only. Returns the root entry hash for the static
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns the root entry hash for the partial
reconfiguration region if one is programmed, else it
returns the string: "hash not programmed". This file
@@ -21,7 +21,7 @@ Description: Read only. Returns the root entry hash for the partial
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_root_entry_hash
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns the root entry hash for the BMC image
if one is programmed, else it returns the string:
"hash not programmed". This file is only visible if the
@@ -31,7 +31,7 @@ Description: Read only. Returns the root entry hash for the BMC image
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/sr_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the static region. The standard bitmap
list format is used (e.g. "1,2-6,9").
@@ -39,7 +39,7 @@ Description: Read only. Returns a list of indices for canceled code
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/pr_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the partial reconfiguration region. The
standard bitmap list format is used (e.g. "1,2-6,9").
@@ -47,7 +47,7 @@ Description: Read only. Returns a list of indices for canceled code
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/bmc_canceled_csks
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns a list of indices for canceled code
signing keys for the BMC. The standard bitmap list format
is used (e.g. "1,2-6,9").
@@ -55,7 +55,7 @@ Description: Read only. Returns a list of indices for canceled code
What: /sys/bus/platform/drivers/intel-m10bmc-sec-update/.../security/flash_count
Date: Sep 2022
KernelVersion: 5.20
Contact: Russ Weight <russell.h.weight@intel.com>
Contact: Peter Colberg <peter.colberg@intel.com>
Description: Read only. Returns number of times the secure update
staging area has been flashed.
Format: "%u".
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
+70
View File
@@ -0,0 +1,70 @@
What: /sys/devices/.../hwmon/hwmon<i>/power1_max
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RW. Card reactive sustained (PL1) power limit in microwatts.
The power controller will throttle the operating frequency
if the power averaged over a window (typically seconds)
exceeds this limit. A read value of 0 means that the PL1
power limit is disabled, writing 0 disables the
limit. Writing values > 0 and <= TDP will enable the power limit.
Only supported for particular Intel xe graphics platforms.
What: /sys/devices/.../hwmon/hwmon<i>/power1_rated_max
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel xe graphics platforms.
What: /sys/devices/.../hwmon/hwmon<i>/power1_crit
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RW. Card reactive critical (I1) power limit in microwatts.
Card reactive critical (I1) power limit in microwatts is exposed
for client products. The power controller will throttle the
operating frequency if the power averaged over a window exceeds
this limit.
Only supported for particular Intel xe graphics platforms.
What: /sys/devices/.../hwmon/hwmon<i>/curr1_crit
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RW. Card reactive critical (I1) power limit in milliamperes.
Card reactive critical (I1) power limit in milliamperes is
exposed for server products. The power controller will throttle
the operating frequency if the power averaged over a window
exceeds this limit.
What: /sys/devices/.../hwmon/hwmon<i>/in0_input
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel xe graphics platforms.
What: /sys/devices/.../hwmon/hwmon<i>/energy1_input
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RO. Energy input of device in microjoules.
Only supported for particular Intel xe graphics platforms.
What: /sys/devices/.../hwmon/hwmon<i>/power1_max_interval
Date: October 2023
KernelVersion: 6.6
Contact: intel-xe@lists.freedesktop.org
Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
milliseconds over which sustained power is averaged.
Only supported for particular Intel xe graphics platforms.
Documentation/ABI/testing/sysfs-driver-qat
+48
View File
@@ -29,6 +29,8 @@ Description: (RW) Reports the current configuration of the QAT device.
services
* asym;sym: identical to sym;asym
* dc: the device is configured for running compression services
* dcc: identical to dc but enables the dc chaining feature,
hash then compression. If this is not required chose dc
* sym: the device is configured for running symmetric crypto
services
* asym: the device is configured for running asymmetric crypto
@@ -93,3 +95,49 @@ Description: (RW) This configuration option provides a way to force the device i
0
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat/rp2srv
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) This attribute provides a way for a user to query a
specific ring pair for the type of service that it is currently
configured for.
When written to, the value is cached and used to perform the
read operation. Allowed values are in the range 0 to N-1, where
N is the max number of ring pairs supported by a device. This
can be queried using the attribute qat/num_rps.
A read returns the service associated to the ring pair queried.
The values are:
* dc: the ring pair is configured for running compression services
* sym: the ring pair is configured for running symmetric crypto
services
* asym: the ring pair is configured for running asymmetric crypto
services
Example usage::
# echo 1 > /sys/bus/pci/devices/<BDF>/qat/rp2srv
# cat /sys/bus/pci/devices/<BDF>/qat/rp2srv
sym
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat/num_rps
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RO) Returns the number of ring pairs that a single device has.
Example usage::
# cat /sys/bus/pci/devices/<BDF>/qat/num_rps
64
This attribute is only available for qat_4xxx devices.
Documentation/ABI/testing/sysfs-driver-qat_ras
+41
View File
@@ -0,0 +1,41 @@
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Reports the number of correctable errors detected by the device.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Reports the number of non fatal errors detected by the device.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (RO) Reports the number of fatal errors detected by the device.
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description: (WO) Write to resets all error counters of a device.
The following example reports how to reset the counters::
# echo 1 > /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
0
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
0
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
0
This attribute is only available for qat_4xxx devices.
Documentation/ABI/testing/sysfs-driver-qat_rl
+226
View File
@@ -0,0 +1,226 @@
What: /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(WO) This attribute is used to perform an operation on an SLA.
The supported operations are: add, update, rm, rm_all, and get.
Input values must be filled through the associated attribute in
this group before a write to this file.
If the operation completes successfully, the associated
attributes will be updated.
The associated attributes are: cir, pir, srv, rp, and id.
Supported operations:
* add: Creates a new SLA with the provided inputs from user.
* Inputs: cir, pir, srv, and rp
* Output: id
* get: Returns the configuration of the specified SLA in id attribute
* Inputs: id
* Outputs: cir, pir, srv, and rp
* update: Updates the SLA with new values set in the following attributes
* Inputs: id, cir, and pir
* rm: Removes the specified SLA in the id attribute.
* Inputs: id
* rm_all: Removes all the configured SLAs.
* Inputs: None
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/rp
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) When read, reports the current assigned ring pairs for the
queried SLA.
When wrote to, configures the ring pairs associated to a new SLA.
The value is a 64-bit bit mask and is written/displayed in hex.
Each bit of this mask represents a single ring pair i.e.,
bit 1 == ring pair id 0; bit 3 == ring pair id 2.
Selected ring pairs must to be assigned to a single service,
i.e. the one provided with the srv attribute. The service
assigned to a certain ring pair can be checked by querying
the attribute qat/rp2srv.
The maximum number of ring pairs is 4 per SLA.
Applicability in sla_op:
* WRITE: add operation
* READ: get operation
Example usage::
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
0x5
## Write
# echo 0x5 > /sys/bus/pci/devices/<BDF>/qat_rl/rp
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/id
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) If written to, the value is used to retrieve a particular
SLA and operate on it.
This is valid only for the following operations: update, rm,
and get.
A read of this attribute is only guaranteed to have correct data
after creation of an SLA.
Applicability in sla_op:
* WRITE: rm and update operations
* READ: add and get operations
Example usage::
## Read
## Set attributes e.g. cir, pir, srv, etc
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/id
4
## Write
# echo 7 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
0x5 ## ring pair ID 0 and ring pair ID 2
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/cir
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) Committed information rate (CIR). Rate guaranteed to be
achieved by a particular SLA. The value is expressed in
permille scale, i.e. 1000 refers to the maximum device
throughput for a selected service.
After sending a "get" to sla_op, this will be populated with the
CIR for that queried SLA.
Write to this file before sending an "add/update" sla_op, to set
the SLA to the specified value.
Applicability in sla_op:
* WRITE: add and update operations
* READ: get operation
Example usage::
## Write
# echo 500 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
# echo "add" /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cir
500
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/pir
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) Peak information rate (PIR). The maximum rate that can be
achieved by that particular SLA. An SLA can reach a value
between CIR and PIR when the device is not fully utilized by
requests from other users (assigned to different SLAs).
After sending a "get" to sla_op, this will be populated with the
PIR for that queried SLA.
Write to this file before sending an "add/update" sla_op, to set
the SLA to the specified value.
Applicability in sla_op:
* WRITE: add and update operations
* READ: get operation
Example usage::
## Write
# echo 750 > /sys/bus/pci/devices/<BDF>/qat_rl/pir
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/pir
750
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/srv
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) Service (SRV). Represents the service (sym, asym, dc)
associated to an SLA.
Can be written to or queried to set/show the SRV type for an SLA.
The SRV attribute is used to specify the SRV type before adding
an SLA. After an SLA is configured, reports the service
associated to that SLA.
Applicability in sla_op:
* WRITE: add and update operations
* READ: get operation
Example usage::
## Write
# echo "dc" > /sys/bus/pci/devices/<BDF>/qat_rl/srv
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/id
4
## Read
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/srv
dc
This attribute is only available for qat_4xxx devices.
What: /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
Date: January 2024
KernelVersion: 6.7
Contact: qat-linux@intel.com
Description:
(RW) This file will return the remaining capability for a
particular service/sla. This is the remaining value that a new
SLA can be set to or a current SLA can be increased with.
Example usage::
# echo "asym" > /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
250
# echo 250 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
0
This attribute is only available for qat_4xxx devices.
Documentation/ABI/testing/sysfs-firmware-dmi-entries
+1 -1
View File
@@ -2,7 +2,7 @@ What: /sys/firmware/dmi/entries/
Date: February 2011
Contact: Mike Waychison <mikew@google.com>
Description:
Many machines' firmware (x86 and ia64) export DMI /
Many machines' firmware (x86 and arm64) export DMI /
SMBIOS tables to the operating system. Getting at this
information is often valuable to userland, especially in
cases where there are OEM extensions used.
Documentation/ABI/testing/sysfs-kernel-mm-damon
+7
View File
@@ -151,6 +151,13 @@ 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>/apply_interval_us
Date: Sep 2023
Contact: SeongJae Park <sj@kernel.org>
Description: Writing a value to this file sets the action apply interval of
the scheme in microseconds. Reading this file returns the
value.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min
Date: Mar 2022
Contact: SeongJae Park <sj@kernel.org>
Documentation/ABI/testing/sysfs-tty
+9 -6
View File
@@ -87,19 +87,22 @@ What: /sys/class/tty/ttyS<x>/close_delay
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the closing delay time for this port in ms.
Show the closing delay time for this port in centiseconds.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS<x>/closing_wait
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the close wait time for this port in ms.
Show the close wait time for this port in centiseconds.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
Waiting forever is represented as 0. If waiting on close is
disabled then the value is 65535.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS<x>/custom_divisor
Date: October 2012
Documentation/PCI/pci-error-recovery.rst
+2 -2
View File
@@ -364,7 +364,7 @@ Note, however, not all failures are truly "permanent". Some are
caused by over-heating, some by a poorly seated card. Many
PCI error events are caused by software bugs, e.g. DMAs to
wild addresses or bogus split transactions due to programming
errors. See the discussion in Documentation/powerpc/eeh-pci-error-recovery.rst
errors. See the discussion in Documentation/arch/powerpc/eeh-pci-error-recovery.rst
for additional detail on real-life experience of the causes of
software errors.
@@ -404,7 +404,7 @@ That is, the recovery API only requires that:
.. note::
Implementation details for the powerpc platform are discussed in
the file Documentation/powerpc/eeh-pci-error-recovery.rst
the file Documentation/arch/powerpc/eeh-pci-error-recovery.rst
As of this writing, there is a growing list of device drivers with
patches implementing error recovery. Not all of these patches are in
Documentation/RCU/Design/Expedited-Grace-Periods/Expedited-Grace-Periods.rst
+1 -1
View File
@@ -181,7 +181,7 @@ operations is carried out at several levels:
of this wait (or series of waits, as the case may be) is to permit a
concurrent CPU-hotplug operation to complete.
#. In the case of RCU-sched, one of the last acts of an outgoing CPU is
to invoke ``rcu_report_dead()``, which reports a quiescent state for
to invoke ``rcutree_report_cpu_dead()``, which reports a quiescent state for
that CPU. However, this is likely paranoia-induced redundancy.
+-----------------------------------------------------------------------+
Documentation/RCU/Design/Memory-Ordering/TreeRCU-callback-registry.svg
-9
View File
@@ -564,15 +564,6 @@
font-size="192"
id="text202-7-9-6"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_migrate_callbacks()</text>
<text
xml:space="preserve"
x="8335.4873"
y="5357.1006"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-7-9-6-0"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_migrate_callbacks()</text>
<text
xml:space="preserve"
x="8768.4678"
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 23 KiB

After

Width:  |  Height:  |  Size: 23 KiB

Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp-fqs.svg
+2 -2
View File
@@ -1135,7 +1135,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6-5"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_report_dead()</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_report_cpu_dead()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -1256,7 +1256,7 @@
font-style="normal"
y="3679.27"
x="-3804.9949"
xml:space="preserve">rcu_cpu_starting()</text>
xml:space="preserve">rcutree_report_cpu_starting()</text>
<g
style="fill:none;stroke-width:0.025in"
id="g3107-7-5-0"
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 50 KiB

After

Width:  |  Height:  |  Size: 50 KiB

Documentation/RCU/Design/Memory-Ordering/TreeRCU-gp.svg
+2 -11
View File
@@ -1446,15 +1446,6 @@
font-size="192"
id="text202-7-9-6"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_migrate_callbacks()</text>
<text
xml:space="preserve"
x="8335.4873"
y="5357.1006"
font-style="normal"
font-weight="bold"
font-size="192"
id="text202-7-9-6-0"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_migrate_callbacks()</text>
<text
xml:space="preserve"
x="8768.4678"
@@ -3274,7 +3265,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6-5"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_report_dead()</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_report_cpu_dead()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -3395,7 +3386,7 @@
font-style="normal"
y="3679.27"
x="-3804.9949"
xml:space="preserve">rcu_cpu_starting()</text>
xml:space="preserve">rcutree_report_cpu_starting()</text>
<g
style="fill:none;stroke-width:0.025in"
id="g3107-7-5-0"
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 209 KiB

After

Width:  |  Height:  |  Size: 208 KiB

Documentation/RCU/Design/Memory-Ordering/TreeRCU-hotplug.svg
+2 -2
View File
@@ -607,7 +607,7 @@
font-weight="bold"
font-size="192"
id="text202-7-5-3-27-6"
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcu_report_dead()</text>
style="font-size:192px;font-style:normal;font-weight:bold;text-anchor:start;fill:#000000;stroke-width:0.025in;font-family:Courier">rcutree_report_cpu_dead()</text>
<text
xml:space="preserve"
x="3745.7725"
@@ -728,7 +728,7 @@
font-style="normal"
y="3679.27"
x="-3804.9949"
xml:space="preserve">rcu_cpu_starting()</text>
xml:space="preserve">rcutree_report_cpu_starting()</text>
<g
style="fill:none;stroke-width:0.025in"
id="g3107-7-5-0"
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 28 KiB

After

Width:  |  Height:  |  Size: 28 KiB

Documentation/RCU/Design/Requirements/Requirements.rst
+2 -2
View File
@@ -1955,12 +1955,12 @@ if offline CPUs block an RCU grace period for too long.
An offline CPU's quiescent state will be reported either:
1. As the CPU goes offline using RCU's hotplug notifier (rcu_report_dead()).
1. As the CPU goes offline using RCU's hotplug notifier (rcutree_report_cpu_dead()).
2. When grace period initialization (rcu_gp_init()) detects a
race either with CPU offlining or with a task unblocking on a leaf
``rcu_node`` structure whose CPUs are all offline.
The CPU-online path (rcu_cpu_starting()) should never need to report
The CPU-online path (rcutree_report_cpu_starting()) should never need to report
a quiescent state for an offline CPU. However, as a debugging measure,
it does emit a warning if a quiescent state was not already reported
for that CPU.
Documentation/RCU/listRCU.rst
+9
View File
@@ -8,6 +8,15 @@ One of the most common uses of RCU is protecting read-mostly linked lists
that all of the required memory ordering is provided by the list macros.
This document describes several list-based RCU use cases.
When iterating a list while holding the rcu_read_lock(), writers may
modify the list. The reader is guaranteed to see all of the elements
which were added to the list before they acquired the rcu_read_lock()
and are still on the list when they drop the rcu_read_unlock().
Elements which are added to, or removed from the list may or may not
be seen. If the writer calls list_replace_rcu(), the reader may see
either the old element or the new element; they will not see both,
nor will they see neither.
Example 1: Read-mostly list: Deferred Destruction
-------------------------------------------------
Documentation/RCU/whatisRCU.rst
+2 -2
View File
@@ -59,8 +59,8 @@ experiment with should focus on Section 2. People who prefer to start
with example uses should focus on Sections 3 and 4. People who need to
understand the RCU implementation should focus on Section 5, then dive
into the kernel source code. People who reason best by analogy should
focus on Section 6. Section 7 serves as an index to the docbook API
documentation, and Section 8 is the traditional answer key.
focus on Section 6 and 7. Section 8 serves as an index to the docbook
API documentation, and Section 9 is the traditional answer key.
So, start with the section that makes the most sense to you and your
preferred method of learning. If you need to know everything about
Documentation/accel/qaic/aic100.rst
+8 -3
View File
@@ -36,8 +36,9 @@ AIC100 DID (0xa100).
AIC100 does not implement FLR (function level reset).
AIC100 implements MSI but does not implement MSI-X. AIC100 requires 17 MSIs to
operate (1 for MHI, 16 for the DMA Bridge).
AIC100 implements MSI but does not implement MSI-X. AIC100 prefers 17 MSIs to
operate (1 for MHI, 16 for the DMA Bridge). Falling back to 1 MSI is possible in
scenarios where reserving 32 MSIs isn't feasible.
As a PCIe device, AIC100 utilizes BARs to provide host interfaces to the device
hardware. AIC100 provides 3, 64-bit BARs.
@@ -220,10 +221,14 @@ of the defined channels, and their uses.
+----------------+---------+----------+----------------------------------------+
| QAIC_DEBUG | 18 & 19 | AMSS | Not used. |
+----------------+---------+----------+----------------------------------------+
| QAIC_TIMESYNC | 20 & 21 | SBL/AMSS | Used to synchronize timestamps in the |
| QAIC_TIMESYNC | 20 & 21 | SBL | Used to synchronize timestamps in the |
| | | | device side logs with the host time |
| | | | source. |
+----------------+---------+----------+----------------------------------------+
| QAIC_TIMESYNC | 22 & 23 | AMSS | Used to periodically synchronize |
| _PERIODIC | | | timestamps in the device side logs with|
| | | | the host time source. |
+----------------+---------+----------+----------------------------------------+
DMA Bridge
==========
Documentation/accel/qaic/qaic.rst
+36 -1
View File
@@ -10,6 +10,9 @@ accelerator products.
Interrupts
==========
IRQ Storm Mitigation
--------------------
While the AIC100 DMA Bridge hardware implements an IRQ storm mitigation
mechanism, it is still possible for an IRQ storm to occur. A storm can happen
if the workload is particularly quick, and the host is responsive. If the host
@@ -35,6 +38,26 @@ generates 100k IRQs per second (per /proc/interrupts) is reduced to roughly 64
IRQs over 5 minutes while keeping the host system stable, and having the same
workload throughput performance (within run to run noise variation).
Single MSI Mode
---------------
MultiMSI is not well supported on all systems; virtualized ones even less so
(circa 2023). Between hypervisors masking the PCIe MSI capability structure to
large memory requirements for vIOMMUs (required for supporting MultiMSI), it is
useful to be able to fall back to a single MSI when needed.
To support this fallback, we allow the case where only one MSI is able to be
allocated, and share that one MSI between MHI and the DBCs. The device detects
when only one MSI has been configured and directs the interrupts for the DBCs
to the interrupt normally used for MHI. Unfortunately this means that the
interrupt handlers for every DBC and MHI wake up for every interrupt that
arrives; however, the DBC threaded irq handlers only are started when work to be
done is detected (MHI will always start its threaded handler).
If the DBC is configured to force MSI interrupts, this can circumvent the
software IRQ storm mitigation mentioned above. Since the MSI is shared it is
never disabled, allowing each new entry to the FIFO to trigger a new interrupt.
Neural Network Control (NNC) Protocol
=====================================
@@ -70,8 +93,15 @@ commands (does not impact QAIC).
uAPI
====
QAIC creates an accel device per phsyical PCIe device. This accel device exists
for as long as the PCIe device is known to Linux.
The PCIe device may not be in the state to accept requests from userspace at
all times. QAIC will trigger KOBJ_ONLINE/OFFLINE uevents to advertise when the
device can accept requests (ONLINE) and when the device is no longer accepting
requests (OFFLINE) because of a reset or other state transition.
QAIC defines a number of driver specific IOCTLs as part of the userspace API.
This section describes those APIs.
DRM_IOCTL_QAIC_MANAGE
This IOCTL allows userspace to send a NNC request to the QSM. The call will
@@ -178,3 +208,8 @@ overrides this for that call. Default is 5000 (5 seconds).
Sets the polling interval in microseconds (us) when datapath polling is active.
Takes effect at the next polling interval. Default is 100 (100 us).
**timesync_delay_ms (unsigned int)**
Sets the time interval in milliseconds (ms) between two consecutive timesync
operations. Default is 1000 (1000 ms).
Documentation/admin-guide/cgroup-v1/memory.rst
+8
View File
@@ -92,6 +92,13 @@ Brief summary of control files.
memory.oom_control set/show oom controls.
memory.numa_stat show the number of memory usage per numa
node
memory.kmem.limit_in_bytes Deprecated knob to set and read the kernel
memory hard limit. Kernel hard limit is not
supported since 5.16. Writing any value to
do file will not have any effect same as if
nokmem kernel parameter was specified.
Kernel memory is still charged and reported
by memory.kmem.usage_in_bytes.
memory.kmem.usage_in_bytes show current kernel memory allocation
memory.kmem.failcnt show the number of kernel memory usage
hits limits
@@ -544,6 +551,7 @@ memory.stat file includes following statistics:
event happens each time a page is unaccounted from the
cgroup.
swap # of bytes of swap usage
swapcached # of bytes of swap cached in memory
dirty # of bytes that are waiting to get written back to the disk.
writeback # of bytes of file/anon cache that are queued for syncing to
disk.
Documentation/admin-guide/cgroup-v2.rst
+142 -36
View File
@@ -210,6 +210,35 @@ cgroup v2 currently supports the following mount options.
relying on the original semantics (e.g. specifying bogusly
high 'bypass' protection values at higher tree levels).
memory_hugetlb_accounting
Count HugeTLB memory usage towards the cgroup's overall
memory usage for the memory controller (for the purpose of
statistics reporting and memory protetion). This is a new
behavior that could regress existing setups, so it must be
explicitly opted in with this mount option.
A few caveats to keep in mind:
* There is no HugeTLB pool management involved in the memory
controller. The pre-allocated pool does not belong to anyone.
Specifically, when a new HugeTLB folio is allocated to
the pool, it is not accounted for from the perspective of the
memory controller. It is only charged to a cgroup when it is
actually used (for e.g at page fault time). Host memory
overcommit management has to consider this when configuring
hard limits. In general, HugeTLB pool management should be
done via other mechanisms (such as the HugeTLB controller).
* Failure to charge a HugeTLB folio to the memory controller
results in SIGBUS. This could happen even if the HugeTLB pool
still has pages available (but the cgroup limit is hit and
reclaim attempt fails).
* Charging HugeTLB memory towards the memory controller affects
memory protection and reclaim dynamics. Any userspace tuning
(of low, min limits for e.g) needs to take this into account.
* HugeTLB pages utilized while this option is not selected
will not be tracked by the memory controller (even if cgroup
v2 is remounted later on).
Organizing Processes and Threads
--------------------------------
@@ -364,6 +393,13 @@ constraint, a threaded controller must be able to handle competition
between threads in a non-leaf cgroup and its child cgroups. Each
threaded controller defines how such competitions are handled.
Currently, the following controllers are threaded and can be enabled
in a threaded cgroup::
- cpu
- cpuset
- perf_event
- pids
[Un]populated Notification
--------------------------
@@ -1532,6 +1568,15 @@ PAGE_SIZE multiple when read back.
collapsing an existing range of pages. This counter is not
present when CONFIG_TRANSPARENT_HUGEPAGE is not set.
thp_swpout (npn)
Number of transparent hugepages which are swapout in one piece
without splitting.
thp_swpout_fallback (npn)
Number of transparent hugepages which were split before swapout.
Usually because failed to allocate some continuous swap space
for the huge page.
memory.numa_stat
A read-only nested-keyed file which exists on non-root cgroups.
@@ -2023,7 +2068,7 @@ IO Priority
~~~~~~~~~~~
A single attribute controls the behavior of the I/O priority cgroup policy,
namely the blkio.prio.class attribute. The following values are accepted for
namely the io.prio.class attribute. The following values are accepted for
that attribute:
no-change
@@ -2052,9 +2097,11 @@ The following numerical values are associated with the I/O priority policies:
+----------------+---+
| no-change | 0 |
+----------------+---+
| rt-to-be | 2 |
| promote-to-rt | 1 |
+----------------+---+
| all-to-idle | 3 |
| restrict-to-be | 2 |
+----------------+---+
| idle | 3 |
+----------------+---+
The numerical value that corresponds to each I/O priority class is as follows:
@@ -2074,7 +2121,7 @@ The algorithm to set the I/O priority class for a request is as follows:
- If I/O priority class policy is promote-to-rt, change the request I/O
priority class to IOPRIO_CLASS_RT and change the request I/O priority
level to 4.
- If I/O priorityt class is not promote-to-rt, translate the I/O priority
- If I/O priority class policy is not promote-to-rt, translate the I/O priority
class policy into a number, then change the request I/O priority class
into the maximum of the I/O priority class policy number and the numerical
I/O priority class.
@@ -2226,6 +2273,49 @@ Cpuset Interface Files
Its value will be affected by memory nodes hotplug events.
cpuset.cpus.exclusive
A read-write multiple values file which exists on non-root
cpuset-enabled cgroups.
It lists all the exclusive CPUs that are allowed to be used
to create a new cpuset partition. Its value is not used
unless the cgroup becomes a valid partition root. See the
"cpuset.cpus.partition" section below for a description of what
a cpuset partition is.
When the cgroup becomes a partition root, the actual exclusive
CPUs that are allocated to that partition are listed in
"cpuset.cpus.exclusive.effective" which may be different
from "cpuset.cpus.exclusive". If "cpuset.cpus.exclusive"
has previously been set, "cpuset.cpus.exclusive.effective"
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.
For a parent cgroup, any one of its exclusive CPUs can only
be distributed to at most one of its child cgroups. Having an
exclusive CPU appearing in two or more of its child cgroups is
not allowed (the exclusivity rule). A value that violates the
exclusivity rule will be rejected with a write error.
The root cgroup is a partition root and all its available CPUs
are in its exclusive CPU set.
cpuset.cpus.exclusive.effective
A read-only multiple values file which exists on all non-root
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
"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
treated to have an implicit value of "cpuset.cpus" in the
formation of local partition.
cpuset.cpus.partition
A read-write single value file which exists on non-root
cpuset-enabled cgroups. This flag is owned by the parent cgroup
@@ -2239,26 +2329,41 @@ Cpuset Interface Files
"isolated" Partition root without load balancing
========== =====================================
The root cgroup is always a partition root and its state
cannot be changed. All other non-root cgroups start out as
"member".
A cpuset partition is a collection of cpuset-enabled cgroups with
a partition root at the top of the hierarchy and its descendants
except those that are separate partition roots themselves and
their descendants. A partition has exclusive access to the
set of exclusive CPUs allocated to it. Other cgroups outside
of that partition cannot use any CPUs in that set.
There are two types of partitions - local and remote. A local
partition is one whose parent cgroup is also a valid partition
root. A remote partition is one whose parent cgroup is not a
valid partition root itself. Writing to "cpuset.cpus.exclusive"
is optional for the creation of a local partition as its
"cpuset.cpus.exclusive" file will assume an implicit value that
is the same as "cpuset.cpus" if it is not set. Writing the
proper "cpuset.cpus.exclusive" values down the cgroup hierarchy
before the target partition root is mandatory for the creation
of a remote partition.
Currently, a remote partition cannot be created under a local
partition. All the ancestors of a remote partition root except
the root cgroup cannot be a partition root.
The root cgroup is always a partition root and its state cannot
be changed. All other non-root cgroups start out as "member".
When set to "root", the current cgroup is the root of a new
partition or scheduling domain that comprises itself and all
its descendants except those that are separate partition roots
themselves and their descendants.
partition or scheduling domain. The set of exclusive CPUs is
determined by the value of its "cpuset.cpus.exclusive.effective".
When set to "isolated", the CPUs in that partition root will
When set to "isolated", the CPUs in that partition will
be in an isolated state without any load balancing from the
scheduler. Tasks placed in such a partition with multiple
CPUs should be carefully distributed and bound to each of the
individual CPUs for optimal performance.
The value shown in "cpuset.cpus.effective" of a partition root
is the CPUs that the partition root can dedicate to a potential
new child partition root. The new child subtracts available
CPUs from its parent "cpuset.cpus.effective".
A partition root ("root" or "isolated") can be in one of the
two possible states - valid or invalid. An invalid partition
root is in a degraded state where some state information may
@@ -2281,37 +2386,33 @@ Cpuset Interface Files
In the case of an invalid partition root, a descriptive string on
why the partition is invalid is included within parentheses.
For a partition root to become valid, the following conditions
For a local partition root to be valid, the following conditions
must be met.
1) The "cpuset.cpus" is exclusive with its siblings , i.e. they
are not shared by any of its siblings (exclusivity rule).
2) The parent cgroup is a valid partition root.
3) The "cpuset.cpus" is not empty and must contain at least
one of the CPUs from parent's "cpuset.cpus", i.e. they overlap.
4) The "cpuset.cpus.effective" cannot be empty unless there is
1) The parent cgroup is a valid partition root.
2) The "cpuset.cpus.exclusive.effective" file cannot be empty,
though it may contain offline CPUs.
3) The "cpuset.cpus.effective" cannot be empty unless there is
no task associated with this partition.
External events like hotplug or changes to "cpuset.cpus" can
cause a valid partition root to become invalid and vice versa.
Note that a task cannot be moved to a cgroup with empty
"cpuset.cpus.effective".
For a remote partition root to be valid, all the above conditions
except the first one must be met.
For a valid partition root with the sibling cpu exclusivity
rule enabled, changes made to "cpuset.cpus" that violate the
exclusivity rule will invalidate the partition as well as its
sibling partitions with conflicting cpuset.cpus values. So
care must be taking in changing "cpuset.cpus".
External events like hotplug or changes to "cpuset.cpus" or
"cpuset.cpus.exclusive" can cause a valid partition root to
become invalid and vice versa. Note that a task cannot be
moved to a cgroup with empty "cpuset.cpus.effective".
A valid non-root parent partition may distribute out all its CPUs
to its child partitions when there is no task associated with it.
to its child local partitions when there is no task associated
with it.
Care must be taken to change a valid partition root to
"member" as all its child partitions, if present, will become
Care must be taken to change a valid partition root to "member"
as all its child local partitions, if present, will become
invalid causing disruption to tasks running in those child
partitions. These inactivated partitions could be recovered if
their parent is switched back to a partition root with a proper
set of "cpuset.cpus".
value in "cpuset.cpus" or "cpuset.cpus.exclusive".
Poll and inotify events are triggered whenever the state of
"cpuset.cpus.partition" changes. That includes changes caused
@@ -2321,6 +2422,11 @@ Cpuset Interface Files
to "cpuset.cpus.partition" without the need to do continuous
polling.
A user can pre-configure certain CPUs to an isolated state
with load balancing disabled at boot time with the "isolcpus"
kernel boot command line option. If those CPUs are to be put
into a partition, they have to be used in an isolated partition.
Device controller
-----------------
Documentation/admin-guide/dynamic-debug-howto.rst
+1 -1
View File
@@ -259,7 +259,7 @@ Debug Messages at Module Initialization Time
When ``modprobe foo`` is called, modprobe scans ``/proc/cmdline`` for
``foo.params``, strips ``foo.``, and passes them to the kernel along with
params given in modprobe args or ``/etc/modprob.d/*.conf`` files,
params given in modprobe args or ``/etc/modprobe.d/*.conf`` files,
in the following order:
1. parameters given via ``/etc/modprobe.d/*.conf``::
Documentation/admin-guide/efi-stub.rst
+1 -1
View File
@@ -15,7 +15,7 @@ between architectures is in drivers/firmware/efi/libstub.
For arm64, there is no compressed kernel support, so the Image itself
masquerades as a PE/COFF image and the EFI stub is linked into the
kernel. The arm64 EFI stub lives in arch/arm64/kernel/efi-entry.S
kernel. The arm64 EFI stub lives in drivers/firmware/efi/libstub/arm64.c
and drivers/firmware/efi/libstub/arm64-stub.c.
By using the EFI boot stub it's possible to boot a Linux kernel
Documentation/admin-guide/hw-vuln/mds.rst
+12 -20
View File
@@ -102,9 +102,19 @@ The possible values in this file are:
* - 'Vulnerable'
- The processor is vulnerable, but no mitigation enabled
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- The processor is vulnerable but microcode is not updated.
- The processor is vulnerable but microcode is not updated. The
mitigation is enabled on a best effort basis.
The mitigation is enabled on a best effort basis. See :ref:`vmwerv`
If the processor is vulnerable but the availability of the microcode
based mitigation mechanism is not advertised via CPUID, the kernel
selects a best effort mitigation mode. This mode invokes the mitigation
instructions without a guarantee that they clear the CPU buffers.
This is done to address virtualization scenarios where the host has the
microcode update applied, but the hypervisor is not yet updated to
expose the CPUID to the guest. If the host has updated microcode the
protection takes effect; otherwise a few CPU cycles are wasted
pointlessly.
* - 'Mitigation: Clear CPU buffers'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
@@ -119,24 +129,6 @@ to the above information:
'SMT Host state unknown' Kernel runs in a VM, Host SMT state unknown
======================== ============================================
.. _vmwerv:
Best effort mitigation mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^
If the processor is vulnerable, but the availability of the microcode based
mitigation mechanism is not advertised via CPUID the kernel selects a best
effort mitigation mode. This mode invokes the mitigation instructions
without a guarantee that they clear the CPU buffers.
This is done to address virtualization scenarios where the host has the
microcode update applied, but the hypervisor is not yet updated to expose
the CPUID to the guest. If the host has updated microcode the protection
takes effect otherwise a few cpu cycles are wasted pointlessly.
The state in the mds sysfs file reflects this situation accordingly.
Mitigation mechanism
-------------------------
Documentation/admin-guide/hw-vuln/processor_mmio_stale_data.rst
+12 -1
View File
@@ -225,8 +225,19 @@ The possible values in this file are:
* - 'Vulnerable'
- The processor is vulnerable, but no mitigation enabled
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- The processor is vulnerable, but microcode is not updated. The
- The processor is vulnerable but microcode is not updated. The
mitigation is enabled on a best effort basis.
If the processor is vulnerable but the availability of the microcode
based mitigation mechanism is not advertised via CPUID, the kernel
selects a best effort mitigation mode. This mode invokes the mitigation
instructions without a guarantee that they clear the CPU buffers.
This is done to address virtualization scenarios where the host has the
microcode update applied, but the hypervisor is not yet updated to
expose the CPUID to the guest. If the host has updated microcode the
protection takes effect; otherwise a few CPU cycles are wasted
pointlessly.
* - 'Mitigation: Clear CPU buffers'
- The processor is vulnerable and the CPU buffer clearing mitigation is
enabled.
Documentation/admin-guide/hw-vuln/srso.rst
+17 -7
View File
@@ -46,12 +46,22 @@ The possible values in this file are:
The processor is not vulnerable
* 'Vulnerable: no microcode':
* 'Vulnerable':
The processor is vulnerable and no mitigations have been applied.
* 'Vulnerable: No microcode':
The processor is vulnerable, no microcode extending IBPB
functionality to address the vulnerability has been applied.
* 'Mitigation: microcode':
* 'Vulnerable: Safe RET, no microcode':
The "Safe RET" mitigation (see below) has been applied to protect the
kernel, but the IBPB-extending microcode has not been applied. User
space tasks may still be vulnerable.
* 'Vulnerable: Microcode, no safe RET':
Extended IBPB functionality microcode patch has been applied. It does
not address User->Kernel and Guest->Host transitions protection but it
@@ -72,11 +82,11 @@ The possible values in this file are:
(spec_rstack_overflow=microcode)
* 'Mitigation: safe RET':
* 'Mitigation: Safe RET':
Software-only mitigation. It complements the extended IBPB microcode
patch functionality by addressing User->Kernel and Guest->Host
transitions protection.
Combined microcode/software mitigation. It complements the
extended IBPB microcode patch functionality by addressing
User->Kernel and Guest->Host transitions protection.
Selected by default or by spec_rstack_overflow=safe-ret
@@ -129,7 +139,7 @@ an indrect branch prediction barrier after having applied the required
microcode patch for one's system. This mitigation comes also at
a performance cost.
Mitigation: safe RET
Mitigation: Safe RET
--------------------
The mitigation works by ensuring all RET instructions speculate to
Documentation/admin-guide/hw-vuln/tsx_async_abort.rst
+13 -20
View File
@@ -98,7 +98,19 @@ The possible values in this file are:
* - 'Vulnerable'
- The CPU is affected by this vulnerability and the microcode and kernel mitigation are not applied.
* - 'Vulnerable: Clear CPU buffers attempted, no microcode'
- The system tries to clear the buffers but the microcode might not support the operation.
- The processor is vulnerable but microcode is not updated. The
mitigation is enabled on a best effort basis.
If the processor is vulnerable but the availability of the microcode
based mitigation mechanism is not advertised via CPUID, the kernel
selects a best effort mitigation mode. This mode invokes the mitigation
instructions without a guarantee that they clear the CPU buffers.
This is done to address virtualization scenarios where the host has the
microcode update applied, but the hypervisor is not yet updated to
expose the CPUID to the guest. If the host has updated microcode the
protection takes effect; otherwise a few CPU cycles are wasted
pointlessly.
* - 'Mitigation: Clear CPU buffers'
- The microcode has been updated to clear the buffers. TSX is still enabled.
* - 'Mitigation: TSX disabled'
@@ -106,25 +118,6 @@ The possible values in this file are:
* - 'Not affected'
- The CPU is not affected by this issue.
.. _ucode_needed:
Best effort mitigation mode
^^^^^^^^^^^^^^^^^^^^^^^^^^^
If the processor is vulnerable, but the availability of the microcode-based
mitigation mechanism is not advertised via CPUID the kernel selects a best
effort mitigation mode. This mode invokes the mitigation instructions
without a guarantee that they clear the CPU buffers.
This is done to address virtualization scenarios where the host has the
microcode update applied, but the hypervisor is not yet updated to expose the
CPUID to the guest. If the host has updated microcode the protection takes
effect; otherwise a few CPU cycles are wasted pointlessly.
The state in the tsx_async_abort sysfs file reflects this situation
accordingly.
Mitigation mechanism
--------------------
Documentation/admin-guide/kdump/kdump.rst
+3 -34
View File
@@ -17,7 +17,7 @@ You can use common commands, such as cp, scp or makedumpfile to copy
the memory image to a dump file on the local disk, or across the network
to a remote system.
Kdump and kexec are currently supported on the x86, x86_64, ppc64, ia64,
Kdump and kexec are currently supported on the x86, x86_64, ppc64,
s390x, arm and arm64 architectures.
When the system kernel boots, it reserves a small section of memory for
@@ -113,7 +113,7 @@ There are two possible methods of using Kdump.
2) Or use the system kernel binary itself as dump-capture kernel and there is
no need to build a separate dump-capture kernel. This is possible
only with the architectures which support a relocatable kernel. As
of today, i386, x86_64, ppc64, ia64, arm and arm64 architectures support
of today, i386, x86_64, ppc64, arm and arm64 architectures support
relocatable kernel.
Building a relocatable kernel is advantageous from the point of view that
@@ -236,24 +236,6 @@ Dump-capture kernel config options (Arch Dependent, ppc64)
Make and install the kernel and its modules.
Dump-capture kernel config options (Arch Dependent, ia64)
----------------------------------------------------------
- No specific options are required to create a dump-capture kernel
for ia64, other than those specified in the arch independent section
above. This means that it is possible to use the system kernel
as a dump-capture kernel if desired.
The crashkernel region can be automatically placed by the system
kernel at runtime. This is done by specifying the base address as 0,
or omitting it all together::
crashkernel=256M@0
or::
crashkernel=256M
Dump-capture kernel config options (Arch Dependent, arm)
----------------------------------------------------------
@@ -348,11 +330,6 @@ Boot into System Kernel
On ppc64, use "crashkernel=128M@32M".
On ia64, 256M@256M is a generous value that typically works.
The region may be automatically placed on ia64, see the
dump-capture kernel config option notes above.
If use sparse memory, the size should be rounded to GRANULE boundaries.
On s390x, typically use "crashkernel=xxM". The value of xx is dependent
on the memory consumption of the kdump system. In general this is not
dependent on the memory size of the production system.
@@ -383,10 +360,6 @@ For ppc64:
- Use vmlinux
For ia64:
- Use vmlinux or vmlinuz.gz
For s390x:
- Use image or bzImage
@@ -428,14 +401,10 @@ to load dump-capture kernel::
--initrd=<initrd-for-dump-capture-kernel> \
--append="root=<root-dev> <arch-specific-options>"
Please note, that --args-linux does not need to be specified for ia64.
It is planned to make this a no-op on that architecture, but for now
it should be omitted
Following are the arch specific command line options to be used while
loading dump-capture kernel.
For i386, x86_64 and ia64:
For i386 and x86_64:
"1 irqpoll nr_cpus=1 reset_devices"
Documentation/admin-guide/kdump/vmcoreinfo.rst
-30
View File
@@ -413,36 +413,6 @@ of a higher page table lookup overhead, and also consumes more page
table space per process. Used to check whether PAE was enabled in the
crash kernel when converting virtual addresses to physical addresses.
ia64
====
pgdat_list|(pgdat_list, MAX_NUMNODES)
-------------------------------------
pg_data_t array storing all NUMA nodes information. MAX_NUMNODES
indicates the number of the nodes.
node_memblk|(node_memblk, NR_NODE_MEMBLKS)
------------------------------------------
List of node memory chunks. Filled when parsing the SRAT table to obtain
information about memory nodes. NR_NODE_MEMBLKS indicates the number of
node memory chunks.
These values are used to compute the number of nodes the crashed kernel used.
node_memblk_s|(node_memblk_s, start_paddr)|(node_memblk_s, size)
----------------------------------------------------------------
The size of a struct node_memblk_s and the offsets of the
node_memblk_s's members. Used to compute the number of nodes.
PGTABLE_3|PGTABLE_4
-------------------
User-space tools need to know whether the crash kernel was in 3-level or
4-level paging mode. Used to distinguish the page table.
ARM64
=====
Documentation/admin-guide/kernel-parameters.txt
+105 -14
View File
@@ -580,6 +580,10 @@
named mounts. Specifying both "all" and "named" disables
all v1 hierarchies.
cgroup_favordynmods= [KNL] Enable or Disable favordynmods.
Format: { "true" | "false" }
Defaults to the value of CONFIG_CGROUP_FAVOR_DYNMODS.
cgroup.memory= [KNL] Pass options to the cgroup memory controller.
Format: <string>
nosocket -- Disable socket memory accounting.
@@ -1331,6 +1335,7 @@
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial[,force],bus:device.function[,baudrate]
earlyprintk=xdbc[xhciController#]
earlyprintk=bios
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
@@ -1361,6 +1366,8 @@
The sclp output can only be used on s390.
The bios output can only be used on SuperH.
The optional "force" to "pciserial" enables use of a
PCI device even when its classcode is not of the
UART class.
@@ -1449,7 +1456,7 @@
See comment before function elanfreq_setup() in
arch/x86/kernel/cpu/cpufreq/elanfreq.c.
elfcorehdr=[size[KMG]@]offset[KMG] [IA64,PPC,SH,X86,S390]
elfcorehdr=[size[KMG]@]offset[KMG] [PPC,SH,X86,S390]
Specifies physical address of start of kernel core
image elf header and optionally the size. Generally
kexec loader will pass this option to capture kernel.
@@ -1512,12 +1519,6 @@
floppy= [HW]
See Documentation/admin-guide/blockdev/floppy.rst.
force_pal_cache_flush
[IA-64] Avoid check_sal_cache_flush which may hang on
buggy SAL_CACHE_FLUSH implementations. Using this
parameter will force ia64_sal_cache_flush to call
ia64_pal_cache_flush instead of SAL_CACHE_FLUSH.
forcepae [X86-32]
Forcefully enable Physical Address Extension (PAE).
Many Pentium M systems disable PAE but may have a
@@ -1893,6 +1894,12 @@
0 -- machine default
1 -- force brightness inversion
ia32_emulation= [X86-64]
Format: <bool>
When true, allows loading 32-bit programs and executing 32-bit
syscalls, essentially overriding IA32_EMULATION_DEFAULT_DISABLED at
boot time. When false, unconditionally disables IA32 emulation.
icn= [HW,ISDN]
Format: <io>[,<membase>[,<icn_id>[,<icn_id2>]]]
@@ -2220,7 +2227,7 @@
forcing Dual Address Cycle for PCI cards supporting
greater than 32-bit addressing.
iommu.strict= [ARM64, X86] Configure TLB invalidation behaviour
iommu.strict= [ARM64, X86, S390] Configure TLB invalidation behaviour
Format: { "0" | "1" }
0 - Lazy mode.
Request that DMA unmap operations use deferred
@@ -2913,6 +2920,38 @@
to extract confidential information from the kernel
are also disabled.
locktorture.acq_writer_lim= [KNL]
Set the time limit in jiffies for a lock
acquisition. Acquisitions exceeding this limit
will result in a splat once they do complete.
locktorture.bind_readers= [KNL]
Specify the list of CPUs to which the readers are
to be bound.
locktorture.bind_writers= [KNL]
Specify the list of CPUs to which the writers are
to be bound.
locktorture.call_rcu_chains= [KNL]
Specify the number of self-propagating call_rcu()
chains to set up. These are used to ensure that
there is a high probability of an RCU grace period
in progress at any given time. Defaults to 0,
which disables these call_rcu() chains.
locktorture.long_hold= [KNL]
Specify the duration in milliseconds for the
occasional long-duration lock hold time. Defaults
to 100 milliseconds. Select 0 to disable.
locktorture.nested_locks= [KNL]
Specify the maximum lock nesting depth that
locktorture is to exercise, up to a limit of 8
(MAX_NESTED_LOCKS). Specify zero to disable.
Note that this parameter is ineffective on types
of locks that do not support nested acquisition.
locktorture.nreaders_stress= [KNL]
Set the number of locking read-acquisition kthreads.
Defaults to being automatically set based on the
@@ -2928,6 +2967,25 @@
Set time (s) between CPU-hotplug operations, or
zero to disable CPU-hotplug testing.
locktorture.rt_boost= [KNL]
Do periodic testing of real-time lock priority
boosting. Select 0 to disable, 1 to boost
only rt_mutex, and 2 to boost unconditionally.
Defaults to 2, which might seem to be an
odd choice, but which should be harmless for
non-real-time spinlocks, due to their disabling
of preemption. Note that non-realtime mutexes
disable boosting.
locktorture.rt_boost_factor= [KNL]
Number that determines how often and for how
long priority boosting is exercised. This is
scaled down by the number of writers, so that the
number of boosts per unit time remains roughly
constant as the number of writers increases.
On the other hand, the duration of each boost
increases with the number of writers.
locktorture.shuffle_interval= [KNL]
Set task-shuffle interval (jiffies). Shuffling
tasks allows some CPUs to go into dyntick-idle
@@ -2950,13 +3008,13 @@
locktorture.torture_type= [KNL]
Specify the locking implementation to test.
locktorture.verbose= [KNL]
Enable additional printk() statements.
locktorture.writer_fifo= [KNL]
Run the write-side locktorture kthreads at
sched_set_fifo() real-time priority.
locktorture.verbose= [KNL]
Enable additional printk() statements.
logibm.irq= [HW,MOUSE] Logitech Bus Mouse Driver
Format: <irq>
@@ -3275,6 +3333,11 @@
mga= [HW,DRM]
microcode.force_minrev= [X86]
Format: <bool>
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.
@@ -3533,6 +3596,13 @@
[NFS] set the TCP port on which the NFSv4 callback
channel should listen.
nfs.delay_retrans=
[NFS] specifies the number of times the NFSv4 client
retries the request before returning an EAGAIN error,
after a reply of NFS4ERR_DELAY from the server.
Only applies if the softerr mount option is enabled,
and the specified value is >= 0.
nfs.enable_ino64=
[NFS] enable 64-bit inode numbers.
If zero, the NFS client will fake up a 32-bit inode
@@ -4769,6 +4839,13 @@
Set maximum number of finished RCU callbacks to
process in one batch.
rcutree.do_rcu_barrier= [KNL]
Request a call to rcu_barrier(). This is
throttled so that userspace tests can safely
hammer on the sysfs variable if they so choose.
If triggered before the RCU grace-period machinery
is fully active, this will error out with EAGAIN.
rcutree.dump_tree= [KNL]
Dump the structure of the rcu_node combining tree
out at early boot. This is used for diagnostic
@@ -5422,6 +5499,12 @@
test until boot completes in order to avoid
interference.
refscale.lookup_instances= [KNL]
Number of data elements to use for the forms of
SLAB_TYPESAFE_BY_RCU testing. A negative number
is negated and multiplied by nr_cpu_ids, while
zero specifies nr_cpu_ids.
refscale.loops= [KNL]
Set the number of loops over the synchronization
primitive under test. Increasing this number
@@ -5611,9 +5694,10 @@
s390_iommu= [HW,S390]
Set s390 IOTLB flushing mode
strict
With strict flushing every unmap operation will result in
an IOTLB flush. Default is lazy flushing before reuse,
which is faster.
With strict flushing every unmap operation will result
in an IOTLB flush. Default is lazy flushing before
reuse, which is faster. Deprecated, equivalent to
iommu.strict=1.
s390_iommu_aperture= [KNL,S390]
Specifies the size of the per device DMA address space
@@ -5858,6 +5942,13 @@
This feature may be more efficiently disabled
using the csdlock_debug- kernel parameter.
smp.panic_on_ipistall= [KNL]
If a csd_lock_timeout extends for more than
the specified number of milliseconds, panic the
system. By default, let CSD-lock acquisition
take as long as they take. Specifying 300,000
for this value provides a 5-minute timeout.
smsc-ircc2.nopnp [HW] Don't use PNP to discover SMC devices
smsc-ircc2.ircc_cfg= [HW] Device configuration I/O port
smsc-ircc2.ircc_sir= [HW] SIR base I/O port
Documentation/admin-guide/laptops/thinkpad-acpi.rst
+20
View File
@@ -53,6 +53,7 @@ detailed description):
- Lap mode sensor
- Setting keyboard language
- WWAN Antenna type
- Auxmac
A compatibility table by model and feature is maintained on the web
site, http://ibm-acpi.sf.net/. I appreciate any success or failure
@@ -1511,6 +1512,25 @@ Currently 2 antenna types are supported as mentioned below:
The property is read-only. If the platform doesn't have support the sysfs
class is not created.
Auxmac
------
sysfs: auxmac
Some newer Thinkpads have a feature called MAC Address Pass-through. This
feature is implemented by the system firmware to provide a system unique MAC,
that can override a dock or USB ethernet dongle MAC, when connected to a
network. This property enables user-space to easily determine the MAC address
if the feature is enabled.
The values of this auxiliary MAC are:
cat /sys/devices/platform/thinkpad_acpi/auxmac
If the feature is disabled, the value will be 'disabled'.
This property is read-only.
Adaptive keyboard
-----------------
Documentation/admin-guide/media/mgb4.rst
+374
View File
@@ -0,0 +1,374 @@
.. SPDX-License-Identifier: GPL-2.0
====================
mgb4 sysfs interface
====================
The mgb4 driver provides a sysfs interface, that is used to configure video
stream related parameters (some of them must be set properly before the v4l2
device can be opened) and obtain the video device/stream status.
There are two types of parameters - global / PCI card related, found under
``/sys/class/video4linux/videoX/device`` and module specific found under
``/sys/class/video4linux/videoX``.
Global (PCI card) parameters
============================
**module_type** (R):
Module type.
| 0 - No module present
| 1 - FPDL3
| 2 - GMSL
**module_version** (R):
Module version number. Zero in case of a missing module.
**fw_type** (R):
Firmware type.
| 1 - FPDL3
| 2 - GMSL
**fw_version** (R):
Firmware version number.
**serial_number** (R):
Card serial number. The format is::
PRODUCT-REVISION-SERIES-SERIAL
where each component is a 8b number.
Common FPDL3/GMSL input parameters
==================================
**input_id** (R):
Input number ID, zero based.
**oldi_lane_width** (RW):
Number of deserializer output lanes.
| 0 - single
| 1 - dual (default)
**color_mapping** (RW):
Mapping of the incoming bits in the signal to the colour bits of the pixels.
| 0 - OLDI/JEIDA
| 1 - SPWG/VESA (default)
**link_status** (R):
Video link status. If the link is locked, chips are properly connected and
communicating at the same speed and protocol. The link can be locked without
an active video stream.
A value of 0 is equivalent to the V4L2_IN_ST_NO_SYNC flag of the V4L2
VIDIOC_ENUMINPUT status bits.
| 0 - unlocked
| 1 - locked
**stream_status** (R):
Video stream status. A stream is detected if the link is locked, the input
pixel clock is running and the DE signal is moving.
A value of 0 is equivalent to the V4L2_IN_ST_NO_SIGNAL flag of the V4L2
VIDIOC_ENUMINPUT status bits.
| 0 - not detected
| 1 - detected
**video_width** (R):
Video stream width. This is the actual width as detected by the HW.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the width
field of the v4l2_bt_timings struct.
**video_height** (R):
Video stream height. This is the actual height as detected by the HW.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the height
field of the v4l2_bt_timings struct.
**vsync_status** (R):
The type of VSYNC pulses as detected by the video format detector.
The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
the polarities field of the v4l2_bt_timings struct.
| 0 - active low
| 1 - active high
| 2 - not available
**hsync_status** (R):
The type of HSYNC pulses as detected by the video format detector.
The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
the polarities field of the v4l2_bt_timings struct.
| 0 - active low
| 1 - active high
| 2 - not available
**vsync_gap_length** (RW):
If the incoming video signal does not contain synchronization VSYNC and
HSYNC pulses, these must be generated internally in the FPGA to achieve
the correct frame ordering. This value indicates, how many "empty" pixels
(pixels with deasserted Data Enable signal) are necessary to generate the
internal VSYNC pulse.
**hsync_gap_length** (RW):
If the incoming video signal does not contain synchronization VSYNC and
HSYNC pulses, these must be generated internally in the FPGA to achieve
the correct frame ordering. This value indicates, how many "empty" pixels
(pixels with deasserted Data Enable signal) are necessary to generate the
internal HSYNC pulse. The value must be greater than 1 and smaller than
vsync_gap_length.
**pclk_frequency** (R):
Input pixel clock frequency in kHz.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the pixelclock field of the v4l2_bt_timings struct.
*Note: The frequency_range parameter must be set properly first to get
a valid frequency here.*
**hsync_width** (R):
Width of the HSYNC signal in PCLK clock ticks.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the hsync field of the v4l2_bt_timings struct.
**vsync_width** (R):
Width of the VSYNC signal in PCLK clock ticks.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the vsync field of the v4l2_bt_timings struct.
**hback_porch** (R):
Number of PCLK pulses between deassertion of the HSYNC signal and the first
valid pixel in the video line (marked by DE=1).
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the hbackporch field of the v4l2_bt_timings struct.
**hfront_porch** (R):
Number of PCLK pulses between the end of the last valid pixel in the video
line (marked by DE=1) and assertion of the HSYNC signal.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the hfrontporch field of the v4l2_bt_timings struct.
**vback_porch** (R):
Number of video lines between deassertion of the VSYNC signal and the video
line with the first valid pixel (marked by DE=1).
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the vbackporch field of the v4l2_bt_timings struct.
**vfront_porch** (R):
Number of video lines between the end of the last valid pixel line (marked
by DE=1) and assertion of the VSYNC signal.
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
the vfrontporch field of the v4l2_bt_timings struct.
**frequency_range** (RW)
PLL frequency range of the OLDI input clock generator. The PLL frequency is
derived from the Pixel Clock Frequency (PCLK) and is equal to PCLK if
oldi_lane_width is set to "single" and PCLK/2 if oldi_lane_width is set to
"dual".
| 0 - PLL < 50MHz (default)
| 1 - PLL >= 50MHz
*Note: This parameter can not be changed while the input v4l2 device is
open.*
Common FPDL3/GMSL output parameters
===================================
**output_id** (R):
Output number ID, zero based.
**video_source** (RW):
Output video source. If set to 0 or 1, the source is the corresponding card
input and the v4l2 output devices are disabled. If set to 2 or 3, the source
is the corresponding v4l2 video output device. The default is
the corresponding v4l2 output, i.e. 2 for OUT1 and 3 for OUT2.
| 0 - input 0
| 1 - input 1
| 2 - v4l2 output 0
| 3 - v4l2 output 1
*Note: This parameter can not be changed while ANY of the input/output v4l2
devices is open.*
**display_width** (RW):
Display width. There is no autodetection of the connected display, so the
proper value must be set before the start of streaming. The default width
is 1280.
*Note: This parameter can not be changed while the output v4l2 device is
open.*
**display_height** (RW):
Display height. There is no autodetection of the connected display, so the
proper value must be set before the start of streaming. The default height
is 640.
*Note: This parameter can not be changed while the output v4l2 device is
open.*
**frame_rate** (RW):
Output video frame rate in frames per second. The default frame rate is
60Hz.
**hsync_polarity** (RW):
HSYNC signal polarity.
| 0 - active low (default)
| 1 - active high
**vsync_polarity** (RW):
VSYNC signal polarity.
| 0 - active low (default)
| 1 - active high
**de_polarity** (RW):
DE signal polarity.
| 0 - active low
| 1 - active high (default)
**pclk_frequency** (RW):
Output pixel clock frequency. Allowed values are between 25000-190000(kHz)
and there is a non-linear stepping between two consecutive allowed
frequencies. The driver finds the nearest allowed frequency to the given
value and sets it. When reading this property, you get the exact
frequency set by the driver. The default frequency is 70000kHz.
*Note: This parameter can not be changed while the output v4l2 device is
open.*
**hsync_width** (RW):
Width of the HSYNC signal in pixels. The default value is 16.
**vsync_width** (RW):
Width of the VSYNC signal in video lines. The default value is 2.
**hback_porch** (RW):
Number of PCLK pulses between deassertion of the HSYNC signal and the first
valid pixel in the video line (marked by DE=1). The default value is 32.
**hfront_porch** (RW):
Number of PCLK pulses between the end of the last valid pixel in the video
line (marked by DE=1) and assertion of the HSYNC signal. The default value
is 32.
**vback_porch** (RW):
Number of video lines between deassertion of the VSYNC signal and the video
line with the first valid pixel (marked by DE=1). The default value is 2.
**vfront_porch** (RW):
Number of video lines between the end of the last valid pixel line (marked
by DE=1) and assertion of the VSYNC signal. The default value is 2.
FPDL3 specific input parameters
===============================
**fpdl3_input_width** (RW):
Number of deserializer input lines.
| 0 - auto (default)
| 1 - single
| 2 - dual
FPDL3 specific output parameters
================================
**fpdl3_output_width** (RW):
Number of serializer output lines.
| 0 - auto (default)
| 1 - single
| 2 - dual
GMSL specific input parameters
==============================
**gmsl_mode** (RW):
GMSL speed mode.
| 0 - 12Gb/s (default)
| 1 - 6Gb/s
| 2 - 3Gb/s
| 3 - 1.5Gb/s
**gmsl_stream_id** (RW):
The GMSL multi-stream contains up to four video streams. This parameter
selects which stream is captured by the video input. The value is the
zero-based index of the stream. The default stream id is 0.
*Note: This parameter can not be changed while the input v4l2 device is
open.*
**gmsl_fec** (RW):
GMSL Forward Error Correction (FEC).
| 0 - disabled
| 1 - enabled (default)
====================
mgb4 mtd partitions
====================
The mgb4 driver creates a MTD device with two partitions:
- mgb4-fw.X - FPGA firmware.
- mgb4-data.X - Factory settings, e.g. card serial number.
The *mgb4-fw* partition is writable and is used for FW updates, *mgb4-data* is
read-only. The *X* attached to the partition name represents the card number.
Depending on the CONFIG_MTD_PARTITIONED_MASTER kernel configuration, you may
also have a third partition named *mgb4-flash* available in the system. This
partition represents the whole, unpartitioned, card's FLASH memory and one should
not fiddle with it...
====================
mgb4 iio (triggers)
====================
The mgb4 driver creates an Industrial I/O (IIO) device that provides trigger and
signal level status capability. The following scan elements are available:
**activity**:
The trigger levels and pending status.
| bit 1 - trigger 1 pending
| bit 2 - trigger 2 pending
| bit 5 - trigger 1 level
| bit 6 - trigger 2 level
**timestamp**:
The trigger event timestamp.
The iio device can operate either in "raw" mode where you can fetch the signal
levels (activity bits 5 and 6) using sysfs access or in triggered buffer mode.
In the triggered buffer mode you can follow the signal level changes (activity
bits 1 and 2) using the iio device in /dev. If you enable the timestamps, you
will also get the exact trigger event time that can be matched to a video frame
(every mgb4 video frame has a timestamp with the same clock source).
*Note: although the activity sample always contains all the status bits, it makes
no sense to get the pending bits in raw mode or the level bits in the triggered
buffer mode - the values do not represent valid data in such case.*
Documentation/admin-guide/media/pci-cardlist.rst
+1
View File
@@ -77,6 +77,7 @@ ipu3-cio2 Intel ipu3-cio2 driver
ivtv Conexant cx23416/cx23415 MPEG encoder/decoder
ivtvfb Conexant cx23415 framebuffer
mantis MANTIS based cards
mgb4 Digiteq Automotive MGB4 frame grabber
mxb Siemens-Nixdorf 'Multimedia eXtension Board'
netup-unidvb NetUP Universal DVB card
ngene Micronas nGene
Documentation/admin-guide/media/v4l-drivers.rst
+1
View File
@@ -17,6 +17,7 @@ Video4Linux (V4L) driver-specific documentation
imx7
ipu3
ivtv
mgb4
omap3isp
omap4_camera
philips
Documentation/admin-guide/media/visl.rst
+3 -3
View File
@@ -78,7 +78,7 @@ The trace events are defined on a per-codec basis, e.g.:
.. code-block:: bash
$ ls /sys/kernel/debug/tracing/events/ | grep visl
$ ls /sys/kernel/tracing/events/ | grep visl
visl_fwht_controls
visl_h264_controls
visl_hevc_controls
@@ -90,13 +90,13 @@ For example, in order to dump HEVC SPS data:
.. code-block:: bash
$ echo 1 > /sys/kernel/debug/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
$ echo 1 > /sys/kernel/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
The SPS data will be dumped to the trace buffer, i.e.:
.. code-block:: bash
$ cat /sys/kernel/debug/tracing/trace
$ cat /sys/kernel/tracing/trace
video_parameter_set_id 0
seq_parameter_set_id 0
pic_width_in_luma_samples 1920
Documentation/admin-guide/mm/damon/usage.rst
+81 -43
View File
@@ -20,18 +20,18 @@ DAMON provides below interfaces for different users.
you can write and use your personalized DAMON sysfs wrapper programs that
reads/writes the sysfs files instead of you. The `DAMON user space tool
<https://github.com/awslabs/damo>`_ is one example of such programs.
- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
<sysfs_interface>`. This is deprecated, so users should move to the
:ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
move, please report your usecase to damon@lists.linux.dev and
linux-mm@kvack.org.
- *Kernel Space Programming Interface.*
:doc:`This </mm/damon/api>` is for kernel space programmers. Using this,
users can utilize every feature of DAMON most flexibly and efficiently by
writing kernel space DAMON application programs for you. You can even extend
DAMON for various address spaces. For detail, please refer to the interface
:doc:`document </mm/damon/api>`.
- *debugfs interface. (DEPRECATED!)*
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
<sysfs_interface>`. This is deprecated, so users should move to the
:ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
move, please report your usecase to damon@lists.linux.dev and
linux-mm@kvack.org.
.. _sysfs_interface:
@@ -76,7 +76,7 @@ comma (","). ::
│ │ │ │ │ │ │ │ ...
│ │ │ │ │ │ ...
│ │ │ │ │ schemes/nr_schemes
│ │ │ │ │ │ 0/action
│ │ │ │ │ │ 0/action,apply_interval_us
│ │ │ │ │ │ │ access_pattern/
│ │ │ │ │ │ │ │ sz/min,max
│ │ │ │ │ │ │ │ nr_accesses/min,max
@@ -105,14 +105,12 @@ having the root permission could use this directory.
kdamonds/
---------
The monitoring-related information including request specifications and results
are called DAMON context. DAMON executes each context with a kernel thread
called kdamond, and multiple kdamonds could run in parallel.
Under the ``admin`` directory, one directory, ``kdamonds``, which has files for
controlling the kdamonds exist. In the beginning, this directory has only one
file, ``nr_kdamonds``. Writing a number (``N``) to the file creates the number
of child directories named ``0`` to ``N-1``. Each directory represents each
controlling the kdamonds (refer to
:ref:`design <damon_design_execution_model_and_data_structures>` for more
details) exists. In the beginning, this directory has only one file,
``nr_kdamonds``. Writing a number (``N``) to the file creates the number of
child directories named ``0`` to ``N-1``. Each directory represents each
kdamond.
kdamonds/<N>/
@@ -150,9 +148,10 @@ kdamonds/<N>/contexts/
In the beginning, this directory has only one file, ``nr_contexts``. Writing a
number (``N``) to the file creates the number of child directories named as
``0`` to ``N-1``. Each directory represents each monitoring context. At the
moment, only one context per kdamond is supported, so only ``0`` or ``1`` can
be written to the file.
``0`` to ``N-1``. Each directory represents each monitoring context (refer to
:ref:`design <damon_design_execution_model_and_data_structures>` for more
details). At the moment, only one context per kdamond is supported, so only
``0`` or ``1`` can be written to the file.
.. _sysfs_contexts:
@@ -270,8 +269,8 @@ schemes/<N>/
------------
In each scheme directory, five directories (``access_pattern``, ``quotas``,
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and one file
(``action``) exist.
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and two files
(``action`` 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
@@ -297,6 +296,9 @@ Note that support of each action depends on the running DAMON operations set
- ``stat``: Do nothing but count the statistics.
Supported by all operations sets.
The ``apply_interval_us`` file is for setting and getting the scheme's
:ref:`apply_interval <damon_design_damos>` in microseconds.
schemes/<N>/access_pattern/
---------------------------
@@ -392,7 +394,7 @@ pages of all memory cgroups except ``/having_care_already``.::
echo N > 1/matching
Note that ``anon`` and ``memcg`` filters are currently supported only when
``paddr`` `implementation <sysfs_contexts>` is being used.
``paddr`` :ref:`implementation <sysfs_contexts>` is being used.
Also, memory regions that are filtered out by ``addr`` or ``target`` filters
are not counted as the scheme has tried to those, while regions that filtered
@@ -430,9 +432,9 @@ that reading it returns the total size of the scheme tried regions, and creates
directories named integer starting from ``0`` under this directory. Each
directory contains files exposing detailed information about each of the memory
region that the corresponding scheme's ``action`` has tried to be applied under
this directory, during next :ref:`aggregation interval
<sysfs_monitoring_attrs>`. The information includes address range,
``nr_accesses``, and ``age`` of the region.
this directory, during next :ref:`apply interval <damon_design_damos>` of the
corresponding scheme. The information includes address range, ``nr_accesses``,
and ``age`` of the region.
Writing ``update_schemes_tried_bytes`` to the relevant ``kdamonds/<N>/state``
file will only update the ``total_bytes`` file, and will not create the
@@ -495,6 +497,62 @@ Please note that it's highly recommended to use user space tools like `damo
<https://github.com/awslabs/damo>`_ rather than manually reading and writing
the files as above. Above is only for an example.
.. _tracepoint:
Tracepoints for Monitoring Results
==================================
Users can get the monitoring results via the :ref:`tried_regions
<sysfs_schemes_tried_regions>`. The interface is useful for getting a
snapshot, but it could be inefficient for fully recording all the monitoring
results. For the purpose, two trace points, namely ``damon:damon_aggregated``
and ``damon:damos_before_apply``, are provided. ``damon:damon_aggregated``
provides the whole monitoring results, while ``damon:damos_before_apply``
provides the monitoring results for regions that each DAMON-based Operation
Scheme (:ref:`DAMOS <damon_design_damos>`) is gonna be applied. Hence,
``damon:damos_before_apply`` is more useful for recording internal behavior of
DAMOS, or DAMOS target access
:ref:`pattern <damon_design_damos_access_pattern>` based query-like efficient
monitoring results recording.
While the monitoring is turned on, you could record the tracepoint events and
show results using tracepoint supporting tools like ``perf``. For example::
# echo on > monitor_on
# perf record -e damon:damon_aggregated &
# sleep 5
# kill 9 $(pidof perf)
# echo off > monitor_on
# perf script
kdamond.0 46568 [027] 79357.842179: damon:damon_aggregated: target_id=0 nr_regions=11 122509119488-135708762112: 0 864
[...]
Each line of the perf script output represents each monitoring region. The
first five fields are as usual other tracepoint outputs. The sixth field
(``target_id=X``) shows the ide of the monitoring target of the region. The
seventh field (``nr_regions=X``) shows the total number of monitoring regions
for the target. The eighth field (``X-Y:``) shows the start (``X``) and end
(``Y``) addresses of the region in bytes. The ninth field (``X``) shows the
``nr_accesses`` of the region (refer to
:ref:`design <damon_design_region_based_sampling>` for more details of the
counter). Finally the tenth field (``X``) shows the ``age`` of the region
(refer to :ref:`design <damon_design_age_tracking>` for more details of the
counter).
If the event was ``damon:damos_beofre_apply``, the ``perf script`` output would
be somewhat like below::
kdamond.0 47293 [000] 80801.060214: damon:damos_before_apply: ctx_idx=0 scheme_idx=0 target_idx=0 nr_regions=11 121932607488-135128711168: 0 136
[...]
Each line of the output represents each monitoring region that each DAMON-based
Operation Scheme was about to be applied at the traced time. The first five
fields are as usual. It shows the index of the DAMON context (``ctx_idx=X``)
of the scheme in the list of the contexts of the context's kdamond, the index
of the scheme (``scheme_idx=X``) in the list of the schemes of the context, in
addition to the output of ``damon_aggregated`` tracepoint.
.. _debugfs_interface:
debugfs Interface (DEPRECATED!)
@@ -790,23 +848,3 @@ directory by putting the name of the context to the ``rm_contexts`` file. ::
Note that ``mk_contexts``, ``rm_contexts``, and ``monitor_on`` files are in the
root directory only.
.. _tracepoint:
Tracepoint for Monitoring Results
=================================
Users can get the monitoring results via the :ref:`tried_regions
<sysfs_schemes_tried_regions>` or a tracepoint, ``damon:damon_aggregated``.
While the tried regions directory is useful for getting a snapshot, the
tracepoint is useful for getting a full record of the results. While the
monitoring is turned on, you could record the tracepoint events and show
results using tracepoint supporting tools like ``perf``. For example::
# echo on > monitor_on
# perf record -e damon:damon_aggregated &
# sleep 5
# kill 9 $(pidof perf)
# echo off > monitor_on
# perf script
Documentation/admin-guide/mm/ksm.rst
+11
View File
@@ -155,6 +155,15 @@ stable_node_chains_prune_millisecs
scan. It's a noop if not a single KSM page hit the
``max_page_sharing`` yet.
smart_scan
Historically KSM checked every candidate page for each scan. It did
not take into account historic information. When smart scan is
enabled, pages that have previously not been de-duplicated get
skipped. How often these pages are skipped depends on how often
de-duplication has already been tried and failed. By default this
optimization is enabled. The ``pages_skipped`` metric shows how
effective the setting is.
The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
general_profit
@@ -169,6 +178,8 @@ pages_unshared
how many pages unique but repeatedly checked for merging
pages_volatile
how many pages changing too fast to be placed in a tree
pages_skipped
how many pages did the "smart" page scanning algorithm skip
full_scans
how many times all mergeable areas have been scanned
stable_node_chains
Documentation/admin-guide/mm/memory-hotplug.rst
+6 -6
View File
@@ -33,7 +33,7 @@ used to expose persistent memory, other performance-differentiated memory and
reserved memory regions as ordinary system RAM to Linux.
Linux only supports memory hot(un)plug on selected 64 bit architectures, such as
x86_64, arm64, ppc64, s390x and ia64.
x86_64, arm64, ppc64 and s390x.
Memory Hot(Un)Plug Granularity
------------------------------
@@ -75,7 +75,7 @@ Memory hotunplug consists of two phases:
(1) Offlining memory blocks
(2) Removing the memory from Linux
In the fist phase, memory is "hidden" from the page allocator again, for
In the first phase, memory is "hidden" from the page allocator again, for
example, by migrating busy memory to other memory locations and removing all
relevant free pages from the page allocator After this phase, the memory is no
longer visible in memory statistics of the system.
@@ -250,15 +250,15 @@ Observing the State of Memory Blocks
The state (online/offline/going-offline) of a memory block can be observed
either via::
% cat /sys/device/system/memory/memoryXXX/state
% cat /sys/devices/system/memory/memoryXXX/state
Or alternatively (1/0) via::
% cat /sys/device/system/memory/memoryXXX/online
% cat /sys/devices/system/memory/memoryXXX/online
For an online memory block, the managing zone can be observed via::
% cat /sys/device/system/memory/memoryXXX/valid_zones
% cat /sys/devices/system/memory/memoryXXX/valid_zones
Configuring Memory Hot(Un)Plug
==============================
@@ -326,7 +326,7 @@ however, a memory block might span memory holes. A memory block spanning memory
holes cannot be offlined.
For example, assume 1 GiB memory block size. A device for a memory starting at
0x100000000 is ``/sys/device/system/memory/memory4``::
0x100000000 is ``/sys/devices/system/memory/memory4``::
(0x100000000 / 1Gib = 4)
Documentation/admin-guide/mm/pagemap.rst
+89
View File
@@ -227,3 +227,92 @@ Before Linux 3.11 pagemap bits 55-60 were used for "page-shift" (which is
always 12 at most architectures). Since Linux 3.11 their meaning changes
after first clear of soft-dirty bits. Since Linux 4.2 they are used for
flags unconditionally.
Pagemap Scan IOCTL
==================
The ``PAGEMAP_SCAN`` IOCTL on the pagemap file can be used to get or optionally
clear the info about page table entries. The following operations are supported
in this IOCTL:
- Scan the address range and get the memory ranges matching the provided criteria.
This is performed when the output buffer is specified.
- Write-protect the pages. The ``PM_SCAN_WP_MATCHING`` is used to write-protect
the pages of interest. The ``PM_SCAN_CHECK_WPASYNC`` aborts the operation if
non-Async Write Protected pages are found. The ``PM_SCAN_WP_MATCHING`` can be
used with or without ``PM_SCAN_CHECK_WPASYNC``.
- Both of those operations can be combined into one atomic operation where we can
get and write protect the pages as well.
Following flags about pages are currently supported:
- ``PAGE_IS_WPALLOWED`` - Page has async-write-protection enabled
- ``PAGE_IS_WRITTEN`` - Page has been written to from the time it was write protected
- ``PAGE_IS_FILE`` - Page is file backed
- ``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
The ``struct pm_scan_arg`` is used as the argument of the IOCTL.
1. The size of the ``struct pm_scan_arg`` must be specified in the ``size``
field. This field will be helpful in recognizing the structure if extensions
are done later.
2. The flags can be specified in the ``flags`` field. The ``PM_SCAN_WP_MATCHING``
and ``PM_SCAN_CHECK_WPASYNC`` are the only added flags at this time. The get
operation is optionally performed depending upon if the output buffer is
provided or not.
3. The range is specified through ``start`` and ``end``.
4. The walk can abort before visiting the complete range such as the user buffer
can get full etc. The walk ending address is specified in``end_walk``.
5. The output buffer of ``struct page_region`` array and size is specified in
``vec`` and ``vec_len``.
6. The optional maximum requested pages are specified in the ``max_pages``.
7. The masks are specified in ``category_mask``, ``category_anyof_mask``,
``category_inverted`` and ``return_mask``.
Find pages which have been written and WP them as well::
struct pm_scan_arg arg = {
.size = sizeof(arg),
.flags = PM_SCAN_CHECK_WPASYNC | PM_SCAN_CHECK_WPASYNC,
..
.category_mask = PAGE_IS_WRITTEN,
.return_mask = PAGE_IS_WRITTEN,
};
Find pages which have been written, are file backed, not swapped and either
present or huge::
struct pm_scan_arg arg = {
.size = sizeof(arg),
.flags = 0,
..
.category_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED,
.category_inverted = PAGE_IS_SWAPPED,
.category_anyof_mask = PAGE_IS_PRESENT | PAGE_IS_HUGE,
.return_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED |
PAGE_IS_PRESENT | PAGE_IS_HUGE,
};
The ``PAGE_IS_WRITTEN`` flag can be considered as a better-performing alternative
of soft-dirty flag. It doesn't get affected by VMA merging of the kernel and hence
the user can find the true soft-dirty pages in case of normal pages. (There may
still be extra dirty pages reported for THP or Hugetlb pages.)
"PAGE_IS_WRITTEN" category is used with uffd write protect-enabled ranges to
implement memory dirty tracking in userspace:
1. The userfaultfd file descriptor is created with ``userfaultfd`` syscall.
2. The ``UFFD_FEATURE_WP_UNPOPULATED`` and ``UFFD_FEATURE_WP_ASYNC`` features
are set by ``UFFDIO_API`` IOCTL.
3. The memory range is registered with ``UFFDIO_REGISTER_MODE_WP`` mode
through ``UFFDIO_REGISTER`` IOCTL.
4. Then any part of the registered memory or the whole memory region must
be write protected using ``PAGEMAP_SCAN`` IOCTL with flag ``PM_SCAN_WP_MATCHING``
or the ``UFFDIO_WRITEPROTECT`` IOCTL can be used. Both of these perform the
same operation. The former is better in terms of performance.
5. Now the ``PAGEMAP_SCAN`` IOCTL can be used to either just find pages which
have been written to since they were last marked and/or optionally write protect
the pages as well.
Documentation/admin-guide/mm/userfaultfd.rst
+35
View File
@@ -244,6 +244,41 @@ write-protected (so future writes will also result in a WP fault). These ioctls
support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
respectively) to configure the mapping this way.
If the userfaultfd context has ``UFFD_FEATURE_WP_ASYNC`` feature bit set,
any vma registered with write-protection will work in async mode rather
than the default sync mode.
In async mode, there will be no message generated when a write operation
happens, meanwhile the write-protection will be resolved automatically by
the kernel. It can be seen as a more accurate version of soft-dirty
tracking and it can be different in a few ways:
- The dirty result will not be affected by vma changes (e.g. vma
merging) because the dirty is only tracked by the pte.
- It supports range operations by default, so one can enable tracking on
any range of memory as long as page aligned.
- Dirty information will not get lost if the pte was zapped due to
various reasons (e.g. during split of a shmem transparent huge page).
- Due to a reverted meaning of soft-dirty (page clean when uffd-wp bit
set; dirty when uffd-wp bit cleared), it has different semantics on
some of the memory operations. For example: ``MADV_DONTNEED`` on
anonymous (or ``MADV_REMOVE`` on a file mapping) will be treated as
dirtying of memory by dropping uffd-wp bit during the procedure.
The user app can collect the "written/dirty" status by looking up the
uffd-wp bit for the pages being interested in /proc/pagemap.
The page will not be under track of uffd-wp async mode until the page is
explicitly write-protected by ``ioctl(UFFDIO_WRITEPROTECT)`` with the mode
flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault
that was tracked by async mode userfaultfd-wp is invalid.
When userfaultfd-wp async mode is used alone, it can be applied to all
kinds of memory.
Memory Poisioning Emulation
---------------------------
Documentation/admin-guide/module-signing.rst
+11 -6
View File
@@ -28,10 +28,10 @@ trusted userspace bits.
This facility uses X.509 ITU-T standard certificates to encode the public keys
involved. The signatures are not themselves encoded in any industrial standard
type. The facility currently only supports the RSA public key encryption
standard (though it is pluggable and permits others to be used). The possible
hash algorithms that can be used are SHA-1, SHA-224, SHA-256, SHA-384, and
SHA-512 (the algorithm is selected by data in the signature).
type. The built-in facility currently only supports the RSA & NIST P-384 ECDSA
public key signing standard (though it is pluggable and permits others to be
used). The possible hash algorithms that can be used are SHA-2 and SHA-3 of
sizes 256, 384, and 512 (the algorithm is selected by data in the signature).
==========================
@@ -81,11 +81,12 @@ This has a number of options available:
sign the modules with:
=============================== ==========================================
``CONFIG_MODULE_SIG_SHA1`` :menuselection:`Sign modules with SHA-1`
``CONFIG_MODULE_SIG_SHA224`` :menuselection:`Sign modules with SHA-224`
``CONFIG_MODULE_SIG_SHA256`` :menuselection:`Sign modules with SHA-256`
``CONFIG_MODULE_SIG_SHA384`` :menuselection:`Sign modules with SHA-384`
``CONFIG_MODULE_SIG_SHA512`` :menuselection:`Sign modules with SHA-512`
``CONFIG_MODULE_SIG_SHA3_256`` :menuselection:`Sign modules with SHA3-256`
``CONFIG_MODULE_SIG_SHA3_384`` :menuselection:`Sign modules with SHA3-384`
``CONFIG_MODULE_SIG_SHA3_512`` :menuselection:`Sign modules with SHA3-512`
=============================== ==========================================
The algorithm selected here will also be built into the kernel (rather
@@ -145,6 +146,10 @@ into vmlinux) using parameters in the::
file (which is also generated if it does not already exist).
One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``) and ECDSA
(``MODULE_SIG_KEY_TYPE_ECDSA``) to generate either RSA 4k or NIST
P-384 keypair.
It is strongly recommended that you provide your own x509.genkey file.
Most notably, in the x509.genkey file, the req_distinguished_name section
Documentation/admin-guide/perf/ampere_cspmu.rst
+29
View File
@@ -0,0 +1,29 @@
.. SPDX-License-Identifier: GPL-2.0
============================================
Ampere SoC Performance Monitoring Unit (PMU)
============================================
Ampere SoC PMU is a generic PMU IP that follows Arm CoreSight PMU architecture.
Therefore, the driver is implemented as a submodule of arm_cspmu driver. At the
first phase it's used for counting MCU events on AmpereOne.
MCU PMU events
--------------
The PMU driver supports setting filters for "rank", "bank", and "threshold".
Note, that the filters are per PMU instance rather than per event.
Example for perf tool use::
/ # perf list ampere
ampere_mcu_pmu_0/act_sent/ [Kernel PMU event]
<...>
ampere_mcu_pmu_1/rd_sent/ [Kernel PMU event]
<...>
/ # perf stat -a -e ampere_mcu_pmu_0/act_sent,bank=5,rank=3,threshold=2/,ampere_mcu_pmu_1/rd_sent/ \
sleep 1
Documentation/admin-guide/perf/index.rst
+1
View File
@@ -22,3 +22,4 @@ Performance monitor support
nvidia-pmu
meson-ddr-pmu
cxl
ampere_cspmu
Documentation/admin-guide/pm/intel_idle.rst
+16 -1
View File
@@ -170,7 +170,7 @@ and ``idle=nomwait``. If any of them is present in the kernel command line, the
``MWAIT`` instruction is not allowed to be used, so the initialization of
``intel_idle`` will fail.
Apart from that there are four module parameters recognized by ``intel_idle``
Apart from that there are five module parameters recognized by ``intel_idle``
itself that can be set via the kernel command line (they cannot be updated via
sysfs, so that is the only way to change their values).
@@ -216,6 +216,21 @@ are ignored).
The idle states disabled this way can be enabled (on a per-CPU basis) from user
space via ``sysfs``.
The ``ibrs_off`` module parameter is a boolean flag (defaults to
false). If set, it is used to control if IBRS (Indirect Branch Restricted
Speculation) should be turned off when the CPU enters an idle state.
This flag does not affect CPUs that use Enhanced IBRS which can remain
on with little performance impact.
For some CPUs, IBRS will be selected as mitigation for Spectre v2 and Retbleed
security vulnerabilities by default. Leaving the IBRS mode on while idling may
have a performance impact on its sibling CPU. The IBRS mode will be turned off
by default when the CPU enters into a deep idle state, but not in some
shallower ones. Setting the ``ibrs_off`` module parameter will force the IBRS
mode to off when the CPU is in any one of the available idle states. This may
help performance of a sibling CPU at the expense of a slightly higher wakeup
latency for the idle CPU.
.. _intel-idle-core-and-package-idle-states:
Documentation/admin-guide/pstore-blk.rst
+4 -4
View File
@@ -76,7 +76,7 @@ kmsg_size
~~~~~~~~~
The chunk size in KB for oops/panic front-end. It **MUST** be a multiple of 4.
It's optional if you do not care oops/panic log.
It's optional if you do not care about the oops/panic log.
There are multiple chunks for oops/panic front-end depending on the remaining
space except other pstore front-ends.
@@ -88,7 +88,7 @@ pmsg_size
~~~~~~~~~
The chunk size in KB for pmsg front-end. It **MUST** be a multiple of 4.
It's optional if you do not care pmsg log.
It's optional if you do not care about the pmsg log.
Unlike oops/panic front-end, there is only one chunk for pmsg front-end.
@@ -100,7 +100,7 @@ console_size
~~~~~~~~~~~~
The chunk size in KB for console front-end. It **MUST** be a multiple of 4.
It's optional if you do not care console log.
It's optional if you do not care about the console log.
Similar to pmsg front-end, there is only one chunk for console front-end.
@@ -111,7 +111,7 @@ ftrace_size
~~~~~~~~~~~
The chunk size in KB for ftrace front-end. It **MUST** be a multiple of 4.
It's optional if you do not care console log.
It's optional if you do not care about the ftrace log.
Similar to oops front-end, there are multiple chunks for ftrace front-end
depending on the count of cpu processors. Each chunk size is equal to
Documentation/admin-guide/spkguide.txt
+8 -3
View File
@@ -7,7 +7,7 @@ Last modified on Mon Sep 27 14:26:31 2010
Document version 1.3
Copyright (c) 2005 Gene Collins
Copyright (c) 2008 Samuel Thibault
Copyright (c) 2008, 2023 Samuel Thibault
Copyright (c) 2009, 2010 the Speakup Team
Permission is granted to copy, distribute and/or modify this document
@@ -83,8 +83,7 @@ spkout -- Speak Out
txprt -- Transport
dummy -- Plain text terminal
Note: Speakup does * NOT * support usb connections! Speakup also does *
NOT * support the internal Tripletalk!
Note: Speakup does * NOT * support the internal Tripletalk!
Speakup does support two other synthesizers, but because they work in
conjunction with other software, they must be loaded as modules after
@@ -94,6 +93,12 @@ These are as follows:
decpc -- DecTalk PC (not available at boot up)
soft -- One of several software synthesizers (not available at boot up)
By default speakup looks for the synthesizer on the ttyS0 serial port. This can
be changed with the device parameter of the modules, for instance for
DoubleTalk LT:
speakup_ltlk.dev=ttyUSB0
See the sections on loading modules and software synthesizers later in
this manual for further details. It should be noted here that the
speakup.synth boot parameter will have no effect if Speakup has been
Documentation/admin-guide/sysctl/fs.rst
+8 -8
View File
@@ -42,16 +42,16 @@ pre-allocation or re-sizing of any kernel data structures.
dentry-state
------------
This file shows the values in ``struct dentry_stat``, as defined in
``linux/include/linux/dcache.h``::
This file shows the values in ``struct dentry_stat_t``, as defined in
``fs/dcache.c``::
struct dentry_stat_t dentry_stat {
int nr_dentry;
int nr_unused;
int age_limit; /* age in seconds */
int want_pages; /* pages requested by system */
int nr_negative; /* # of unused negative dentries */
int dummy; /* Reserved for future use */
long nr_dentry;
long nr_unused;
long age_limit; /* age in seconds */
long want_pages; /* pages requested by system */
long nr_negative; /* # of unused negative dentries */
long dummy; /* Reserved for future use */
};
Dentries are dynamically allocated and deallocated.
Documentation/admin-guide/sysctl/kernel.rst
+4 -22
View File
@@ -436,7 +436,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``, ``ia64`` and ``loongarch``), controls whether all
currently, ``arc`` and ``loongarch``), controls whether all
unaligned traps are logged.
= =============================================================
@@ -445,10 +445,7 @@ unaligned traps are logged.
setting.
= =============================================================
See also `unaligned-trap`_ and `unaligned-dump-stack`_. On ``ia64``,
this allows system administrators to override the
``IA64_THREAD_UAC_NOPRINT`` ``prctl`` and avoid logs being flooded.
See also `unaligned-trap`_.
io_uring_disabled
=================
@@ -1182,7 +1179,8 @@ automatically on platforms where it can run (that is,
platforms with asymmetric CPU topologies and having an Energy
Model available). If your platform happens to meet the
requirements for EAS but you do not want to use it, change
this value to 0.
this value to 0. On Non-EAS platforms, write operation fails and
read doesn't return anything.
task_delayacct
===============
@@ -1538,22 +1536,6 @@ See Documentation/admin-guide/kernel-parameters.rst and
Documentation/trace/boottime-trace.rst.
.. _unaligned-dump-stack:
unaligned-dump-stack (ia64)
===========================
When logging unaligned accesses, controls whether the stack is
dumped.
= ===================================================
0 Do not dump the stack. This is the default setting.
1 Dump the stack.
= ===================================================
See also `ignore-unaligned-usertrap`_.
unaligned-trap
==============
Documentation/admin-guide/sysctl/net.rst
+1
View File
@@ -71,6 +71,7 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
- s390x
- riscv64
- riscv32
- loongarch64
And the older cBPF JIT supported on the following archs:
Documentation/admin-guide/sysctl/vm.rst
+2 -2
View File
@@ -742,8 +742,8 @@ overcommit_memory
This value contains a flag that enables memory overcommitment.
When this flag is 0, the kernel attempts to estimate the amount
of free memory left when userspace requests more memory.
When this flag is 0, the kernel compares the userspace memory request
size against total memory plus swap and rejects obvious overcommits.
When this flag is 1, the kernel pretends there is always enough
memory until it actually runs out.
Documentation/arch/arm64/cpu-feature-registers.rst
+14
View File
@@ -175,6 +175,8 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
| SME | [27-24] | y |
+------------------------------+---------+---------+
| MTE | [11-8] | y |
+------------------------------+---------+---------+
| SSBS | [7-4] | y |
@@ -266,6 +268,8 @@ infrastructure:
+------------------------------+---------+---------+
| SHA3 | [35-32] | y |
+------------------------------+---------+---------+
| B16B16 | [27-24] | y |
+------------------------------+---------+---------+
| BF16 | [23-20] | y |
+------------------------------+---------+---------+
| BitPerm | [19-16] | y |
@@ -288,8 +292,18 @@ infrastructure:
+------------------------------+---------+---------+
| Name | bits | visible |
+------------------------------+---------+---------+
| CSSC | [55-52] | y |
+------------------------------+---------+---------+
| RPRFM | [51-48] | y |
+------------------------------+---------+---------+
| BC | [23-20] | y |
+------------------------------+---------+---------+
| MOPS | [19-16] | y |
+------------------------------+---------+---------+
| APA3 | [15-12] | y |
+------------------------------+---------+---------+
| GPA3 | [11-8] | y |
+------------------------------+---------+---------+
| RPRES | [7-4] | y |
+------------------------------+---------+---------+
| WFXT | [3-0] | y |
Documentation/arch/arm64/elf_hwcaps.rst
+15 -3
View File
@@ -174,7 +174,7 @@ HWCAP2_DCPODP
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
HWCAP2_SVE2
Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0001.
HWCAP2_SVEAES
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
@@ -222,7 +222,7 @@ HWCAP2_RNG
Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
HWCAP2_BTI
Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
Functionality implied by ID_AA64PFR1_EL1.BT == 0b0001.
HWCAP2_MTE
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
@@ -232,7 +232,7 @@ HWCAP2_ECV
Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
HWCAP2_AFP
Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
Functionality implied by ID_AA64MMFR1_EL1.AFP == 0b0001.
HWCAP2_RPRES
Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
@@ -305,6 +305,18 @@ HWCAP2_SMEF16F16
HWCAP2_MOPS
Functionality implied by ID_AA64ISAR2_EL1.MOPS == 0b0001.
HWCAP2_HBC
Functionality implied by ID_AA64ISAR2_EL1.BC == 0b0001.
HWCAP2_SVE_B16B16
Functionality implied by ID_AA64ZFR0_EL1.B16B16 == 0b0001.
HWCAP2_LRCPC3
Functionality implied by ID_AA64ISAR1_EL1.LRCPC == 0b0011.
HWCAP2_LSE128
Functionality implied by ID_AA64ISAR0_EL1.Atomic == 0b0011.
4. Unused AT_HWCAP bits
-----------------------
Documentation/arch/arm64/silicon-errata.rst
+2
View File
@@ -71,6 +71,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A510 | #2658417 | ARM64_ERRATUM_2658417 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A520 | #2966298 | ARM64_ERRATUM_2966298 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 |
Documentation/arch/ia64/aliasing.rst
-246
View File
@@ -1,246 +0,0 @@
==================================
Memory Attribute Aliasing on IA-64
==================================
Bjorn Helgaas <bjorn.helgaas@hp.com>
May 4, 2006
Memory Attributes
=================
Itanium supports several attributes for virtual memory references.
The attribute is part of the virtual translation, i.e., it is
contained in the TLB entry. The ones of most interest to the Linux
kernel are:
== ======================
WB Write-back (cacheable)
UC Uncacheable
WC Write-coalescing
== ======================
System memory typically uses the WB attribute. The UC attribute is
used for memory-mapped I/O devices. The WC attribute is uncacheable
like UC is, but writes may be delayed and combined to increase
performance for things like frame buffers.
The Itanium architecture requires that we avoid accessing the same
page with both a cacheable mapping and an uncacheable mapping[1].
The design of the chipset determines which attributes are supported
on which regions of the address space. For example, some chipsets
support either WB or UC access to main memory, while others support
only WB access.
Memory Map
==========
Platform firmware describes the physical memory map and the
supported attributes for each region. At boot-time, the kernel uses
the EFI GetMemoryMap() interface. ACPI can also describe memory
devices and the attributes they support, but Linux/ia64 currently
doesn't use this information.
The kernel uses the efi_memmap table returned from GetMemoryMap() to
learn the attributes supported by each region of physical address
space. Unfortunately, this table does not completely describe the
address space because some machines omit some or all of the MMIO
regions from the map.
The kernel maintains another table, kern_memmap, which describes the
memory Linux is actually using and the attribute for each region.
This contains only system memory; it does not contain MMIO space.
The kern_memmap table typically contains only a subset of the system
memory described by the efi_memmap. Linux/ia64 can't use all memory
in the system because of constraints imposed by the identity mapping
scheme.
The efi_memmap table is preserved unmodified because the original
boot-time information is required for kexec.
Kernel Identity Mappings
========================
Linux/ia64 identity mappings are done with large pages, currently
either 16MB or 64MB, referred to as "granules." Cacheable mappings
are speculative[2], so the processor can read any location in the
page at any time, independent of the programmer's intentions. This
means that to avoid attribute aliasing, Linux can create a cacheable
identity mapping only when the entire granule supports cacheable
access.
Therefore, kern_memmap contains only full granule-sized regions that
can referenced safely by an identity mapping.
Uncacheable mappings are not speculative, so the processor will
generate UC accesses only to locations explicitly referenced by
software. This allows UC identity mappings to cover granules that
are only partially populated, or populated with a combination of UC
and WB regions.
User Mappings
=============
User mappings are typically done with 16K or 64K pages. The smaller
page size allows more flexibility because only 16K or 64K has to be
homogeneous with respect to memory attributes.
Potential Attribute Aliasing Cases
==================================
There are several ways the kernel creates new mappings:
mmap of /dev/mem
----------------
This uses remap_pfn_range(), which creates user mappings. These
mappings may be either WB or UC. If the region being mapped
happens to be in kern_memmap, meaning that it may also be mapped
by a kernel identity mapping, the user mapping must use the same
attribute as the kernel mapping.
If the region is not in kern_memmap, the user mapping should use
an attribute reported as being supported in the EFI memory map.
Since the EFI memory map does not describe MMIO on some
machines, this should use an uncacheable mapping as a fallback.
mmap of /sys/class/pci_bus/.../legacy_mem
-----------------------------------------
This is very similar to mmap of /dev/mem, except that legacy_mem
only allows mmap of the one megabyte "legacy MMIO" area for a
specific PCI bus. Typically this is the first megabyte of
physical address space, but it may be different on machines with
several VGA devices.
"X" uses this to access VGA frame buffers. Using legacy_mem
rather than /dev/mem allows multiple instances of X to talk to
different VGA cards.
The /dev/mem mmap constraints apply.
mmap of /proc/bus/pci/.../??.?
------------------------------
This is an MMIO mmap of PCI functions, which additionally may or
may not be requested as using the WC attribute.
If WC is requested, and the region in kern_memmap is either WC
or UC, and the EFI memory map designates the region as WC, then
the WC mapping is allowed.
Otherwise, the user mapping must use the same attribute as the
kernel mapping.
read/write of /dev/mem
----------------------
This uses copy_from_user(), which implicitly uses a kernel
identity mapping. This is obviously safe for things in
kern_memmap.
There may be corner cases of things that are not in kern_memmap,
but could be accessed this way. For example, registers in MMIO
space are not in kern_memmap, but could be accessed with a UC
mapping. This would not cause attribute aliasing. But
registers typically can be accessed only with four-byte or
eight-byte accesses, and the copy_from_user() path doesn't allow
any control over the access size, so this would be dangerous.
ioremap()
---------
This returns a mapping for use inside the kernel.
If the region is in kern_memmap, we should use the attribute
specified there.
If the EFI memory map reports that the entire granule supports
WB, we should use that (granules that are partially reserved
or occupied by firmware do not appear in kern_memmap).
If the granule contains non-WB memory, but we can cover the
region safely with kernel page table mappings, we can use
ioremap_page_range() as most other architectures do.
Failing all of the above, we have to fall back to a UC mapping.
Past Problem Cases
==================
mmap of various MMIO regions from /dev/mem by "X" on Intel platforms
--------------------------------------------------------------------
The EFI memory map may not report these MMIO regions.
These must be allowed so that X will work. This means that
when the EFI memory map is incomplete, every /dev/mem mmap must
succeed. It may create either WB or UC user mappings, depending
on whether the region is in kern_memmap or the EFI memory map.
mmap of 0x0-0x9FFFF /dev/mem by "hwinfo" on HP sx1000 with VGA enabled
----------------------------------------------------------------------
The EFI memory map reports the following attributes:
=============== ======= ==================
0x00000-0x9FFFF WB only
0xA0000-0xBFFFF UC only (VGA frame buffer)
0xC0000-0xFFFFF WB only
=============== ======= ==================
This mmap is done with user pages, not kernel identity mappings,
so it is safe to use WB mappings.
The kernel VGA driver may ioremap the VGA frame buffer at 0xA0000,
which uses a granule-sized UC mapping. This granule will cover some
WB-only memory, but since UC is non-speculative, the processor will
never generate an uncacheable reference to the WB-only areas unless
the driver explicitly touches them.
mmap of 0x0-0xFFFFF legacy_mem by "X"
-------------------------------------
If the EFI memory map reports that the entire range supports the
same attributes, we can allow the mmap (and we will prefer WB if
supported, as is the case with HP sx[12]000 machines with VGA
disabled).
If EFI reports the range as partly WB and partly UC (as on sx[12]000
machines with VGA enabled), we must fail the mmap because there's no
safe attribute to use.
If EFI reports some of the range but not all (as on Intel firmware
that doesn't report the VGA frame buffer at all), we should fail the
mmap and force the user to map just the specific region of interest.
mmap of 0xA0000-0xBFFFF legacy_mem by "X" on HP sx1000 with VGA disabled
------------------------------------------------------------------------
The EFI memory map reports the following attributes::
0x00000-0xFFFFF WB only (no VGA MMIO hole)
This is a special case of the previous case, and the mmap should
fail for the same reason as above.
read of /sys/devices/.../rom
----------------------------
For VGA devices, this may cause an ioremap() of 0xC0000. This
used to be done with a UC mapping, because the VGA frame buffer
at 0xA0000 prevents use of a WB granule. The UC mapping causes
an MCA on HP sx[12]000 chipsets.
We should use WB page table mappings to avoid covering the VGA
frame buffer.
Notes
=====
[1] SDM rev 2.2, vol 2, sec 4.4.1.
[2] SDM rev 2.2, vol 2, sec 4.4.6.
Documentation/arch/ia64/efirtc.rst
-144
View File
@@ -1,144 +0,0 @@
==========================
EFI Real Time Clock driver
==========================
S. Eranian <eranian@hpl.hp.com>
March 2000
1. Introduction
===============
This document describes the efirtc.c driver has provided for
the IA-64 platform.
The purpose of this driver is to supply an API for kernel and user applications
to get access to the Time Service offered by EFI version 0.92.
EFI provides 4 calls one can make once the OS is booted: GetTime(),
SetTime(), GetWakeupTime(), SetWakeupTime() which are all supported by this
driver. We describe those calls as well the design of the driver in the
following sections.
2. Design Decisions
===================
The original ideas was to provide a very simple driver to get access to,
at first, the time of day service. This is required in order to access, in a
portable way, the CMOS clock. A program like /sbin/hwclock uses such a clock
to initialize the system view of the time during boot.
Because we wanted to minimize the impact on existing user-level apps using
the CMOS clock, we decided to expose an API that was very similar to the one
used today with the legacy RTC driver (driver/char/rtc.c). However, because
EFI provides a simpler services, not all ioctl() are available. Also
new ioctl()s have been introduced for things that EFI provides but not the
legacy.
EFI uses a slightly different way of representing the time, noticeably
the reference date is different. Year is the using the full 4-digit format.
The Epoch is January 1st 1998. For backward compatibility reasons we don't
expose this new way of representing time. Instead we use something very
similar to the struct tm, i.e. struct rtc_time, as used by hwclock.
One of the reasons for doing it this way is to allow for EFI to still evolve
without necessarily impacting any of the user applications. The decoupling
enables flexibility and permits writing wrapper code is ncase things change.
The driver exposes two interfaces, one via the device file and a set of
ioctl()s. The other is read-only via the /proc filesystem.
As of today we don't offer a /proc/sys interface.
To allow for a uniform interface between the legacy RTC and EFI time service,
we have created the include/linux/rtc.h header file to contain only the
"public" API of the two drivers. The specifics of the legacy RTC are still
in include/linux/mc146818rtc.h.
3. Time of day service
======================
The part of the driver gives access to the time of day service of EFI.
Two ioctl()s, compatible with the legacy RTC calls:
Read the CMOS clock::
ioctl(d, RTC_RD_TIME, &rtc);
Write the CMOS clock::
ioctl(d, RTC_SET_TIME, &rtc);
The rtc is a pointer to a data structure defined in rtc.h which is close
to a struct tm::
struct rtc_time {
int tm_sec;
int tm_min;
int tm_hour;
int tm_mday;
int tm_mon;
int tm_year;
int tm_wday;
int tm_yday;
int tm_isdst;
};
The driver takes care of converting back an forth between the EFI time and
this format.
Those two ioctl()s can be exercised with the hwclock command:
For reading::
# /sbin/hwclock --show
Mon Mar 6 15:32:32 2000 -0.910248 seconds
For setting::
# /sbin/hwclock --systohc
Root privileges are required to be able to set the time of day.
4. Wakeup Alarm service
=======================
EFI provides an API by which one can program when a machine should wakeup,
i.e. reboot. This is very different from the alarm provided by the legacy
RTC which is some kind of interval timer alarm. For this reason we don't use
the same ioctl()s to get access to the service. Instead we have
introduced 2 news ioctl()s to the interface of an RTC.
We have added 2 new ioctl()s that are specific to the EFI driver:
Read the current state of the alarm::
ioctl(d, RTC_WKALM_RD, &wkt)
Set the alarm or change its status::
ioctl(d, RTC_WKALM_SET, &wkt)
The wkt structure encapsulates a struct rtc_time + 2 extra fields to get
status information::
struct rtc_wkalrm {
unsigned char enabled; /* =1 if alarm is enabled */
unsigned char pending; /* =1 if alarm is pending */
struct rtc_time time;
}
As of today, none of the existing user-level apps supports this feature.
However writing such a program should be hard by simply using those two
ioctl().
Root privileges are required to be able to set the alarm.
5. References
=============
Checkout the following Web site for more information on EFI:
http://developer.intel.com/technology/efi/
Documentation/arch/ia64/err_inject.rst
-1067
View File
File diff suppressed because it is too large Load Diff
Documentation/arch/ia64/features.rst
-3
View File
@@ -1,3 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
.. kernel-feat:: $srctree/Documentation/features ia64
Documentation/arch/ia64/fsys.rst
-303
View File
@@ -1,303 +0,0 @@
===================================
Light-weight System Calls for IA-64
===================================
Started: 13-Jan-2003
Last update: 27-Sep-2003
David Mosberger-Tang
<davidm@hpl.hp.com>
Using the "epc" instruction effectively introduces a new mode of
execution to the ia64 linux kernel. We call this mode the
"fsys-mode". To recap, the normal states of execution are:
- kernel mode:
Both the register stack and the memory stack have been
switched over to kernel memory. The user-level state is saved
in a pt-regs structure at the top of the kernel memory stack.
- user mode:
Both the register stack and the kernel stack are in
user memory. The user-level state is contained in the
CPU registers.
- bank 0 interruption-handling mode:
This is the non-interruptible state which all
interruption-handlers start execution in. The user-level
state remains in the CPU registers and some kernel state may
be stored in bank 0 of registers r16-r31.
In contrast, fsys-mode has the following special properties:
- execution is at privilege level 0 (most-privileged)
- CPU registers may contain a mixture of user-level and kernel-level
state (it is the responsibility of the kernel to ensure that no
security-sensitive kernel-level state is leaked back to
user-level)
- execution is interruptible and preemptible (an fsys-mode handler
can disable interrupts and avoid all other interruption-sources
to avoid preemption)
- neither the memory-stack nor the register-stack can be trusted while
in fsys-mode (they point to the user-level stacks, which may
be invalid, or completely bogus addresses)
In summary, fsys-mode is much more similar to running in user-mode
than it is to running in kernel-mode. Of course, given that the
privilege level is at level 0, this means that fsys-mode requires some
care (see below).
How to tell fsys-mode
=====================
Linux operates in fsys-mode when (a) the privilege level is 0 (most
privileged) and (b) the stacks have NOT been switched to kernel memory
yet. For convenience, the header file <asm-ia64/ptrace.h> provides
three macros::
user_mode(regs)
user_stack(task,regs)
fsys_mode(task,regs)
The "regs" argument is a pointer to a pt_regs structure. The "task"
argument is a pointer to the task structure to which the "regs"
pointer belongs to. user_mode() returns TRUE if the CPU state pointed
to by "regs" was executing in user mode (privilege level 3).
user_stack() returns TRUE if the state pointed to by "regs" was
executing on the user-level stack(s). Finally, fsys_mode() returns
TRUE if the CPU state pointed to by "regs" was executing in fsys-mode.
The fsys_mode() macro is equivalent to the expression::
!user_mode(regs) && user_stack(task,regs)
How to write an fsyscall handler
================================
The file arch/ia64/kernel/fsys.S contains a table of fsyscall-handlers
(fsyscall_table). This table contains one entry for each system call.
By default, a system call is handled by fsys_fallback_syscall(). This
routine takes care of entering (full) kernel mode and calling the
normal Linux system call handler. For performance-critical system
calls, it is possible to write a hand-tuned fsyscall_handler. For
example, fsys.S contains fsys_getpid(), which is a hand-tuned version
of the getpid() system call.
The entry and exit-state of an fsyscall handler is as follows:
Machine state on entry to fsyscall handler
------------------------------------------
========= ===============================================================
r10 0
r11 saved ar.pfs (a user-level value)
r15 system call number
r16 "current" task pointer (in normal kernel-mode, this is in r13)
r32-r39 system call arguments
b6 return address (a user-level value)
ar.pfs previous frame-state (a user-level value)
PSR.be cleared to zero (i.e., little-endian byte order is in effect)
- all other registers may contain values passed in from user-mode
========= ===============================================================
Required machine state on exit to fsyscall handler
--------------------------------------------------
========= ===========================================================
r11 saved ar.pfs (as passed into the fsyscall handler)
r15 system call number (as passed into the fsyscall handler)
r32-r39 system call arguments (as passed into the fsyscall handler)
b6 return address (as passed into the fsyscall handler)
ar.pfs previous frame-state (as passed into the fsyscall handler)
========= ===========================================================
Fsyscall handlers can execute with very little overhead, but with that
speed comes a set of restrictions:
* Fsyscall-handlers MUST check for any pending work in the flags
member of the thread-info structure and if any of the
TIF_ALLWORK_MASK flags are set, the handler needs to fall back on
doing a full system call (by calling fsys_fallback_syscall).
* Fsyscall-handlers MUST preserve incoming arguments (r32-r39, r11,
r15, b6, and ar.pfs) because they will be needed in case of a
system call restart. Of course, all "preserved" registers also
must be preserved, in accordance to the normal calling conventions.
* Fsyscall-handlers MUST check argument registers for containing a
NaT value before using them in any way that could trigger a
NaT-consumption fault. If a system call argument is found to
contain a NaT value, an fsyscall-handler may return immediately
with r8=EINVAL, r10=-1.
* Fsyscall-handlers MUST NOT use the "alloc" instruction or perform
any other operation that would trigger mandatory RSE
(register-stack engine) traffic.
* Fsyscall-handlers MUST NOT write to any stacked registers because
it is not safe to assume that user-level called a handler with the
proper number of arguments.
* Fsyscall-handlers need to be careful when accessing per-CPU variables:
unless proper safe-guards are taken (e.g., interruptions are avoided),
execution may be pre-empted and resumed on another CPU at any given
time.
* Fsyscall-handlers must be careful not to leak sensitive kernel'
information back to user-level. In particular, before returning to
user-level, care needs to be taken to clear any scratch registers
that could contain sensitive information (note that the current
task pointer is not considered sensitive: it's already exposed
through ar.k6).
* Fsyscall-handlers MUST NOT access user-memory without first
validating access-permission (this can be done typically via
probe.r.fault and/or probe.w.fault) and without guarding against
memory access exceptions (this can be done with the EX() macros
defined by asmmacro.h).
The above restrictions may seem draconian, but remember that it's
possible to trade off some of the restrictions by paying a slightly
higher overhead. For example, if an fsyscall-handler could benefit
from the shadow register bank, it could temporarily disable PSR.i and
PSR.ic, switch to bank 0 (bsw.0) and then use the shadow registers as
needed. In other words, following the above rules yields extremely
fast system call execution (while fully preserving system call
semantics), but there is also a lot of flexibility in handling more
complicated cases.
Signal handling
===============
The delivery of (asynchronous) signals must be delayed until fsys-mode
is exited. This is accomplished with the help of the lower-privilege
transfer trap: arch/ia64/kernel/process.c:do_notify_resume_user()
checks whether the interrupted task was in fsys-mode and, if so, sets
PSR.lp and returns immediately. When fsys-mode is exited via the
"br.ret" instruction that lowers the privilege level, a trap will
occur. The trap handler clears PSR.lp again and returns immediately.
The kernel exit path then checks for and delivers any pending signals.
PSR Handling
============
The "epc" instruction doesn't change the contents of PSR at all. This
is in contrast to a regular interruption, which clears almost all
bits. Because of that, some care needs to be taken to ensure things
work as expected. The following discussion describes how each PSR bit
is handled.
======= =======================================================================
PSR.be Cleared when entering fsys-mode. A srlz.d instruction is used
to ensure the CPU is in little-endian mode before the first
load/store instruction is executed. PSR.be is normally NOT
restored upon return from an fsys-mode handler. In other
words, user-level code must not rely on PSR.be being preserved
across a system call.
PSR.up Unchanged.
PSR.ac Unchanged.
PSR.mfl Unchanged. Note: fsys-mode handlers must not write-registers!
PSR.mfh Unchanged. Note: fsys-mode handlers must not write-registers!
PSR.ic Unchanged. Note: fsys-mode handlers can clear the bit, if needed.
PSR.i Unchanged. Note: fsys-mode handlers can clear the bit, if needed.
PSR.pk Unchanged.
PSR.dt Unchanged.
PSR.dfl Unchanged. Note: fsys-mode handlers must not write-registers!
PSR.dfh Unchanged. Note: fsys-mode handlers must not write-registers!
PSR.sp Unchanged.
PSR.pp Unchanged.
PSR.di Unchanged.
PSR.si Unchanged.
PSR.db Unchanged. The kernel prevents user-level from setting a hardware
breakpoint that triggers at any privilege level other than
3 (user-mode).
PSR.lp Unchanged.
PSR.tb Lazy redirect. If a taken-branch trap occurs while in
fsys-mode, the trap-handler modifies the saved machine state
such that execution resumes in the gate page at
syscall_via_break(), with privilege level 3. Note: the
taken branch would occur on the branch invoking the
fsyscall-handler, at which point, by definition, a syscall
restart is still safe. If the system call number is invalid,
the fsys-mode handler will return directly to user-level. This
return will trigger a taken-branch trap, but since the trap is
taken _after_ restoring the privilege level, the CPU has already
left fsys-mode, so no special treatment is needed.
PSR.rt Unchanged.
PSR.cpl Cleared to 0.
PSR.is Unchanged (guaranteed to be 0 on entry to the gate page).
PSR.mc Unchanged.
PSR.it Unchanged (guaranteed to be 1).
PSR.id Unchanged. Note: the ia64 linux kernel never sets this bit.
PSR.da Unchanged. Note: the ia64 linux kernel never sets this bit.
PSR.dd Unchanged. Note: the ia64 linux kernel never sets this bit.
PSR.ss Lazy redirect. If set, "epc" will cause a Single Step Trap to
be taken. The trap handler then modifies the saved machine
state such that execution resumes in the gate page at
syscall_via_break(), with privilege level 3.
PSR.ri Unchanged.
PSR.ed Unchanged. Note: This bit could only have an effect if an fsys-mode
handler performed a speculative load that gets NaTted. If so, this
would be the normal & expected behavior, so no special treatment is
needed.
PSR.bn Unchanged. Note: fsys-mode handlers may clear the bit, if needed.
Doing so requires clearing PSR.i and PSR.ic as well.
PSR.ia Unchanged. Note: the ia64 linux kernel never sets this bit.
======= =======================================================================
Using fast system calls
=======================
To use fast system calls, userspace applications need simply call
__kernel_syscall_via_epc(). For example
-- example fgettimeofday() call --
-- fgettimeofday.S --
::
#include <asm/asmmacro.h>
GLOBAL_ENTRY(fgettimeofday)
.prologue
.save ar.pfs, r11
mov r11 = ar.pfs
.body
mov r2 = 0xa000000000020660;; // gate address
// found by inspection of System.map for the
// __kernel_syscall_via_epc() function. See
// below for how to do this for real.
mov b7 = r2
mov r15 = 1087 // gettimeofday syscall
;;
br.call.sptk.many b6 = b7
;;
.restore sp
mov ar.pfs = r11
br.ret.sptk.many rp;; // return to caller
END(fgettimeofday)
-- end fgettimeofday.S --
In reality, getting the gate address is accomplished by two extra
values passed via the ELF auxiliary vector (include/asm-ia64/elf.h)
* AT_SYSINFO : is the address of __kernel_syscall_via_epc()
* AT_SYSINFO_EHDR : is the address of the kernel gate ELF DSO
The ELF DSO is a pre-linked library that is mapped in by the kernel at
the gate page. It is a proper ELF shared object so, with a dynamic
loader that recognises the library, you should be able to make calls to
the exported functions within it as with any other shared library.
AT_SYSINFO points into the kernel DSO at the
__kernel_syscall_via_epc() function for historical reasons (it was
used before the kernel DSO) and as a convenience.
Documentation/arch/ia64/ia64.rst
-49
View File
@@ -1,49 +0,0 @@
===========================================
Linux kernel release for the IA-64 Platform
===========================================
These are the release notes for Linux since version 2.4 for IA-64
platform. This document provides information specific to IA-64
ONLY, to get additional information about the Linux kernel also
read the original Linux README provided with the kernel.
Installing the Kernel
=====================
- IA-64 kernel installation is the same as the other platforms, see
original README for details.
Software Requirements
=====================
Compiling and running this kernel requires an IA-64 compliant GCC
compiler. And various software packages also compiled with an
IA-64 compliant GCC compiler.
Configuring the Kernel
======================
Configuration is the same, see original README for details.
Compiling the Kernel:
- Compiling this kernel doesn't differ from other platform so read
the original README for details BUT make sure you have an IA-64
compliant GCC compiler.
IA-64 Specifics
===============
- General issues:
* Hardly any performance tuning has been done. Obvious targets
include the library routines (IP checksum, etc.). Less
obvious targets include making sure we don't flush the TLB
needlessly, etc.
* SMP locks cleanup/optimization
* IA32 support. Currently experimental. It mostly works.
Documentation/arch/ia64/index.rst
-19
View File
@@ -1,19 +0,0 @@
.. SPDX-License-Identifier: GPL-2.0
==================
IA-64 Architecture
==================
.. toctree::
:maxdepth: 1
ia64
aliasing
efirtc
err_inject
fsys
irq-redir
mca
serial
features
Documentation/arch/ia64/irq-redir.rst
-80
View File
@@ -1,80 +0,0 @@
==============================
IRQ affinity on IA64 platforms
==============================
07.01.2002, Erich Focht <efocht@ess.nec.de>
By writing to /proc/irq/IRQ#/smp_affinity the interrupt routing can be
controlled. The behavior on IA64 platforms is slightly different from
that described in Documentation/core-api/irq/irq-affinity.rst for i386 systems.
Because of the usage of SAPIC mode and physical destination mode the
IRQ target is one particular CPU and cannot be a mask of several
CPUs. Only the first non-zero bit is taken into account.
Usage examples
==============
The target CPU has to be specified as a hexadecimal CPU mask. The
first non-zero bit is the selected CPU. This format has been kept for
compatibility reasons with i386.
Set the delivery mode of interrupt 41 to fixed and route the
interrupts to CPU #3 (logical CPU number) (2^3=0x08)::
echo "8" >/proc/irq/41/smp_affinity
Set the default route for IRQ number 41 to CPU 6 in lowest priority
delivery mode (redirectable)::
echo "r 40" >/proc/irq/41/smp_affinity
The output of the command::
cat /proc/irq/IRQ#/smp_affinity
gives the target CPU mask for the specified interrupt vector. If the CPU
mask is preceded by the character "r", the interrupt is redirectable
(i.e. lowest priority mode routing is used), otherwise its route is
fixed.
Initialization and default behavior
===================================
If the platform features IRQ redirection (info provided by SAL) all
IO-SAPIC interrupts are initialized with CPU#0 as their default target
and the routing is the so called "lowest priority mode" (actually
fixed SAPIC mode with hint). The XTP chipset registers are used as hints
for the IRQ routing. Currently in Linux XTP registers can have three
values:
- minimal for an idle task,
- normal if any other task runs,
- maximal if the CPU is going to be switched off.
The IRQ is routed to the CPU with lowest XTP register value, the
search begins at the default CPU. Therefore most of the interrupts
will be handled by CPU #0.
If the platform doesn't feature interrupt redirection IOSAPIC fixed
routing is used. The target CPUs are distributed in a round robin
manner. IRQs will be routed only to the selected target CPUs. Check
with::
cat /proc/interrupts
Comments
========
On large (multi-node) systems it is recommended to route the IRQs to
the node to which the corresponding device is connected.
For systems like the NEC AzusA we get IRQ node-affinity for free. This
is because usually the chipsets on each node redirect the interrupts
only to their own CPUs (as they cannot see the XTP registers on the
other nodes).
Documentation/arch/ia64/mca.rst
-198
View File
@@ -1,198 +0,0 @@
=============================================================
An ad-hoc collection of notes on IA64 MCA and INIT processing
=============================================================
Feel free to update it with notes about any area that is not clear.
---
MCA/INIT are completely asynchronous. They can occur at any time, when
the OS is in any state. Including when one of the cpus is already
holding a spinlock. Trying to get any lock from MCA/INIT state is
asking for deadlock. Also the state of structures that are protected
by locks is indeterminate, including linked lists.
---
The complicated ia64 MCA process. All of this is mandated by Intel's
specification for ia64 SAL, error recovery and unwind, it is not as
if we have a choice here.
* MCA occurs on one cpu, usually due to a double bit memory error.
This is the monarch cpu.
* SAL sends an MCA rendezvous interrupt (which is a normal interrupt)
to all the other cpus, the slaves.
* Slave cpus that receive the MCA interrupt call down into SAL, they
end up spinning disabled while the MCA is being serviced.
* If any slave cpu was already spinning disabled when the MCA occurred
then it cannot service the MCA interrupt. SAL waits ~20 seconds then
sends an unmaskable INIT event to the slave cpus that have not
already rendezvoused.
* Because MCA/INIT can be delivered at any time, including when the cpu
is down in PAL in physical mode, the registers at the time of the
event are _completely_ undefined. In particular the MCA/INIT
handlers cannot rely on the thread pointer, PAL physical mode can
(and does) modify TP. It is allowed to do that as long as it resets
TP on return. However MCA/INIT events expose us to these PAL
internal TP changes. Hence curr_task().
* If an MCA/INIT event occurs while the kernel was running (not user
space) and the kernel has called PAL then the MCA/INIT handler cannot
assume that the kernel stack is in a fit state to be used. Mainly
because PAL may or may not maintain the stack pointer internally.
Because the MCA/INIT handlers cannot trust the kernel stack, they
have to use their own, per-cpu stacks. The MCA/INIT stacks are
preformatted with just enough task state to let the relevant handlers
do their job.
* Unlike most other architectures, the ia64 struct task is embedded in
the kernel stack[1]. So switching to a new kernel stack means that
we switch to a new task as well. Because various bits of the kernel
assume that current points into the struct task, switching to a new
stack also means a new value for current.
* Once all slaves have rendezvoused and are spinning disabled, the
monarch is entered. The monarch now tries to diagnose the problem
and decide if it can recover or not.
* Part of the monarch's job is to look at the state of all the other
tasks. The only way to do that on ia64 is to call the unwinder,
as mandated by Intel.
* The starting point for the unwind depends on whether a task is
running or not. That is, whether it is on a cpu or is blocked. The
monarch has to determine whether or not a task is on a cpu before it
knows how to start unwinding it. The tasks that received an MCA or
INIT event are no longer running, they have been converted to blocked
tasks. But (and its a big but), the cpus that received the MCA
rendezvous interrupt are still running on their normal kernel stacks!
* To distinguish between these two cases, the monarch must know which
tasks are on a cpu and which are not. Hence each slave cpu that
switches to an MCA/INIT stack, registers its new stack using
set_curr_task(), so the monarch can tell that the _original_ task is
no longer running on that cpu. That gives us a decent chance of
getting a valid backtrace of the _original_ task.
* MCA/INIT can be nested, to a depth of 2 on any cpu. In the case of a
nested error, we want diagnostics on the MCA/INIT handler that
failed, not on the task that was originally running. Again this
requires set_curr_task() so the MCA/INIT handlers can register their
own stack as running on that cpu. Then a recursive error gets a
trace of the failing handler's "task".
[1]
My (Keith Owens) original design called for ia64 to separate its
struct task and the kernel stacks. Then the MCA/INIT data would be
chained stacks like i386 interrupt stacks. But that required
radical surgery on the rest of ia64, plus extra hard wired TLB
entries with its associated performance degradation. David
Mosberger vetoed that approach. Which meant that separate kernel
stacks meant separate "tasks" for the MCA/INIT handlers.
---
INIT is less complicated than MCA. Pressing the nmi button or using
the equivalent command on the management console sends INIT to all
cpus. SAL picks one of the cpus as the monarch and the rest are
slaves. All the OS INIT handlers are entered at approximately the same
time. The OS monarch prints the state of all tasks and returns, after
which the slaves return and the system resumes.
At least that is what is supposed to happen. Alas there are broken
versions of SAL out there. Some drive all the cpus as monarchs. Some
drive them all as slaves. Some drive one cpu as monarch, wait for that
cpu to return from the OS then drive the rest as slaves. Some versions
of SAL cannot even cope with returning from the OS, they spin inside
SAL on resume. The OS INIT code has workarounds for some of these
broken SAL symptoms, but some simply cannot be fixed from the OS side.
---
The scheduler hooks used by ia64 (curr_task, set_curr_task) are layer
violations. Unfortunately MCA/INIT start off as massive layer
violations (can occur at _any_ time) and they build from there.
At least ia64 makes an attempt at recovering from hardware errors, but
it is a difficult problem because of the asynchronous nature of these
errors. When processing an unmaskable interrupt we sometimes need
special code to cope with our inability to take any locks.
---
How is ia64 MCA/INIT different from x86 NMI?
* x86 NMI typically gets delivered to one cpu. MCA/INIT gets sent to
all cpus.
* x86 NMI cannot be nested. MCA/INIT can be nested, to a depth of 2
per cpu.
* x86 has a separate struct task which points to one of multiple kernel
stacks. ia64 has the struct task embedded in the single kernel
stack, so switching stack means switching task.
* x86 does not call the BIOS so the NMI handler does not have to worry
about any registers having changed. MCA/INIT can occur while the cpu
is in PAL in physical mode, with undefined registers and an undefined
kernel stack.
* i386 backtrace is not very sensitive to whether a process is running
or not. ia64 unwind is very, very sensitive to whether a process is
running or not.
---
What happens when MCA/INIT is delivered what a cpu is running user
space code?
The user mode registers are stored in the RSE area of the MCA/INIT on
entry to the OS and are restored from there on return to SAL, so user
mode registers are preserved across a recoverable MCA/INIT. Since the
OS has no idea what unwind data is available for the user space stack,
MCA/INIT never tries to backtrace user space. Which means that the OS
does not bother making the user space process look like a blocked task,
i.e. the OS does not copy pt_regs and switch_stack to the user space
stack. Also the OS has no idea how big the user space RSE and memory
stacks are, which makes it too risky to copy the saved state to a user
mode stack.
---
How do we get a backtrace on the tasks that were running when MCA/INIT
was delivered?
mca.c:::ia64_mca_modify_original_stack(). That identifies and
verifies the original kernel stack, copies the dirty registers from
the MCA/INIT stack's RSE to the original stack's RSE, copies the
skeleton struct pt_regs and switch_stack to the original stack, fills
in the skeleton structures from the PAL minstate area and updates the
original stack's thread.ksp. That makes the original stack look
exactly like any other blocked task, i.e. it now appears to be
sleeping. To get a backtrace, just start with thread.ksp for the
original task and unwind like any other sleeping task.
---
How do we identify the tasks that were running when MCA/INIT was
delivered?
If the previous task has been verified and converted to a blocked
state, then sos->prev_task on the MCA/INIT stack is updated to point to
the previous task. You can look at that field in dumps or debuggers.
To help distinguish between the handler and the original tasks,
handlers have _TIF_MCA_INIT set in thread_info.flags.
The sos data is always in the MCA/INIT handler stack, at offset
MCA_SOS_OFFSET. You can get that value from mca_asm.h or calculate it
as KERNEL_STACK_SIZE - sizeof(struct pt_regs) - sizeof(struct
ia64_sal_os_state), with 16 byte alignment for all structures.
Also the comm field of the MCA/INIT task is modified to include the pid
of the original task, for humans to use. For example, a comm field of
'MCA 12159' means that pid 12159 was running when the MCA was
delivered.
Documentation/arch/ia64/serial.rst
-165
View File
@@ -1,165 +0,0 @@
==============
Serial Devices
==============
Serial Device Naming
====================
As of 2.6.10, serial devices on ia64 are named based on the
order of ACPI and PCI enumeration. The first device in the
ACPI namespace (if any) becomes /dev/ttyS0, the second becomes
/dev/ttyS1, etc., and PCI devices are named sequentially
starting after the ACPI devices.
Prior to 2.6.10, there were confusing exceptions to this:
- Firmware on some machines (mostly from HP) provides an HCDP
table[1] that tells the kernel about devices that can be used
as a serial console. If the user specified "console=ttyS0"
or the EFI ConOut path contained only UART devices, the
kernel registered the device described by the HCDP as
/dev/ttyS0.
- If there was no HCDP, we assumed there were UARTs at the
legacy COM port addresses (I/O ports 0x3f8 and 0x2f8), so
the kernel registered those as /dev/ttyS0 and /dev/ttyS1.
Any additional ACPI or PCI devices were registered sequentially
after /dev/ttyS0 as they were discovered.
With an HCDP, device names changed depending on EFI configuration
and "console=" arguments. Without an HCDP, device names didn't
change, but we registered devices that might not really exist.
For example, an HP rx1600 with a single built-in serial port
(described in the ACPI namespace) plus an MP[2] (a PCI device) has
these ports:
========== ========== ============ ============ =======
Type MMIO pre-2.6.10 pre-2.6.10 2.6.10+
address
(EFI console (EFI console
on builtin) on MP port)
========== ========== ============ ============ =======
builtin 0xff5e0000 ttyS0 ttyS1 ttyS0
MP UPS 0xf8031000 ttyS1 ttyS2 ttyS1
MP Console 0xf8030000 ttyS2 ttyS0 ttyS2
MP 2 0xf8030010 ttyS3 ttyS3 ttyS3
MP 3 0xf8030038 ttyS4 ttyS4 ttyS4
========== ========== ============ ============ =======
Console Selection
=================
EFI knows what your console devices are, but it doesn't tell the
kernel quite enough to actually locate them. The DIG64 HCDP
table[1] does tell the kernel where potential serial console
devices are, but not all firmware supplies it. Also, EFI supports
multiple simultaneous consoles and doesn't tell the kernel which
should be the "primary" one.
So how do you tell Linux which console device to use?
- If your firmware supplies the HCDP, it is simplest to
configure EFI with a single device (either a UART or a VGA
card) as the console. Then you don't need to tell Linux
anything; the kernel will automatically use the EFI console.
(This works only in 2.6.6 or later; prior to that you had
to specify "console=ttyS0" to get a serial console.)
- Without an HCDP, Linux defaults to a VGA console unless you
specify a "console=" argument.
NOTE: Don't assume that a serial console device will be /dev/ttyS0.
It might be ttyS1, ttyS2, etc. Make sure you have the appropriate
entries in /etc/inittab (for getty) and /etc/securetty (to allow
root login).
Early Serial Console
====================
The kernel can't start using a serial console until it knows where
the device lives. Normally this happens when the driver enumerates
all the serial devices, which can happen a minute or more after the
kernel starts booting.
2.6.10 and later kernels have an "early uart" driver that works
very early in the boot process. The kernel will automatically use
this if the user supplies an argument like "console=uart,io,0x3f8",
or if the EFI console path contains only a UART device and the
firmware supplies an HCDP.
Troubleshooting Serial Console Problems
=======================================
No kernel output after elilo prints "Uncompressing Linux... done":
- You specified "console=ttyS0" but Linux changed the device
to which ttyS0 refers. Configure exactly one EFI console
device[3] and remove the "console=" option.
- The EFI console path contains both a VGA device and a UART.
EFI and elilo use both, but Linux defaults to VGA. Remove
the VGA device from the EFI console path[3].
- Multiple UARTs selected as EFI console devices. EFI and
elilo use all selected devices, but Linux uses only one.
Make sure only one UART is selected in the EFI console
path[3].
- You're connected to an HP MP port[2] but have a non-MP UART
selected as EFI console device. EFI uses the MP as a
console device even when it isn't explicitly selected.
Either move the console cable to the non-MP UART, or change
the EFI console path[3] to the MP UART.
Long pause (60+ seconds) between "Uncompressing Linux... done" and
start of kernel output:
- No early console because you used "console=ttyS<n>". Remove
the "console=" option if your firmware supplies an HCDP.
- If you don't have an HCDP, the kernel doesn't know where
your console lives until the driver discovers serial
devices. Use "console=uart,io,0x3f8" (or appropriate
address for your machine).
Kernel and init script output works fine, but no "login:" prompt:
- Add getty entry to /etc/inittab for console tty. Look for
the "Adding console on ttyS<n>" message that tells you which
device is the console.
"login:" prompt, but can't login as root:
- Add entry to /etc/securetty for console tty.
No ACPI serial devices found in 2.6.17 or later:
- Turn on CONFIG_PNP and CONFIG_PNPACPI. Prior to 2.6.17, ACPI
serial devices were discovered by 8250_acpi. In 2.6.17,
8250_acpi was replaced by the combination of 8250_pnp and
CONFIG_PNPACPI.
[1]
http://www.dig64.org/specifications/agreement
The table was originally defined as the "HCDP" for "Headless
Console/Debug Port." The current version is the "PCDP" for
"Primary Console and Debug Port Devices."
[2]
The HP MP (management processor) is a PCI device that provides
several UARTs. One of the UARTs is often used as a console; the
EFI Boot Manager identifies it as "Acpi(HWP0002,700)/Pci(...)/Uart".
The external connection is usually a 25-pin connector, and a
special dongle converts that to three 9-pin connectors, one of
which is labelled "Console."
[3]
EFI console devices are configured using the EFI Boot Manager
"Boot option maintenance" menu. You may have to interrupt the
boot sequence to use this menu, and you will have to reset the
box after changing console configuration.
Documentation/arch/index.rst
+2 -3
View File
@@ -12,15 +12,14 @@ implementation.
arc/index
arm/index
arm64/index
ia64/index
loongarch/index
m68k/index
mips/index
nios2/index
openrisc/index
parisc/index
../powerpc/index
../riscv/index
powerpc/index
riscv/index
s390/index
sh/index
sparc/index
Documentation/arch/loongarch/introduction.rst
+4 -4
View File
@@ -375,15 +375,15 @@ Developer web site of Loongson and LoongArch (Software and Documentation):
Documentation of LoongArch ISA:
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-EN.pdf (in English)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-EN.pdf (in English)
Documentation of LoongArch ELF psABI:
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.01-CN.pdf (in Chinese)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.00-EN.pdf (in English)
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-ELF-ABI-v2.01-EN.pdf (in English)
Linux kernel repository of Loongson and LoongArch:
Documentation/powerpc/associativity.rst → Documentation/arch/powerpc/associativity.rst
View File
Documentation/powerpc/booting.rst → Documentation/arch/powerpc/booting.rst
View File
Documentation/powerpc/bootwrapper.rst → Documentation/arch/powerpc/bootwrapper.rst
View File
Documentation/powerpc/cpu_families.rst → Documentation/arch/powerpc/cpu_families.rst
View File
Documentation/powerpc/cpu_features.rst → Documentation/arch/powerpc/cpu_features.rst
View File
Documentation/powerpc/cxl.rst → Documentation/arch/powerpc/cxl.rst
View File
Documentation/powerpc/cxlflash.rst → Documentation/arch/powerpc/cxlflash.rst
+1 -1
View File
@@ -32,7 +32,7 @@ Introduction
responsible for the initialization of the adapter, setting up the
special path for user space access, and performing error recovery. It
communicates directly the Flash Accelerator Functional Unit (AFU)
as described in Documentation/powerpc/cxl.rst.
as described in Documentation/arch/powerpc/cxl.rst.
The cxlflash driver supports two, mutually exclusive, modes of
operation at the device (LUN) level:
Documentation/powerpc/dawr-power9.rst → Documentation/arch/powerpc/dawr-power9.rst
View File
Documentation/powerpc/dexcr.rst → Documentation/arch/powerpc/dexcr.rst
View File

Some files were not shown because too many files have changed in this diff Show More