mirror of
https://github.com/nxp-imx/linux-imx.git
synced 2025-07-19 15:50:12 +02:00
Compare commits
No commits in common. "android-15.0.0_1.2.0" and "lf-6.6.y" have entirely different histories.
android-15
...
lf-6.6.y
1
.gitignore
vendored
1
.gitignore
vendored
|
|
@ -135,6 +135,7 @@ GTAGS
|
|||
# id-utils files
|
||||
ID
|
||||
|
||||
*.orig
|
||||
*~
|
||||
\#*#
|
||||
|
||||
|
|
|
|||
2446
BUILD.bazel
2446
BUILD.bazel
File diff suppressed because it is too large
Load Diff
|
|
@ -45,21 +45,3 @@ Date: Jun 2005
|
|||
Description:
|
||||
If the module source has MODULE_VERSION, this file will contain
|
||||
the version of the source code.
|
||||
|
||||
What: /sys/module/MODULENAME/scmversion
|
||||
Date: November 2020
|
||||
KernelVersion: 5.12
|
||||
Contact: Will McVicker <willmcvicker@google.com>
|
||||
Description: This read-only file will appear if modpost was supplied with an
|
||||
SCM version for the module. It can be enabled with the config
|
||||
MODULE_SCMVERSION. The SCM version is retrieved by
|
||||
scripts/setlocalversion, which means that the presence of this
|
||||
file depends on CONFIG_LOCALVERSION_AUTO=y. When read, the SCM
|
||||
version that the module was compiled with is returned. The SCM
|
||||
version is returned in the following format::
|
||||
|
||||
===
|
||||
Git: g[a-f0-9]\+(-dirty)\?
|
||||
Mercurial: hg[a-f0-9]\+(-dirty)\?
|
||||
Subversion: svn[0-9]\+
|
||||
===
|
||||
|
|
|
|||
|
|
@ -342,70 +342,6 @@ Description: Specific uncompressed frame descriptors
|
|||
support
|
||||
========================= =====================================
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased
|
||||
Date: Sept 2024
|
||||
KernelVersion: 5.15
|
||||
Description: Framebased format descriptors
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased/name
|
||||
Date: Sept 2024
|
||||
KernelVersion: 5.15
|
||||
Description: Specific framebased format descriptors
|
||||
|
||||
================== =======================================
|
||||
bFormatIndex unique id for this format descriptor;
|
||||
only defined after parent header is
|
||||
linked into the streaming class;
|
||||
read-only
|
||||
bmaControls this format's data for bmaControls in
|
||||
the streaming header
|
||||
bmInterlaceFlags specifies interlace information,
|
||||
read-only
|
||||
bAspectRatioY the X dimension of the picture aspect
|
||||
ratio, read-only
|
||||
bAspectRatioX the Y dimension of the picture aspect
|
||||
ratio, read-only
|
||||
bDefaultFrameIndex optimum frame index for this stream
|
||||
bBitsPerPixel number of bits per pixel used to
|
||||
specify color in the decoded video
|
||||
frame
|
||||
guidFormat globally unique id used to identify
|
||||
stream-encoding format
|
||||
================== =======================================
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/framebased/name/name
|
||||
Date: Sept 2024
|
||||
KernelVersion: 5.15
|
||||
Description: Specific framebased frame descriptors
|
||||
|
||||
========================= =====================================
|
||||
bFrameIndex unique id for this framedescriptor;
|
||||
only defined after parent format is
|
||||
linked into the streaming header;
|
||||
read-only
|
||||
dwFrameInterval indicates how frame interval can be
|
||||
programmed; a number of values
|
||||
separated by newline can be specified
|
||||
dwDefaultFrameInterval the frame interval the device would
|
||||
like to use as default
|
||||
dwBytesPerLine Specifies the number of bytes per line
|
||||
of video for packed fixed frame size
|
||||
formats, allowing the receiver to
|
||||
perform stride alignment of the video.
|
||||
If the bVariableSize value (above) is
|
||||
TRUE (1), or if the format does not
|
||||
permit such alignment, this value shall
|
||||
be set to zero (0).
|
||||
dwMaxBitRate the maximum bit rate at the shortest
|
||||
frame interval in bps
|
||||
dwMinBitRate the minimum bit rate at the longest
|
||||
frame interval in bps
|
||||
wHeight height of decoded bitmap frame in px
|
||||
wWidth width of decoded bitmam frame in px
|
||||
bmCapabilities still image support, fixed frame-rate
|
||||
support
|
||||
========================= =====================================
|
||||
|
||||
What: /config/usb-gadget/gadget/functions/uvc.name/streaming/header
|
||||
Date: Dec 2014
|
||||
KernelVersion: 4.0
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ KernelVersion:
|
|||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reading this returns the valid values that can be written to the
|
||||
filter_mode attribute:
|
||||
on_altvoltage0_mode attribute:
|
||||
|
||||
- auto -> Adjust bandpass filter to track changes in input clock rate.
|
||||
- manual -> disable/unregister the clock rate notifier / input clock tracking.
|
||||
|
|
|
|||
|
|
@ -1,32 +0,0 @@
|
|||
Android USB devices (eg. /sys/class/android_usb/android0/)
|
||||
|
||||
What: /sys/class/android_usb/<android_device>/state
|
||||
Date: Feb 2024
|
||||
Contact: Neill Kapron <nkapron@google.com>
|
||||
Description:
|
||||
The state of the USB connection. This attribute is likely
|
||||
redundant with the /sys/class/UDC/state attribute, and should
|
||||
be deprecated/removed when userspace can be refactored.
|
||||
Change on the state will also generate uevent KOBJ_CHANGE on
|
||||
the port with the new state included in the message as
|
||||
"USB_STATE=<STATE>". Note this is not the correct usage of
|
||||
uevents, but necessary due to the requirement to maintaine
|
||||
userspace API compatibility.
|
||||
|
||||
Valid values: CONNECTED, DISCONNECTED, CONFIGURED
|
||||
|
||||
Android USB MIDI Function devices (eg. /sys/class/android_usb/androidN/f_midi/)
|
||||
|
||||
What: /sys/class/android_usb/<android_device>/f_midi/alsa
|
||||
Date: Feb 2024
|
||||
Contact Neill Kapron <nkapron@google.com>
|
||||
Description:
|
||||
The PCM card and device numbers created by the f_midi driver.
|
||||
This is not the correct use of sysfs due to passing multiple
|
||||
values through a single file, which is directly against the
|
||||
"one value per file" nature of sysfs, however Android userspace
|
||||
code currently relies on this functionality as-is.
|
||||
|
||||
Valid values: card and device numbers in the format of
|
||||
<PCM_card_number> <device number>", or "-1 -1" if the attr
|
||||
is read prior to binding the f_midi device.
|
||||
|
|
@ -920,16 +920,14 @@ Description: This file shows whether the configuration descriptor is locked.
|
|||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_number_of_rtt
|
||||
What: /sys/bus/platform/devices/*.ufs/attributes/max_number_of_rtt
|
||||
Date: May 2024
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Date: February 2018
|
||||
Contact: Stanislav Nijnikov <stanislav.nijnikov@wdc.com>
|
||||
Description: This file provides the maximum current number of
|
||||
outstanding RTTs in device that is allowed. bMaxNumOfRTT is a
|
||||
read-write persistent attribute and is equal to two after device
|
||||
manufacturing. It shall not be set to a value greater than
|
||||
bDeviceRTTCap value, and it may be set only when the hw queues are
|
||||
empty.
|
||||
outstanding RTTs in device that is allowed. The full
|
||||
information about the attribute could be found at
|
||||
UFS specifications 2.1.
|
||||
|
||||
The file is read write.
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/exception_event_control
|
||||
What: /sys/bus/platform/devices/*.ufs/attributes/exception_event_control
|
||||
|
|
|
|||
|
|
@ -311,13 +311,10 @@ Description: Do background GC aggressively when set. Set to 0 by default.
|
|||
GC approach and turns SSR mode on.
|
||||
gc urgent low(2): lowers the bar of checking I/O idling in
|
||||
order to process outstanding discard commands and GC a
|
||||
little bit aggressively. always uses cost benefit GC approach,
|
||||
and will override age-threshold GC approach if ATGC is enabled
|
||||
at the same time.
|
||||
little bit aggressively. uses cost benefit GC approach.
|
||||
gc urgent mid(3): does GC forcibly in a period of given
|
||||
gc_urgent_sleep_time and executes a mid level of I/O idling check.
|
||||
always uses cost benefit GC approach, and will override
|
||||
age-threshold GC approach if ATGC is enabled at the same time.
|
||||
uses cost benefit GC approach.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time
|
||||
Date: August 2017
|
||||
|
|
@ -334,7 +331,7 @@ Date: January 2018
|
|||
Contact: Jaegeuk Kim <jaegeuk@kernel.org>
|
||||
Description: This indicates how many GC can be failed for the pinned
|
||||
file. If it exceeds this, F2FS doesn't guarantee its pinning
|
||||
state. 2048 trials is set by default, and 65535 as maximum.
|
||||
state. 2048 trials is set by default.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/extension_list
|
||||
Date: February 2018
|
||||
|
|
@ -501,21 +498,6 @@ Description: Show status of f2fs checkpoint in real time.
|
|||
CP_RESIZEFS_FLAG 0x00004000
|
||||
=============================== ==============================
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/stat/issued_discard
|
||||
Date: December 2023
|
||||
Contact: "Zhiguo Niu" <zhiguo.niu@unisoc.com>
|
||||
Description: Shows the number of issued discard.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/stat/queued_discard
|
||||
Date: December 2023
|
||||
Contact: "Zhiguo Niu" <zhiguo.niu@unisoc.com>
|
||||
Description: Shows the number of queued discard.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/stat/undiscard_blks
|
||||
Date: December 2023
|
||||
Contact: "Zhiguo Niu" <zhiguo.niu@unisoc.com>
|
||||
Description: Shows the total number of undiscard blocks.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/ckpt_thread_ioprio
|
||||
Date: January 2021
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
|
|
@ -582,12 +564,6 @@ Description: When ATGC is on, it controls age threshold to bypass GCing young
|
|||
candidates whose age is not beyond the threshold, by default it was
|
||||
initialized as 604800 seconds (equals to 7 days).
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/atgc_enabled
|
||||
Date: Feb 2024
|
||||
Contact: "Jinbao Liu" <liujinbao1@xiaomi.com>
|
||||
Description: It represents whether ATGC is on or off. The value is 1 which
|
||||
indicates that ATGC is on, and 0 indicates that it is off.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_reclaimed_segments
|
||||
Date: July 2021
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
|
|
@ -710,31 +686,29 @@ Description: Support configuring fault injection type, should be
|
|||
enabled with fault_injection option, fault type value
|
||||
is shown below, it supports single or combined type.
|
||||
|
||||
=========================== ===========
|
||||
Type_Name Type_Value
|
||||
=========================== ===========
|
||||
FAULT_KMALLOC 0x000000001
|
||||
FAULT_KVMALLOC 0x000000002
|
||||
FAULT_PAGE_ALLOC 0x000000004
|
||||
FAULT_PAGE_GET 0x000000008
|
||||
FAULT_ALLOC_BIO 0x000000010 (obsolete)
|
||||
FAULT_ALLOC_NID 0x000000020
|
||||
FAULT_ORPHAN 0x000000040
|
||||
FAULT_BLOCK 0x000000080
|
||||
FAULT_DIR_DEPTH 0x000000100
|
||||
FAULT_EVICT_INODE 0x000000200
|
||||
FAULT_TRUNCATE 0x000000400
|
||||
FAULT_READ_IO 0x000000800
|
||||
FAULT_CHECKPOINT 0x000001000
|
||||
FAULT_DISCARD 0x000002000
|
||||
FAULT_WRITE_IO 0x000004000
|
||||
FAULT_SLAB_ALLOC 0x000008000
|
||||
FAULT_DQUOT_INIT 0x000010000
|
||||
FAULT_LOCK_OP 0x000020000
|
||||
FAULT_BLKADDR_VALIDITY 0x000040000
|
||||
FAULT_BLKADDR_CONSISTENCE 0x000080000
|
||||
FAULT_NO_SEGMENT 0x000100000
|
||||
=========================== ===========
|
||||
=================== ===========
|
||||
Type_Name Type_Value
|
||||
=================== ===========
|
||||
FAULT_KMALLOC 0x000000001
|
||||
FAULT_KVMALLOC 0x000000002
|
||||
FAULT_PAGE_ALLOC 0x000000004
|
||||
FAULT_PAGE_GET 0x000000008
|
||||
FAULT_ALLOC_BIO 0x000000010 (obsolete)
|
||||
FAULT_ALLOC_NID 0x000000020
|
||||
FAULT_ORPHAN 0x000000040
|
||||
FAULT_BLOCK 0x000000080
|
||||
FAULT_DIR_DEPTH 0x000000100
|
||||
FAULT_EVICT_INODE 0x000000200
|
||||
FAULT_TRUNCATE 0x000000400
|
||||
FAULT_READ_IO 0x000000800
|
||||
FAULT_CHECKPOINT 0x000001000
|
||||
FAULT_DISCARD 0x000002000
|
||||
FAULT_WRITE_IO 0x000004000
|
||||
FAULT_SLAB_ALLOC 0x000008000
|
||||
FAULT_DQUOT_INIT 0x000010000
|
||||
FAULT_LOCK_OP 0x000020000
|
||||
FAULT_BLKADDR 0x000040000
|
||||
=================== ===========
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/discard_io_aware_gran
|
||||
Date: January 2023
|
||||
|
|
@ -766,65 +740,3 @@ Description: When compress cache is on, it controls cached page
|
|||
If cached page percent exceed threshold, then deny caching compress page.
|
||||
The value should be in range of (0, 100], by default it was initialized
|
||||
as 20(%).
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/discard_io_aware
|
||||
Date: November 2023
|
||||
Contact: "Chao Yu" <chao@kernel.org>
|
||||
Description: It controls to enable/disable IO aware feature for background discard.
|
||||
By default, the value is 1 which indicates IO aware is on.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/blkzone_alloc_policy
|
||||
Date: July 2024
|
||||
Contact: "Yuanhong Liao" <liaoyuanhong@vivo.com>
|
||||
Description: The zone UFS we are currently using consists of two parts:
|
||||
conventional zones and sequential zones. It can be used to control which part
|
||||
to prioritize for writes, with a default value of 0.
|
||||
|
||||
======================== =========================================
|
||||
value description
|
||||
blkzone_alloc_policy = 0 Prioritize writing to sequential zones
|
||||
blkzone_alloc_policy = 1 Only allow writing to sequential zones
|
||||
blkzone_alloc_policy = 2 Prioritize writing to conventional zones
|
||||
======================== =========================================
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/migration_window_granularity
|
||||
Date: September 2024
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: Controls migration window granularity of garbage collection on large
|
||||
section. it can control the scanning window granularity for GC migration
|
||||
in a unit of segment, while migration_granularity controls the number
|
||||
of segments which can be migrated at the same turn.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/reserved_segments
|
||||
Date: September 2024
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: In order to fine tune GC behavior, we can control the number of
|
||||
reserved segments.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_no_zoned_gc_percent
|
||||
Date: September 2024
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: If the percentage of free sections over total sections is above this
|
||||
number, F2FS do not garbage collection for zoned devices through the
|
||||
background GC thread. the default number is "60".
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_boost_zoned_gc_percent
|
||||
Date: September 2024
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: If the percentage of free sections over total sections is under this
|
||||
number, F2FS boosts garbage collection for zoned devices through the
|
||||
background GC thread. the default number is "25".
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_valid_thresh_ratio
|
||||
Date: September 2024
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: It controls the valid block ratio threshold not to trigger excessive GC
|
||||
for zoned deivces. The initial value of it is 95(%). F2FS will stop the
|
||||
background GC thread from intiating GC for sections having valid blocks
|
||||
exceeding the ratio.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/max_read_extent_count
|
||||
Date: November 2024
|
||||
Contact: "Chao Yu" <chao@kernel.org>
|
||||
Description: It controls max read extent count for per-inode, the value of threshold
|
||||
is 10240 by default.
|
||||
|
|
|
|||
|
|
@ -1,19 +0,0 @@
|
|||
What: /sys/fs/fuse/features/fuse_bpf
|
||||
Date: December 2022
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description:
|
||||
Read-only file that contains the word 'supported' if fuse-bpf is
|
||||
supported, does not exist otherwise
|
||||
|
||||
What: /sys/fs/fuse/bpf_prog_type_fuse
|
||||
Date: December 2022
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description:
|
||||
bpf_prog_type_fuse defines the program type of bpf programs that
|
||||
may be passed to fuse-bpf. For upstream bpf program types, this
|
||||
is a constant defined in a contiguous array of constants.
|
||||
bpf_prog_type_fuse is appended to the end of the list, so it may
|
||||
change and therefore its value must be read from this file.
|
||||
|
||||
Contents is ASCII decimal representation of bpf_prog_type_fuse
|
||||
|
||||
|
|
@ -1,70 +0,0 @@
|
|||
What: /sys/fs/incremental-fs/features/corefs
|
||||
Date: 2019
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Reads 'supported'. Always present.
|
||||
|
||||
What: /sys/fs/incremental-fs/features/v2
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Reads 'supported'. Present if all v2 features of incfs are
|
||||
supported.
|
||||
|
||||
What: /sys/fs/incremental-fs/features/zstd
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Reads 'supported'. Present if zstd compression is supported
|
||||
for data blocks.
|
||||
|
||||
What: /sys/fs/incremental-fs/features/bugfix_throttling
|
||||
Date: January 2023
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Reads 'supported'. Present if the throttling lock bug is fixed
|
||||
https://android-review.git.corp.google.com/c/kernel/common/+/2381827
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Folder created when incfs is mounted with the sysfs_name=[name]
|
||||
option. If this option is used, the following values are created
|
||||
in this folder.
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_min
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Returns a count of the number of reads that were delayed as a
|
||||
result of the per UID read timeouts min time setting.
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_min_us
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Returns total delay time for all files since first mount as a
|
||||
result of the per UID read timeouts min time setting.
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_pending
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Returns a count of the number of reads that were delayed as a
|
||||
result of waiting for a pending read.
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]/reads_delayed_pending_us
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Returns total delay time for all files since first mount as a
|
||||
result of waiting for a pending read.
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]/reads_failed_hash_verification
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Returns number of reads that failed because of hash verification
|
||||
failures.
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]/reads_failed_other
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Returns number of reads that failed for reasons other than
|
||||
timing out or hash failures.
|
||||
|
||||
What: /sys/fs/incremental-fs/instances/[name]/reads_failed_timed_out
|
||||
Date: April 2021
|
||||
Contact: Paul Lawrence <paullawrence@google.com>
|
||||
Description: Returns number of reads that timed out.
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
What: /sys/kernel/dma_heap/total_pools_kb
|
||||
Date: Feb 2021
|
||||
KernelVersion: 5.10
|
||||
Contact: T.J. Mercier <tjmercier@google.com>
|
||||
Description:
|
||||
The total_pools_kb file is read-only and specifies how much
|
||||
memory in KiB is allocated to DMA-BUF heap pools.
|
||||
|
|
@ -1,18 +0,0 @@
|
|||
What: /sys/kernel/mm/transparent_hugepage/
|
||||
Date: April 2024
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description:
|
||||
/sys/kernel/mm/transparent_hugepage/ contains a number of files and
|
||||
subdirectories,
|
||||
|
||||
- defrag
|
||||
- enabled
|
||||
- hpage_pmd_size
|
||||
- khugepaged
|
||||
- shmem_enabled
|
||||
- use_zero_page
|
||||
- subdirectories of the form hugepages-<size>kB, where <size>
|
||||
is the page size of the hugepages supported by the kernel/CPU
|
||||
combination.
|
||||
|
||||
See Documentation/admin-guide/mm/transhuge.rst for details.
|
||||
|
|
@ -1,16 +0,0 @@
|
|||
What: /sys/kernel/wakeup_reasons/last_resume_reason
|
||||
Date: February 2014
|
||||
Contact: Ruchi Kandoi <kandoiruchi@google.com>
|
||||
Description:
|
||||
The /sys/kernel/wakeup_reasons/last_resume_reason is
|
||||
used to report wakeup reasons after system exited suspend.
|
||||
|
||||
What: /sys/kernel/wakeup_reasons/last_suspend_time
|
||||
Date: March 2015
|
||||
Contact: jinqian <jinqian@google.com>
|
||||
Description:
|
||||
The /sys/kernel/wakeup_reasons/last_suspend_time is
|
||||
used to report time spent in last suspend cycle. It contains
|
||||
two numbers (in seconds) separated by space. First number is
|
||||
the time spent in suspend and resume processes. Second number
|
||||
is the time spent in sleep state.
|
||||
|
|
@ -1067,10 +1067,6 @@
|
|||
can be useful when debugging issues that require an SLB
|
||||
miss to occur.
|
||||
|
||||
disable_dma32= [KNL]
|
||||
Dynamically disable ZONE_DMA32 on kernels compiled with
|
||||
CONFIG_ZONE_DMA32=y.
|
||||
|
||||
disable= [IPV6]
|
||||
See Documentation/networking/ipv6.rst.
|
||||
|
||||
|
|
@ -1565,28 +1561,12 @@
|
|||
The above will cause the "foo" tracing instance to trigger
|
||||
a snapshot at the end of boot up.
|
||||
|
||||
ftrace_dump_on_oops[=2(orig_cpu) | =<instance>][,<instance> |
|
||||
,<instance>=2(orig_cpu)]
|
||||
ftrace_dump_on_oops[=orig_cpu]
|
||||
[FTRACE] will dump the trace buffers on oops.
|
||||
If no parameter is passed, ftrace will dump global
|
||||
buffers of all CPUs, if you pass 2 or orig_cpu, it
|
||||
will dump only the buffer of the CPU that triggered
|
||||
the oops, or the specific instance will be dumped if
|
||||
its name is passed. Multiple instance dump is also
|
||||
supported, and instances are separated by commas. Each
|
||||
instance supports only dump on CPU that triggered the
|
||||
oops by passing 2 or orig_cpu to it.
|
||||
|
||||
ftrace_dump_on_oops=foo=orig_cpu
|
||||
|
||||
The above will dump only the buffer of "foo" instance
|
||||
on CPU that triggered the oops.
|
||||
|
||||
ftrace_dump_on_oops,foo,bar=orig_cpu
|
||||
|
||||
The above will dump global buffer on all CPUs, the
|
||||
buffer of "foo" instance on all CPUs and the buffer
|
||||
of "bar" instance on CPU that triggered the oops.
|
||||
If no parameter is passed, ftrace will dump
|
||||
buffers of all CPUs, but if you pass orig_cpu, it will
|
||||
dump only the buffer of the CPU that triggered the
|
||||
oops.
|
||||
|
||||
ftrace_filter=[function-list]
|
||||
[FTRACE] Limit the functions traced by the function
|
||||
|
|
@ -1870,10 +1850,6 @@
|
|||
If specified, z/VM IUCV HVC accepts connections
|
||||
from listed z/VM user IDs only.
|
||||
|
||||
hvc_dcc.enable= [ARM,ARM64] Enable DCC driver at runtime. For GKI,
|
||||
disabled at runtime by default to prevent
|
||||
crashes in devices which do not support DCC.
|
||||
|
||||
hv_nopvspin [X86,HYPER_V] Disables the paravirt spinlock optimizations
|
||||
which allow the hypervisor to 'idle' the
|
||||
guest on lock contention.
|
||||
|
|
@ -2280,9 +2256,6 @@
|
|||
1 - Bypass the IOMMU for DMA.
|
||||
unset - Use value of CONFIG_IOMMU_DEFAULT_PASSTHROUGH.
|
||||
|
||||
ioremap_guard [ARM64] enable the KVM MMIO guard functionality
|
||||
if available.
|
||||
|
||||
io7= [HW] IO7 for Marvel-based Alpha systems
|
||||
See comment before marvel_specify_io7 in
|
||||
arch/alpha/kernel/core_marvel.c.
|
||||
|
|
@ -2571,7 +2544,7 @@
|
|||
CONFIG_KUNIT to be set to be fully enabled. The
|
||||
default value can be overridden via
|
||||
KUNIT_DEFAULT_ENABLED.
|
||||
Default is 0 (disabled)
|
||||
Default is 1 (enabled)
|
||||
|
||||
kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs.
|
||||
Default is 0 (don't ignore, but inject #GP)
|
||||
|
|
@ -2647,9 +2620,7 @@
|
|||
protected guests.
|
||||
|
||||
protected: nVHE-based mode with support for guests whose
|
||||
state is kept private from the host. See
|
||||
Documentation/virt/kvm/arm/pkvm.rst for more
|
||||
information about this mode of operation.
|
||||
state is kept private from the host.
|
||||
|
||||
nested: VHE-based mode with support for nested
|
||||
virtualization. Requires at least ARMv8.3
|
||||
|
|
@ -2660,13 +2631,6 @@
|
|||
for the host. "nested" is experimental and should be
|
||||
used with extreme caution.
|
||||
|
||||
kvm-arm.protected_modules=
|
||||
[KVM,ARM] List of pKVM modules to load before the host
|
||||
is deprevileged.
|
||||
|
||||
This option only applies when booting with
|
||||
kvm-arm.mode=protected.
|
||||
|
||||
kvm-arm.vgic_v3_group0_trap=
|
||||
[KVM,ARM] Trap guest accesses to GICv3 group-0
|
||||
system registers
|
||||
|
|
@ -3506,16 +3470,6 @@
|
|||
allocations which rules out almost all kernel
|
||||
allocations. Use with caution!
|
||||
|
||||
nosplit=X,Y [MM] Set the minimum order of the nosplit zone. Pages in
|
||||
this zone can't be split down below order Y, while free
|
||||
or in use.
|
||||
Like movablecore, X should be either nn[KMGTPE] or n%.
|
||||
|
||||
nomerge=X,Y [MM] Set the exact orders of the nomerge zone. Pages in
|
||||
this zone are always order Y, meaning they can't be
|
||||
split or merged while free or in use.
|
||||
Like movablecore, X should be either nn[KMGTPE] or n%.
|
||||
|
||||
MTD_Partition= [MTD]
|
||||
Format: <name>,<region-number>,<size>,<offset>
|
||||
|
||||
|
|
@ -4685,16 +4639,6 @@
|
|||
printk.time= Show timing data prefixed to each printk message line
|
||||
Format: <bool> (1/Y/y=enable, 0/N/n=disable)
|
||||
|
||||
proc_mem.force_override= [KNL]
|
||||
Format: {always | ptrace | never}
|
||||
Traditionally /proc/pid/mem allows memory permissions to be
|
||||
overridden without restrictions. This option may be set to
|
||||
restrict that. Can be one of:
|
||||
- 'always': traditional behavior always allows mem overrides.
|
||||
- 'ptrace': only allow mem overrides for active ptracers.
|
||||
- 'never': never allow mem overrides.
|
||||
If not specified, default is the CONFIG_PROC_MEM_* choice.
|
||||
|
||||
processor.max_cstate= [HW,ACPI]
|
||||
Limit processor to maximum C-state
|
||||
max_cstate=9 overrides any DMI blacklist limit.
|
||||
|
|
@ -5015,11 +4959,6 @@
|
|||
this kernel boot parameter, forcibly setting it
|
||||
to zero.
|
||||
|
||||
rcutree.enable_rcu_lazy= [KNL]
|
||||
To save power, batch RCU callbacks and flush after
|
||||
delay, memory pressure or callback list growing too
|
||||
big.
|
||||
|
||||
rcuscale.gp_async= [KNL]
|
||||
Measure performance of asynchronous
|
||||
grace-period primitives such as call_rcu().
|
||||
|
|
@ -5297,21 +5236,6 @@
|
|||
rcutorture.verbose= [KNL]
|
||||
Enable additional printk() statements.
|
||||
|
||||
rcupdate.rcu_boot_end_delay= [KNL]
|
||||
Minimum time in milliseconds from the start of boot
|
||||
that must elapse before the boot sequence can be marked
|
||||
complete from RCU's perspective, after which RCU's
|
||||
behavior becomes more relaxed. The default value is also
|
||||
configurable via CONFIG_RCU_BOOT_END_DELAY.
|
||||
Userspace can also mark the boot as completed
|
||||
sooner by writing the time in milliseconds, say once
|
||||
userspace considers the system as booted, to:
|
||||
/sys/module/rcupdate/parameters/rcu_boot_end_delay
|
||||
Or even just writing a value of 0 to this sysfs node.
|
||||
The sysfs node can also be used to extend the delay
|
||||
to be larger than the default, assuming the marking
|
||||
of boot complete has not yet occurred.
|
||||
|
||||
rcupdate.rcu_cpu_stall_ftrace_dump= [KNL]
|
||||
Dump ftrace buffer after reporting RCU CPU
|
||||
stall warning.
|
||||
|
|
@ -6472,15 +6396,6 @@
|
|||
<deci-seconds>: poll all this frequency
|
||||
0: no polling (default)
|
||||
|
||||
thp_anon= [KNL]
|
||||
Format: <size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>
|
||||
state is one of "always", "madvise", "never" or "inherit".
|
||||
Control the default behavior of the system with respect
|
||||
to anonymous transparent hugepages.
|
||||
Can be used multiple times for multiple anon THP sizes.
|
||||
See Documentation/admin-guide/mm/transhuge.rst for more
|
||||
details.
|
||||
|
||||
threadirqs [KNL]
|
||||
Force threading of all interrupt handlers except those
|
||||
marked explicitly IRQF_NO_THREAD.
|
||||
|
|
@ -7223,15 +7138,6 @@
|
|||
threshold repeatedly. They are likely good
|
||||
candidates for using WQ_UNBOUND workqueues instead.
|
||||
|
||||
workqueue.cpu_intensive_warning_thresh=<uint>
|
||||
If CONFIG_WQ_CPU_INTENSIVE_REPORT is set, the kernel
|
||||
will report the work functions which violate the
|
||||
intensive_threshold_us repeatedly. In order to prevent
|
||||
spurious warnings, start printing only after a work
|
||||
function has violated this threshold number of times.
|
||||
|
||||
The default is 4 times. 0 disables the warning.
|
||||
|
||||
workqueue.power_efficient
|
||||
Per-cpu workqueues are generally preferred because
|
||||
they show better performance thanks to cache
|
||||
|
|
|
|||
|
|
@ -45,25 +45,10 @@ components:
|
|||
the two is using hugepages just because of the fact the TLB miss is
|
||||
going to run faster.
|
||||
|
||||
Modern kernels support "multi-size THP" (mTHP), which introduces the
|
||||
ability to allocate memory in blocks that are bigger than a base page
|
||||
but smaller than traditional PMD-size (as described above), in
|
||||
increments of a power-of-2 number of pages. mTHP can back anonymous
|
||||
memory (for example 16K, 32K, 64K, etc). These THPs continue to be
|
||||
PTE-mapped, but in many cases can still provide similar benefits to
|
||||
those outlined above: Page faults are significantly reduced (by a
|
||||
factor of e.g. 4, 8, 16, etc), but latency spikes are much less
|
||||
prominent because the size of each page isn't as huge as the PMD-sized
|
||||
variant and there is less memory to clear in each page fault. Some
|
||||
architectures also employ TLB compression mechanisms to squeeze more
|
||||
entries in when a set of PTEs are virtually and physically contiguous
|
||||
and approporiately aligned. In this case, TLB misses will occur less
|
||||
often.
|
||||
|
||||
THP can be enabled system wide or restricted to certain tasks or even
|
||||
memory ranges inside task's address space. Unless THP is completely
|
||||
disabled, there is ``khugepaged`` daemon that scans memory and
|
||||
collapses sequences of basic pages into PMD-sized huge pages.
|
||||
collapses sequences of basic pages into huge pages.
|
||||
|
||||
The THP behaviour is controlled via :ref:`sysfs <thp_sysfs>`
|
||||
interface and using madvise(2) and prctl(2) system calls.
|
||||
|
|
@ -110,40 +95,12 @@ Global THP controls
|
|||
Transparent Hugepage Support for anonymous memory can be entirely disabled
|
||||
(mostly for debugging purposes) or only enabled inside MADV_HUGEPAGE
|
||||
regions (to avoid the risk of consuming more memory resources) or enabled
|
||||
system wide. This can be achieved per-supported-THP-size with one of::
|
||||
|
||||
echo always >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
|
||||
echo madvise >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
|
||||
echo never >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
|
||||
|
||||
where <size> is the hugepage size being addressed, the available sizes
|
||||
for which vary by system.
|
||||
|
||||
For example::
|
||||
|
||||
echo always >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
|
||||
|
||||
Alternatively it is possible to specify that a given hugepage size
|
||||
will inherit the top-level "enabled" value::
|
||||
|
||||
echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/enabled
|
||||
|
||||
For example::
|
||||
|
||||
echo inherit >/sys/kernel/mm/transparent_hugepage/hugepages-2048kB/enabled
|
||||
|
||||
The top-level setting (for use with "inherit") can be set by issuing
|
||||
one of the following commands::
|
||||
system wide. This can be achieved with one of::
|
||||
|
||||
echo always >/sys/kernel/mm/transparent_hugepage/enabled
|
||||
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
|
||||
echo never >/sys/kernel/mm/transparent_hugepage/enabled
|
||||
|
||||
By default, PMD-sized hugepages have enabled="inherit" and all other
|
||||
hugepage sizes have enabled="never". If enabling multiple hugepage
|
||||
sizes, the kernel will select the most appropriate enabled size for a
|
||||
given allocation.
|
||||
|
||||
It's also possible to limit defrag efforts in the VM to generate
|
||||
anonymous hugepages in case they're not immediately free to madvise
|
||||
regions or to never try to defrag memory and simply fallback to regular
|
||||
|
|
@ -189,34 +146,25 @@ madvise
|
|||
never
|
||||
should be self-explanatory.
|
||||
|
||||
By default kernel tries to use huge, PMD-mappable zero page on read
|
||||
page fault to anonymous mapping. It's possible to disable huge zero
|
||||
page by writing 0 or enable it back by writing 1::
|
||||
By default kernel tries to use huge zero page on read page fault to
|
||||
anonymous mapping. It's possible to disable huge zero page by writing 0
|
||||
or enable it back by writing 1::
|
||||
|
||||
echo 0 >/sys/kernel/mm/transparent_hugepage/use_zero_page
|
||||
echo 1 >/sys/kernel/mm/transparent_hugepage/use_zero_page
|
||||
|
||||
Some userspace (such as a test program, or an optimized memory
|
||||
allocation library) may want to know the size (in bytes) of a
|
||||
PMD-mappable transparent hugepage::
|
||||
Some userspace (such as a test program, or an optimized memory allocation
|
||||
library) may want to know the size (in bytes) of a transparent hugepage::
|
||||
|
||||
cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
|
||||
|
||||
khugepaged will be automatically started when one or more hugepage
|
||||
sizes are enabled (either by directly setting "always" or "madvise",
|
||||
or by setting "inherit" while the top-level enabled is set to "always"
|
||||
or "madvise"), and it'll be automatically shutdown when the last
|
||||
hugepage size is disabled (either by directly setting "never", or by
|
||||
setting "inherit" while the top-level enabled is set to "never").
|
||||
khugepaged will be automatically started when
|
||||
transparent_hugepage/enabled is set to "always" or "madvise, and it'll
|
||||
be automatically shutdown if it's set to "never".
|
||||
|
||||
Khugepaged controls
|
||||
-------------------
|
||||
|
||||
.. note::
|
||||
khugepaged currently only searches for opportunities to collapse to
|
||||
PMD-sized THP and no attempt is made to collapse to other THP
|
||||
sizes.
|
||||
|
||||
khugepaged runs usually at low frequency so while one may not want to
|
||||
invoke defrag algorithms synchronously during the page faults, it
|
||||
should be worth invoking defrag at least in khugepaged. However it's
|
||||
|
|
@ -284,37 +232,13 @@ processes. Exceeding the number would block the collapse::
|
|||
|
||||
A higher value may increase memory footprint for some workloads.
|
||||
|
||||
Boot parameters
|
||||
===============
|
||||
Boot parameter
|
||||
==============
|
||||
|
||||
You can change the sysfs boot time default for the top-level "enabled"
|
||||
control by passing the parameter ``transparent_hugepage=always`` or
|
||||
``transparent_hugepage=madvise`` or ``transparent_hugepage=never`` to the
|
||||
kernel command line.
|
||||
|
||||
Alternatively, each supported anonymous THP size can be controlled by
|
||||
passing ``thp_anon=<size>,<size>[KMG]:<state>;<size>-<size>[KMG]:<state>``,
|
||||
where ``<size>`` is the THP size (must be a power of 2 of PAGE_SIZE and
|
||||
supported anonymous THP) and ``<state>`` is one of ``always``, ``madvise``,
|
||||
``never`` or ``inherit``.
|
||||
|
||||
For example, the following will set 16K, 32K, 64K THP to ``always``,
|
||||
set 128K, 512K to ``inherit``, set 256K to ``madvise`` and 1M, 2M
|
||||
to ``never``::
|
||||
|
||||
thp_anon=16K-64K:always;128K,512K:inherit;256K:madvise;1M-2M:never
|
||||
|
||||
``thp_anon=`` may be specified multiple times to configure all THP sizes as
|
||||
required. If ``thp_anon=`` is specified at least once, any anon THP sizes
|
||||
not explicitly configured on the command line are implicitly set to
|
||||
``never``.
|
||||
|
||||
``transparent_hugepage`` setting only affects the global toggle. If
|
||||
``thp_anon`` is not specified, PMD_ORDER THP will default to ``inherit``.
|
||||
However, if a valid ``thp_anon`` setting is provided by the user, the
|
||||
PMD_ORDER THP policy will be overridden. If the policy for PMD_ORDER
|
||||
is not defined within a valid ``thp_anon``, its policy will default to
|
||||
``never``.
|
||||
You can change the sysfs boot time defaults of Transparent Hugepage
|
||||
Support by passing the parameter ``transparent_hugepage=always`` or
|
||||
``transparent_hugepage=madvise`` or ``transparent_hugepage=never``
|
||||
to the kernel command line.
|
||||
|
||||
Hugepages in tmpfs/shmem
|
||||
========================
|
||||
|
|
@ -358,22 +282,19 @@ force
|
|||
Need of application restart
|
||||
===========================
|
||||
|
||||
The transparent_hugepage/enabled and
|
||||
transparent_hugepage/hugepages-<size>kB/enabled values and tmpfs mount
|
||||
option only affect future behavior. So to make them effective you need
|
||||
to restart any application that could have been using hugepages. This
|
||||
also applies to the regions registered in khugepaged.
|
||||
The transparent_hugepage/enabled values and tmpfs mount option only affect
|
||||
future behavior. So to make them effective you need to restart any
|
||||
application that could have been using hugepages. This also applies to the
|
||||
regions registered in khugepaged.
|
||||
|
||||
Monitoring usage
|
||||
================
|
||||
|
||||
The number of PMD-sized anonymous transparent huge pages currently used by the
|
||||
The number of anonymous transparent huge pages currently used by the
|
||||
system is available by reading the AnonHugePages field in ``/proc/meminfo``.
|
||||
To identify what applications are using PMD-sized anonymous transparent huge
|
||||
pages, it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages
|
||||
fields for each mapping. (Note that AnonHugePages only applies to traditional
|
||||
PMD-sized THP for historical reasons and should have been called
|
||||
AnonHugePmdMapped).
|
||||
To identify what applications are using anonymous transparent huge pages,
|
||||
it is necessary to read ``/proc/PID/smaps`` and count the AnonHugePages fields
|
||||
for each mapping.
|
||||
|
||||
The number of file transparent huge pages mapped to userspace is available
|
||||
by reading ShmemPmdMapped and ShmemHugePages fields in ``/proc/meminfo``.
|
||||
|
|
@ -389,7 +310,7 @@ monitor how successfully the system is providing huge pages for use.
|
|||
|
||||
thp_fault_alloc
|
||||
is incremented every time a huge page is successfully
|
||||
allocated and charged to handle a page fault.
|
||||
allocated to handle a page fault.
|
||||
|
||||
thp_collapse_alloc
|
||||
is incremented by khugepaged when it has found
|
||||
|
|
@ -397,7 +318,7 @@ thp_collapse_alloc
|
|||
successfully allocated a new huge page to store the data.
|
||||
|
||||
thp_fault_fallback
|
||||
is incremented if a page fault fails to allocate or charge
|
||||
is incremented if a page fault fails to allocate
|
||||
a huge page and instead falls back to using small pages.
|
||||
|
||||
thp_fault_fallback_charge
|
||||
|
|
@ -467,49 +388,6 @@ thp_swpout_fallback
|
|||
Usually because failed to allocate some continuous swap space
|
||||
for the huge page.
|
||||
|
||||
In /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/stats, There are
|
||||
also individual counters for each huge page size, which can be utilized to
|
||||
monitor the system's effectiveness in providing huge pages for usage. Each
|
||||
counter has its own corresponding file.
|
||||
|
||||
anon_fault_alloc
|
||||
is incremented every time a huge page is successfully
|
||||
allocated and charged to handle a page fault.
|
||||
|
||||
anon_fault_fallback
|
||||
is incremented if a page fault fails to allocate or charge
|
||||
a huge page and instead falls back to using huge pages with
|
||||
lower orders or small pages.
|
||||
|
||||
anon_fault_fallback_charge
|
||||
is incremented if a page fault fails to charge a huge page and
|
||||
instead falls back to using huge pages with lower orders or
|
||||
small pages even though the allocation was successful.
|
||||
|
||||
swpout
|
||||
is incremented every time a huge page is swapped out in one
|
||||
piece without splitting.
|
||||
|
||||
swpout_fallback
|
||||
is incremented if a huge page has to be split before swapout.
|
||||
Usually because failed to allocate some continuous swap space
|
||||
for the huge page.
|
||||
|
||||
split
|
||||
is incremented every time a huge page is successfully split into
|
||||
smaller orders. This can happen for a variety of reasons but a
|
||||
common reason is that a huge page is old and is being reclaimed.
|
||||
|
||||
split_failed
|
||||
is incremented if kernel fails to split huge
|
||||
page. This can happen if the page was pinned by somebody.
|
||||
|
||||
split_deferred
|
||||
is incremented when a huge page is put onto split queue.
|
||||
This happens when a huge page is partially unmapped and splitting
|
||||
it would free up some memory. Pages on split queue are going to
|
||||
be split under memory pressure, if splitting is possible.
|
||||
|
||||
As the system ages, allocating huge pages may be expensive as the
|
||||
system uses memory compaction to copy data around memory to free a
|
||||
huge page for use. There are some counters in ``/proc/vmstat`` to help
|
||||
|
|
@ -535,7 +413,7 @@ for huge pages.
|
|||
Optimizing the applications
|
||||
===========================
|
||||
|
||||
To be guaranteed that the kernel will map a THP immediately in any
|
||||
To be guaranteed that the kernel will map a 2M page immediately in any
|
||||
memory region, the mmap region has to be hugepage naturally
|
||||
aligned. posix_memalign() can provide that guarantee.
|
||||
|
||||
|
|
|
|||
|
|
@ -113,9 +113,6 @@ events, except page fault notifications, may be generated:
|
|||
areas. ``UFFD_FEATURE_MINOR_SHMEM`` is the analogous feature indicating
|
||||
support for shmem virtual memory areas.
|
||||
|
||||
- ``UFFD_FEATURE_MOVE`` indicates that the kernel supports moving an
|
||||
existing page contents from userspace.
|
||||
|
||||
The userland application should set the feature flags it intends to use
|
||||
when invoking the ``UFFDIO_API`` ioctl, to request that those features be
|
||||
enabled if supported.
|
||||
|
|
|
|||
|
|
@ -296,30 +296,12 @@ kernel panic). This will output the contents of the ftrace buffers to
|
|||
the console. This is very useful for capturing traces that lead to
|
||||
crashes and outputting them to a serial console.
|
||||
|
||||
======================= ===========================================
|
||||
0 Disabled (default).
|
||||
1 Dump buffers of all CPUs.
|
||||
2(orig_cpu) Dump the buffer of the CPU that triggered the
|
||||
oops.
|
||||
<instance> Dump the specific instance buffer on all CPUs.
|
||||
<instance>=2(orig_cpu) Dump the specific instance buffer on the CPU
|
||||
that triggered the oops.
|
||||
======================= ===========================================
|
||||
= ===================================================
|
||||
0 Disabled (default).
|
||||
1 Dump buffers of all CPUs.
|
||||
2 Dump the buffer of the CPU that triggered the oops.
|
||||
= ===================================================
|
||||
|
||||
Multiple instance dump is also supported, and instances are separated
|
||||
by commas. If global buffer also needs to be dumped, please specify
|
||||
the dump mode (1/2/orig_cpu) first for global buffer.
|
||||
|
||||
So for example to dump "foo" and "bar" instance buffer on all CPUs,
|
||||
user can::
|
||||
|
||||
echo "foo,bar" > /proc/sys/kernel/ftrace_dump_on_oops
|
||||
|
||||
To dump global buffer and "foo" instance buffer on all
|
||||
CPUs along with the "bar" instance buffer on CPU that triggered the
|
||||
oops, user can::
|
||||
|
||||
echo "1,foo,bar=2" > /proc/sys/kernel/ftrace_dump_on_oops
|
||||
|
||||
ftrace_enabled, stack_tracer_enabled
|
||||
====================================
|
||||
|
|
|
|||
|
|
@ -54,8 +54,6 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Ampere | AmpereOne | AC03_CPU_38 | AMPERE_ERRATUM_AC03_CPU_38 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Ampere | AmpereOne AC04 | AC04_CPU_10 | AMPERE_ERRATUM_AC03_CPU_38 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A510 | #2457168 | ARM64_ERRATUM_2457168 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
@ -141,8 +139,6 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A715 | #2645198 | ARM64_ERRATUM_2645198 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A715 | #3456084 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A720 | #3456091 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Cortex-A725 | #3456106 | ARM64_ERRATUM_3194386 |
|
||||
|
|
@ -179,8 +175,6 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N2 | #3324339 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-N3 | #3456111 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V1 | #3324341 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| ARM | Neoverse-V2 | #3324336 | ARM64_ERRATUM_3194386 |
|
||||
|
|
@ -284,5 +278,3 @@ stable kernels.
|
|||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Microsoft | Azure Cobalt 100| #2253138 | ARM64_ERRATUM_2253138 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
| Microsoft | Azure Cobalt 100| #3324339 | ARM64_ERRATUM_3194386 |
|
||||
+----------------+-----------------+-----------------+-----------------------------+
|
||||
|
|
|
|||
|
|
@ -77,10 +77,10 @@ Basic design
|
|||
============
|
||||
|
||||
We introduce ``struct blk_crypto_key`` to represent an inline encryption key and
|
||||
how it will be used. This includes the type of the key (standard or
|
||||
hardware-wrapped); the actual bytes of the key; the size of the key; the
|
||||
algorithm and data unit size the key will be used with; and the number of bytes
|
||||
needed to represent the maximum data unit number the key will be used with.
|
||||
how it will be used. This includes the actual bytes of the key; the size of the
|
||||
key; the algorithm and data unit size the key will be used with; and the number
|
||||
of bytes needed to represent the maximum data unit number the key will be used
|
||||
with.
|
||||
|
||||
We introduce ``struct bio_crypt_ctx`` to represent an encryption context. It
|
||||
contains a data unit number and a pointer to a blk_crypto_key. We add pointers
|
||||
|
|
@ -301,216 +301,3 @@ kernel will pretend that the device does not support hardware inline encryption
|
|||
When the crypto API fallback is enabled, this means that all bios with and
|
||||
encryption context will use the fallback, and IO will complete as usual. When
|
||||
the fallback is disabled, a bio with an encryption context will be failed.
|
||||
|
||||
.. _hardware_wrapped_keys:
|
||||
|
||||
Hardware-wrapped keys
|
||||
=====================
|
||||
|
||||
Motivation and threat model
|
||||
---------------------------
|
||||
|
||||
Linux storage encryption (dm-crypt, fscrypt, eCryptfs, etc.) traditionally
|
||||
relies on the raw encryption key(s) being present in kernel memory so that the
|
||||
encryption can be performed. This traditionally isn't seen as a problem because
|
||||
the key(s) won't be present during an offline attack, which is the main type of
|
||||
attack that storage encryption is intended to protect from.
|
||||
|
||||
However, there is an increasing desire to also protect users' data from other
|
||||
types of attacks (to the extent possible), including:
|
||||
|
||||
- Cold boot attacks, where an attacker with physical access to a system suddenly
|
||||
powers it off, then immediately dumps the system memory to extract recently
|
||||
in-use encryption keys, then uses these keys to decrypt user data on-disk.
|
||||
|
||||
- Online attacks where the attacker is able to read kernel memory without fully
|
||||
compromising the system, followed by an offline attack where any extracted
|
||||
keys can be used to decrypt user data on-disk. An example of such an online
|
||||
attack would be if the attacker is able to run some code on the system that
|
||||
exploits a Meltdown-like vulnerability but is unable to escalate privileges.
|
||||
|
||||
- Online attacks where the attacker fully compromises the system, but their data
|
||||
exfiltration is significantly time-limited and/or bandwidth-limited, so in
|
||||
order to completely exfiltrate the data they need to extract the encryption
|
||||
keys to use in a later offline attack.
|
||||
|
||||
Hardware-wrapped keys are a feature of inline encryption hardware that is
|
||||
designed to protect users' data from the above attacks (to the extent possible),
|
||||
without introducing limitations such as a maximum number of keys.
|
||||
|
||||
Note that it is impossible to **fully** protect users' data from these attacks.
|
||||
Even in the attacks where the attacker "just" gets read access to kernel memory,
|
||||
they can still extract any user data that is present in memory, including
|
||||
plaintext pagecache pages of encrypted files. The focus here is just on
|
||||
protecting the encryption keys, as those instantly give access to **all** user
|
||||
data in any following offline attack, rather than just some of it (where which
|
||||
data is included in that "some" might not be controlled by the attacker).
|
||||
|
||||
Solution overview
|
||||
-----------------
|
||||
|
||||
Inline encryption hardware typically has "keyslots" into which software can
|
||||
program keys for the hardware to use; the contents of keyslots typically can't
|
||||
be read back by software. As such, the above security goals could be achieved
|
||||
if the kernel simply erased its copy of the key(s) after programming them into
|
||||
keyslot(s) and thereafter only referred to them via keyslot number.
|
||||
|
||||
However, that naive approach runs into the problem that it limits the number of
|
||||
unlocked keys to the number of keyslots, which typically is a small number. In
|
||||
cases where there is only one encryption key system-wide (e.g., a full-disk
|
||||
encryption key), that can be tolerable. However, in general there can be many
|
||||
logged-in users with many different keys, and/or many running applications with
|
||||
application-specific encrypted storage areas. This is especially true if
|
||||
file-based encryption (e.g. fscrypt) is being used.
|
||||
|
||||
Thus, it is important for the kernel to still have a way to "remind" the
|
||||
hardware about a key, without actually having the raw key itself. This would
|
||||
ensure that the number of hardware keyslots only limits the number of active I/O
|
||||
requests, not other things such as the number of logged-in users, the number of
|
||||
running apps, or the number of encrypted storage areas that apps can create.
|
||||
|
||||
Somewhat less importantly, it is also desirable that the raw keys are never
|
||||
visible to software at all, even while being initially unlocked. This would
|
||||
ensure that a read-only compromise of system memory will never allow a key to be
|
||||
extracted to be used off-system, even if it occurs when a key is being unlocked.
|
||||
|
||||
To solve all these problems, some vendors of inline encryption hardware have
|
||||
made their hardware support *hardware-wrapped keys*. Hardware-wrapped keys
|
||||
are encrypted keys that can only be unwrapped (decrypted) and used by hardware
|
||||
-- either by the inline encryption hardware itself, or by a dedicated hardware
|
||||
block that can directly provision keys to the inline encryption hardware.
|
||||
|
||||
(We refer to them as "hardware-wrapped keys" rather than simply "wrapped keys"
|
||||
to add some clarity in cases where there could be other types of wrapped keys,
|
||||
such as in file-based encryption. Key wrapping is a commonly used technique.)
|
||||
|
||||
The key which wraps (encrypts) hardware-wrapped keys is a hardware-internal key
|
||||
that is never exposed to software; it is either a persistent key (a "long-term
|
||||
wrapping key") or a per-boot key (an "ephemeral wrapping key"). The long-term
|
||||
wrapped form of the key is what is initially unlocked, but it is erased from
|
||||
memory as soon as it is converted into an ephemerally-wrapped key. In-use
|
||||
hardware-wrapped keys are always ephemerally-wrapped, not long-term wrapped.
|
||||
|
||||
As inline encryption hardware can only be used to encrypt/decrypt data on-disk,
|
||||
the hardware also includes a level of indirection; it doesn't use the unwrapped
|
||||
key directly for inline encryption, but rather derives both an inline encryption
|
||||
key and a "software secret" from it. Software can use the "software secret" for
|
||||
tasks that can't use the inline encryption hardware, such as filenames
|
||||
encryption. The software secret is not protected from memory compromise.
|
||||
|
||||
Key hierarchy
|
||||
-------------
|
||||
|
||||
Here is the key hierarchy for a hardware-wrapped key::
|
||||
|
||||
Hardware-wrapped key
|
||||
|
|
||||
|
|
||||
<Hardware KDF>
|
||||
|
|
||||
-----------------------------
|
||||
| |
|
||||
Inline encryption key Software secret
|
||||
|
||||
The components are:
|
||||
|
||||
- *Hardware-wrapped key*: a key for the hardware's KDF (Key Derivation
|
||||
Function), in ephemerally-wrapped form. The key wrapping algorithm is a
|
||||
hardware implementation detail that doesn't impact kernel operation, but a
|
||||
strong authenticated encryption algorithm such as AES-256-GCM is recommended.
|
||||
|
||||
- *Hardware KDF*: a KDF (Key Derivation Function) which the hardware uses to
|
||||
derive subkeys after unwrapping the wrapped key. The hardware's choice of KDF
|
||||
doesn't impact kernel operation, but it does need to be known for testing
|
||||
purposes, and it's also assumed to have at least a 256-bit security strength.
|
||||
All known hardware uses the SP800-108 KDF in Counter Mode with AES-256-CMAC,
|
||||
with a particular choice of labels and contexts; new hardware should use this
|
||||
already-vetted KDF.
|
||||
|
||||
- *Inline encryption key*: a derived key which the hardware directly provisions
|
||||
to a keyslot of the inline encryption hardware, without exposing it to
|
||||
software. In all known hardware, this will always be an AES-256-XTS key.
|
||||
However, in principle other encryption algorithms could be supported too.
|
||||
Hardware must derive distinct subkeys for each supported encryption algorithm.
|
||||
|
||||
- *Software secret*: a derived key which the hardware returns to software so
|
||||
that software can use it for cryptographic tasks that can't use inline
|
||||
encryption. This value is cryptographically isolated from the inline
|
||||
encryption key, i.e. knowing one doesn't reveal the other. (The KDF ensures
|
||||
this.) Currently, the software secret is always 32 bytes and thus is suitable
|
||||
for cryptographic applications that require up to a 256-bit security strength.
|
||||
Some use cases (e.g. full-disk encryption) won't require the software secret.
|
||||
|
||||
Example: in the case of fscrypt, the fscrypt master key (the key that protects a
|
||||
particular set of encrypted directories) is made hardware-wrapped. The inline
|
||||
encryption key is used as the file contents encryption key, while the software
|
||||
secret (rather than the master key directly) is used to key fscrypt's KDF
|
||||
(HKDF-SHA512) to derive other subkeys such as filenames encryption keys.
|
||||
|
||||
Note that currently this design assumes a single inline encryption key per
|
||||
hardware-wrapped key, without any further key derivation. Thus, in the case of
|
||||
fscrypt, currently hardware-wrapped keys are only compatible with the "inline
|
||||
encryption optimized" settings, which use one file contents encryption key per
|
||||
encryption policy rather than one per file. This design could be extended to
|
||||
make the hardware derive per-file keys using per-file nonces passed down the
|
||||
storage stack, and in fact some hardware already supports this; future work is
|
||||
planned to remove this limitation by adding the corresponding kernel support.
|
||||
|
||||
Kernel support
|
||||
--------------
|
||||
|
||||
The inline encryption support of the kernel's block layer ("blk-crypto") has
|
||||
been extended to support hardware-wrapped keys as an alternative to standard
|
||||
keys, when hardware support is available. This works in the following way:
|
||||
|
||||
- A ``key_types_supported`` field is added to the crypto capabilities in
|
||||
``struct blk_crypto_profile``. This allows device drivers to declare that
|
||||
they support standard keys, hardware-wrapped keys, or both.
|
||||
|
||||
- ``struct blk_crypto_key`` can now contain a hardware-wrapped key as an
|
||||
alternative to a standard key; a ``key_type`` field is added to
|
||||
``struct blk_crypto_config`` to distinguish between the different key types.
|
||||
This allows users of blk-crypto to en/decrypt data using a hardware-wrapped
|
||||
key in a way very similar to using a standard key.
|
||||
|
||||
- A new method ``blk_crypto_ll_ops::derive_sw_secret`` is added. Device drivers
|
||||
that support hardware-wrapped keys must implement this method. Users of
|
||||
blk-crypto can call ``blk_crypto_derive_sw_secret()`` to access this method.
|
||||
|
||||
- The programming and eviction of hardware-wrapped keys happens via
|
||||
``blk_crypto_ll_ops::keyslot_program`` and
|
||||
``blk_crypto_ll_ops::keyslot_evict``, just like it does for standard keys. If
|
||||
a driver supports hardware-wrapped keys, then it must handle hardware-wrapped
|
||||
keys being passed to these methods.
|
||||
|
||||
blk-crypto-fallback doesn't support hardware-wrapped keys. Therefore,
|
||||
hardware-wrapped keys can only be used with actual inline encryption hardware.
|
||||
|
||||
Currently, the kernel only works with hardware-wrapped keys in
|
||||
ephemerally-wrapped form. No generic kernel interfaces are provided for
|
||||
generating or importing hardware-wrapped keys in the first place, or converting
|
||||
them to ephemerally-wrapped form. In Android, SoC vendors are required to
|
||||
support these operations in their KeyMint implementation (a hardware abstraction
|
||||
layer in userspace); for details, see the `Android documentation
|
||||
<https://source.android.com/security/encryption/hw-wrapped-keys>`_.
|
||||
|
||||
Testability
|
||||
-----------
|
||||
|
||||
Both the hardware KDF and the inline encryption itself are well-defined
|
||||
algorithms that don't depend on any secrets other than the unwrapped key.
|
||||
Therefore, if the unwrapped key is known to software, these algorithms can be
|
||||
reproduced in software in order to verify the ciphertext that is written to disk
|
||||
by the inline encryption hardware.
|
||||
|
||||
However, the unwrapped key will only be known to software for testing if the
|
||||
"import" functionality is used. Proper testing is not possible in the
|
||||
"generate" case where the hardware generates the key itself. The correct
|
||||
operation of the "generate" mode thus relies on the security and correctness of
|
||||
the hardware RNG and its use to generate the key, as well as the testing of the
|
||||
"import" mode as that should cover all parts other than the key generation.
|
||||
|
||||
For an example of a test that verifies the ciphertext written to disk in the
|
||||
"import" mode, see the fscrypt hardware-wrapped key tests in xfstests, or
|
||||
`Android's vts_kernel_encryption_test
|
||||
<https://android.googlesource.com/platform/test/vts-testcase/kernel/+/refs/heads/master/encryption/>`_.
|
||||
|
|
|
|||
|
|
@ -81,9 +81,6 @@ section.
|
|||
Sometimes it is necessary to ensure the next call to store to a maple tree does
|
||||
not allocate memory, please see :ref:`maple-tree-advanced-api` for this use case.
|
||||
|
||||
You can use mtree_dup() to duplicate an entire maple tree. It is a more
|
||||
efficient way than inserting all elements one by one into a new tree.
|
||||
|
||||
Finally, you can remove all entries from a maple tree by calling
|
||||
mtree_destroy(). If the maple tree entries are pointers, you may wish to free
|
||||
the entries first.
|
||||
|
|
@ -115,7 +112,6 @@ Takes ma_lock internally:
|
|||
* mtree_insert()
|
||||
* mtree_insert_range()
|
||||
* mtree_erase()
|
||||
* mtree_dup()
|
||||
* mtree_destroy()
|
||||
* mt_set_in_rcu()
|
||||
* mt_clear_in_rcu()
|
||||
|
|
|
|||
|
|
@ -1,55 +1,58 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
#
|
||||
# (C) COPYRIGHT 2022-2023 ARM Limited. All rights reserved.
|
||||
#
|
||||
# This program is free software and is provided to you under the terms of the
|
||||
# GNU General Public License version 2 as published by the Free Software
|
||||
# Foundation, and any use by you of this program is subject to the terms
|
||||
# of such GNU license.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, you can access it online at
|
||||
# http://www.gnu.org/licenses/gpl-2.0.html.
|
||||
#
|
||||
#
|
||||
|
||||
==================
|
||||
DebugFS interface
|
||||
==================
|
||||
|
||||
**Copyright:** \(C) 2022-2024 ARM Limited. All rights reserved.
|
||||
..
|
||||
This program is free software and is provided to you under the terms of the
|
||||
GNU General Public License version 2 as published by the Free Software
|
||||
Foundation, and any use by you of this program is subject to the terms
|
||||
of such GNU license.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, you can access it online at
|
||||
http://www.gnu.org/licenses/gpl-2.0.html.
|
||||
DebugFS interface:
|
||||
------------------
|
||||
|
||||
A new per-kbase-context debugfs file called csf_sync has been implemented
|
||||
which captures the current KCPU & GPU queue state of the not-yet-completed
|
||||
operations and displayed through the debugfs file.
|
||||
This file is at
|
||||
This file is at:
|
||||
=======================================================
|
||||
/sys/kernel/debug/mali0/ctx/<pid>_<context id>/csf_sync
|
||||
=======================================================
|
||||
|
||||
::
|
||||
|
||||
/sys/kernel/debug/mali0/ctx/<pid>_<context id>/csf_sync
|
||||
|
||||
|
||||
Output Format
|
||||
-------------
|
||||
Output Format:
|
||||
----------------
|
||||
|
||||
The csf_sync file contains important data for the currently active queues.
|
||||
This data is formatted into two segments, which are separated by a
|
||||
pipe character: the common properties and the operation-specific properties.
|
||||
|
||||
Common Properties
|
||||
-----------------
|
||||
Common Properties:
|
||||
------------------
|
||||
|
||||
* Queue type: GPU or KCPU.
|
||||
* kbase context id and the queue id.
|
||||
* If the queue type is a GPU queue then the group handle is also noted,in the middle of the other two IDs. The slot value is also dumped.
|
||||
* If the queue type is a GPU queue then the group handle is also noted,
|
||||
in the middle of the other two IDs. The slot value is also dumped.
|
||||
* Execution status, which can either be 'P' for pending or 'S' for started.
|
||||
* Command type is then output which indicates the type of dependency (i.e. wait or signal).
|
||||
* Object address which is a pointer to the sync object that the command operates on.
|
||||
* Command type is then output which indicates the type of dependency
|
||||
(i.e. wait or signal).
|
||||
* Object address which is a pointer to the sync object that the
|
||||
command operates on.
|
||||
* The live value, which is the value of the synchronization object
|
||||
at the time of dumping. This could help to determine why wait
|
||||
operations might be blocked.
|
||||
|
||||
* The live value, which is the value of the synchronization object at the time of dumping. This could help to determine why wait operations might be blocked.
|
||||
|
||||
Operation-Specific Properties
|
||||
Operation-Specific Properties:
|
||||
------------------------------
|
||||
|
||||
The operation-specific values for KCPU queue fence operations
|
||||
|
|
@ -64,49 +67,48 @@ which are always shown; the argument value to wait on or set/add to,
|
|||
and the operation type (set/add) or wait condition (e.g. LE, GT, GE).
|
||||
|
||||
Examples
|
||||
========
|
||||
|
||||
--------
|
||||
GPU Queue Example
|
||||
------------------
|
||||
|
||||
The following output is of a GPU queue, from a process that has a KCTX ID of 52,
|
||||
is in Queue Group (CSG) 0, and has Queue ID 0. It has started and is waiting on
|
||||
the object at address **0x0000007f81ffc800**. The live value is 0,
|
||||
the object at address 0x0000007f81ffc800. The live value is 0,
|
||||
as is the arg value. However, the operation "op" is GT, indicating it's waiting
|
||||
for the live value to surpass the arg value:
|
||||
|
||||
::
|
||||
|
||||
queue:GPU-52-0-0 exec:S cmd:SYNC_WAIT slot:4 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
|
||||
======================================================================================================================================
|
||||
queue:GPU-52-0-0 exec:S cmd:SYNC_WAIT slot:4 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
|
||||
======================================================================================================================================
|
||||
|
||||
The following is an example of GPU queue dump, where the SYNC SET operation
|
||||
is blocked by the preceding SYNC WAIT operation. This shows two GPU queues,
|
||||
with the same KCTX ID of 8, Queue Group (CSG) 0, and Queue ID 0. The SYNC WAIT
|
||||
operation has started, while the SYNC SET is pending, blocked by the SYNC WAIT.
|
||||
Both operations are on the same slot, 2 and have live value of 0. The SYNC WAIT
|
||||
is waiting on the object at address **0x0000007f81ffc800**, while the SYNC SET will
|
||||
set the object at address **0x00000000a3bad4fb** when it is unblocked.
|
||||
is waiting on the object at address 0x0000007f81ffc800, while the SYNC SET will
|
||||
set the object at address 0x00000000a3bad4fb when it is unblocked.
|
||||
The operation "op" is GT for the SYNC WAIT, indicating it's waiting for the
|
||||
live value to surpass the arg value, while the operation and arg value for the
|
||||
SYNC SET is "set" and "1" respectively.
|
||||
SYNC SET is "set" and "1" respectively:
|
||||
|
||||
::
|
||||
|
||||
queue:GPU-8-0-0 exec:S cmd:SYNC_WAIT slot:2 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
|
||||
queue:GPU-8-0-0 exec:P cmd:SYNC_SET slot:2 obj:0x00000000a3bad4fb live_value:0x0000000000000000 | op:set arg_value:0x0000000000000001
|
||||
======================================================================================================================================
|
||||
queue:GPU-8-0-0 exec:S cmd:SYNC_WAIT slot:2 obj:0x0000007f81ffc800 live_value:0x0000000000000000 | op:gt arg_value:0x0000000000000000
|
||||
queue:GPU-8-0-0 exec:P cmd:SYNC_SET slot:2 obj:0x00000000a3bad4fb live_value:0x0000000000000000 | op:set arg_value:0x0000000000000001
|
||||
======================================================================================================================================
|
||||
|
||||
KCPU Queue Example
|
||||
------------------
|
||||
|
||||
The following is an example of a KCPU queue, from a process that has
|
||||
a KCTX ID of 0 and has Queue ID 1. It has started and is waiting on the
|
||||
object at address **0x0000007fbf6f2ff8**. The live value is currently 0 with
|
||||
object at address 0x0000007fbf6f2ff8. The live value is currently 0 with
|
||||
the "op" being GT indicating it is waiting on the live value to
|
||||
surpass the arg value.
|
||||
|
||||
::
|
||||
|
||||
queue:KCPU-0-1 exec:S cmd:CQS_WAIT_OPERATION obj:0x0000007fbf6f2ff8 live_value:0x0000000000000000 | op:gt arg_value: 0x00000000
|
||||
===============================================================================================================================
|
||||
queue:KCPU-0-1 exec:S cmd:CQS_WAIT_OPERATION obj:0x0000007fbf6f2ff8 live_value:0x0000000000000000 | op:gt arg_value: 0x00000000
|
||||
===============================================================================================================================
|
||||
|
||||
CSF Sync State Dump For Fence Signal Timeouts
|
||||
---------------------------------------------
|
||||
|
|
@ -140,23 +142,18 @@ which is written to, to turn this feature on and off.
|
|||
|
||||
Example:
|
||||
--------
|
||||
when writing to fence_signal_timeout_enable entry
|
||||
|
||||
::
|
||||
|
||||
echo 1 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is enabled.
|
||||
echo 0 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is disabled.
|
||||
when writing to fence_signal_timeout_enable entry:
|
||||
echo 1 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is enabled.
|
||||
echo 0 > /sys/kernel/debug/mali0/fence_signal_timeout_enable -> feature is disabled.
|
||||
|
||||
It is also possible to read from this file to check if the feature is currently
|
||||
enabled or not checking the return value of fence_signal_timeout_enable.
|
||||
|
||||
Example:
|
||||
--------
|
||||
when reading from fence_signal_timeout_enable entry, if
|
||||
::
|
||||
|
||||
cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 1 -> feature is enabled.
|
||||
cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 0 -> feature is disabled.
|
||||
when reading from fence_signal_timeout_enable entry, if:
|
||||
cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 1 -> feature is enabled.
|
||||
cat /sys/kernel/debug/mali0/fence_signal_timeout_enable returns 0 -> feature is disabled.
|
||||
|
||||
Update Timer Duration
|
||||
---------------------
|
||||
|
|
@ -166,15 +163,11 @@ milliseconds.
|
|||
|
||||
Example:
|
||||
--------
|
||||
::
|
||||
|
||||
cat /sys/kernel/debug/mali0/fence_signal_timeout_ms
|
||||
cat /sys/kernel/debug/mali0/fence_signal_timeout_ms
|
||||
|
||||
The 'fence_signal_timeout_ms' debugfs entry can also be written to, to update
|
||||
the time in milliseconds.
|
||||
|
||||
Example:
|
||||
--------
|
||||
::
|
||||
|
||||
echo 10000 > /sys/kernel/debug/mali0/fence_signal_timeout_ms
|
||||
echo 10000 > /sys/kernel/debug/mali0/fence_signal_timeout_ms
|
||||
|
|
@ -255,21 +255,9 @@ Contributing new tests (details)
|
|||
|
||||
TEST_PROGS_EXTENDED, TEST_GEN_PROGS_EXTENDED mean it is the
|
||||
executable which is not tested by default.
|
||||
|
||||
TEST_FILES, TEST_GEN_FILES mean it is the file which is used by
|
||||
test.
|
||||
|
||||
TEST_INCLUDES is similar to TEST_FILES, it lists files which should be
|
||||
included when exporting or installing the tests, with the following
|
||||
differences:
|
||||
|
||||
* symlinks to files in other directories are preserved
|
||||
* the part of paths below tools/testing/selftests/ is preserved when
|
||||
copying the files to the output directory
|
||||
|
||||
TEST_INCLUDES is meant to list dependencies located in other directories of
|
||||
the selftests hierarchy.
|
||||
|
||||
* First use the headers inside the kernel source and/or git repo, and then the
|
||||
system headers. Headers for the kernel release as opposed to headers
|
||||
installed by the distro on the system should be the primary focus to be able
|
||||
|
|
|
|||
|
|
@ -18,15 +18,6 @@ KUnit - Linux Kernel Unit Testing
|
|||
faq
|
||||
running_tips
|
||||
|
||||
.. warning::
|
||||
AOSP only supports running tests loaded with modules. Built-in
|
||||
test execution support has been disabled. In addition, in order
|
||||
to fully enable running module loaded tests both CONFIG_KUNIT
|
||||
needs to be enabled and kernel command line argument
|
||||
`kunit.enable` needs to be set to 1.
|
||||
|
||||
The remaining KUnit documentation has been left as-is.
|
||||
|
||||
This section details the kernel unit testing framework.
|
||||
|
||||
Introduction
|
||||
|
|
|
|||
|
|
@ -651,16 +651,12 @@ For example:
|
|||
}
|
||||
|
||||
Note that, for functions like device_unregister which only accept a single
|
||||
pointer-sized argument, it's possible to automatically generate a wrapper
|
||||
with the ``KUNIT_DEFINE_ACTION_WRAPPER()`` macro, for example:
|
||||
pointer-sized argument, it's possible to directly cast that function to
|
||||
a ``kunit_action_t`` rather than writing a wrapper function, for example:
|
||||
|
||||
.. code-block:: C
|
||||
|
||||
KUNIT_DEFINE_ACTION_WRAPPER(device_unregister, device_unregister_wrapper, struct device *);
|
||||
kunit_add_action(test, &device_unregister_wrapper, &dev);
|
||||
|
||||
You should do this in preference to manually casting to the ``kunit_action_t`` type,
|
||||
as casting function pointers will break Control Flow Integrity (CFI).
|
||||
kunit_add_action(test, (kunit_action_t *)&device_unregister, &dev);
|
||||
|
||||
``kunit_add_action`` can fail if, for example, the system is out of memory.
|
||||
You can use ``kunit_add_action_or_reset`` instead which runs the action
|
||||
|
|
|
|||
|
|
@ -1,99 +0,0 @@
|
|||
dm_bow (backup on write)
|
||||
========================
|
||||
|
||||
dm_bow is a device mapper driver that uses the free space on a device to back up
|
||||
data that is overwritten. The changes can then be committed by a simple state
|
||||
change, or rolled back by removing the dm_bow device and running a command line
|
||||
utility over the underlying device.
|
||||
|
||||
dm_bow has three states, set by writing ‘1’ or ‘2’ to /sys/block/dm-?/bow/state.
|
||||
It is only possible to go from state 0 (initial state) to state 1, and then from
|
||||
state 1 to state 2.
|
||||
|
||||
State 0: dm_bow collects all trims to the device and assumes that these mark
|
||||
free space on the overlying file system that can be safely used. Typically the
|
||||
mount code would create the dm_bow device, mount the file system, call the
|
||||
FITRIM ioctl on the file system then switch to state 1. These trims are not
|
||||
propagated to the underlying device.
|
||||
|
||||
State 1: All writes to the device cause the underlying data to be backed up to
|
||||
the free (trimmed) area as needed in such a way as they can be restored.
|
||||
However, the writes, with one exception, then happen exactly as they would
|
||||
without dm_bow, so the device is always in a good final state. The exception is
|
||||
that sector 0 is used to keep a log of the latest changes, both to indicate that
|
||||
we are in this state and to allow rollback. See below for all details. If there
|
||||
isn't enough free space, writes are failed with -ENOSPC.
|
||||
|
||||
State 2: The transition to state 2 triggers replacing the special sector 0 with
|
||||
the normal sector 0, and the freeing of all state information. dm_bow then
|
||||
becomes a pass-through driver, allowing the device to continue to be used with
|
||||
minimal performance impact.
|
||||
|
||||
Usage
|
||||
=====
|
||||
dm-bow takes one command line parameter, the name of the underlying device.
|
||||
|
||||
dm-bow will typically be used in the following way. dm-bow will be loaded with a
|
||||
suitable underlying device and the resultant device will be mounted. A file
|
||||
system trim will be issued via the FITRIM ioctl, then the device will be
|
||||
switched to state 1. The file system will now be used as normal. At some point,
|
||||
the changes can either be committed by switching to state 2, or rolled back by
|
||||
unmounting the file system, removing the dm-bow device and running the command
|
||||
line utility. Note that rebooting the device will be equivalent to unmounting
|
||||
and removing, but the command line utility must still be run
|
||||
|
||||
Details of operation in state 1
|
||||
===============================
|
||||
|
||||
dm_bow maintains a type for all sectors. A sector can be any of:
|
||||
|
||||
SECTOR0
|
||||
SECTOR0_CURRENT
|
||||
UNCHANGED
|
||||
FREE
|
||||
CHANGED
|
||||
BACKUP
|
||||
|
||||
SECTOR0 is the first sector on the device, and is used to hold the log of
|
||||
changes. This is the one exception.
|
||||
|
||||
SECTOR0_CURRENT is a sector picked from the FREE sectors, and is where reads and
|
||||
writes from the true sector zero are redirected to. Note that like any backup
|
||||
sector, if the sector is written to directly, it must be moved again.
|
||||
|
||||
UNCHANGED means that the sector has not been changed since we entered state 1.
|
||||
Thus if it is written to or trimmed, the contents must first be backed up.
|
||||
|
||||
FREE means that the sector was trimmed in state 0 and has not yet been written
|
||||
to or used for backup. On being written to, a FREE sector is changed to CHANGED.
|
||||
|
||||
CHANGED means that the sector has been modified, and can be further modified
|
||||
without further backup.
|
||||
|
||||
BACKUP means that this is a free sector being used as a backup. On being written
|
||||
to, the contents must first be backed up again.
|
||||
|
||||
All backup operations are logged to the first sector. The log sector has the
|
||||
format:
|
||||
--------------------------------------------------------
|
||||
| Magic | Count | Sequence | Log entry | Log entry | …
|
||||
--------------------------------------------------------
|
||||
|
||||
Magic is a magic number. Count is the number of log entries. Sequence is 0
|
||||
initially. A log entry is
|
||||
|
||||
-----------------------------------
|
||||
| Source | Dest | Size | Checksum |
|
||||
-----------------------------------
|
||||
|
||||
When SECTOR0 is full, the log sector is backed up and another empty log sector
|
||||
created with sequence number one higher. The first entry in any log entry with
|
||||
sequence > 0 therefore must be the log of the backing up of the previous log
|
||||
sector. Note that sequence is not strictly needed, but is a useful sanity check
|
||||
and potentially limits the time spent trying to restore a corrupted snapshot.
|
||||
|
||||
On entering state 1, dm_bow has a list of free sectors. All other sectors are
|
||||
unchanged. Sector0_current is selected from the free sectors and the contents of
|
||||
sector 0 are copied there. The sector 0 is backed up, which triggers the first
|
||||
log entry to be written.
|
||||
|
||||
|
|
@ -1,163 +0,0 @@
|
|||
# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
#
|
||||
# (C) COPYRIGHT 2022-2024 ARM Limited. All rights reserved.
|
||||
#
|
||||
# This program is free software and is provided to you under the terms of the
|
||||
# GNU General Public License version 2 as published by the Free Software
|
||||
# Foundation, and any use by you of this program is subject to the terms
|
||||
# of such GNU license.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, you can access it online at
|
||||
# http://www.gnu.org/licenses/gpl-2.0.html.
|
||||
#
|
||||
#
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/arm/arm,coresight-mali-source.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ARM CoreSight Mali Source integration
|
||||
|
||||
maintainers:
|
||||
- ARM Ltd.
|
||||
|
||||
description: |
|
||||
See Documentation/trace/coresight/coresight.rst for detailed information
|
||||
about Coresight.
|
||||
|
||||
This documentation will cover Mali specific devicetree integration.
|
||||
|
||||
References to Sink ports are given as examples. Access to Sink is specific
|
||||
to an implementation and would require dedicated kernel modules.
|
||||
|
||||
Arm Mali GPU are supporting 3 different sources: ITM, ETM, ELA
|
||||
|
||||
ELA source configuration via SysFS entries:
|
||||
|
||||
The register values used by CoreSight for ELA can be configured using SysFS
|
||||
interfaces. This implicitly includes configuring the ELA for independent or
|
||||
shared JCN request and response channels.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- arm,coresight-mali-source-itm
|
||||
- arm,coresight-mali-source-etm
|
||||
- arm,coresight-mali-source-ela
|
||||
|
||||
gpu:
|
||||
minItems: 1
|
||||
maxItems: 1
|
||||
description:
|
||||
Phandle to a Mali GPU definition
|
||||
|
||||
port:
|
||||
description:
|
||||
Output connection to CoreSight Sink Trace bus.
|
||||
|
||||
Legacy binding between Coresight Sources and CoreSight Sink.
|
||||
For Linux kernel < v4.20.
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
|
||||
out-ports:
|
||||
description:
|
||||
Binding between Coresight Sources and CoreSight Sink.
|
||||
For Linux kernel >= v4.20.
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
|
||||
properties:
|
||||
port:
|
||||
description: Output connection to CoreSight Sink Trace bus.
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- gpu
|
||||
- port
|
||||
- out-ports
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
|
||||
# A Sink node without legacy CoreSight connections
|
||||
- |
|
||||
mali-source-itm {
|
||||
compatible = "arm,coresight-mali-source-itm";
|
||||
gpu = <&gpu>;
|
||||
|
||||
out-ports {
|
||||
port {
|
||||
mali_source_itm_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mali-source-ela {
|
||||
compatible = "arm,coresight-mali-source-ela";
|
||||
gpu = <&gpu>;
|
||||
|
||||
out-ports {
|
||||
port {
|
||||
mali_source_ela_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mali-source-etm {
|
||||
compatible = "arm,coresight-mali-source-etm";
|
||||
gpu = <&gpu>;
|
||||
|
||||
out-ports {
|
||||
port {
|
||||
mali_source_etm_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
# A Sink node with legacy CoreSight connections
|
||||
- |
|
||||
mali-source-itm {
|
||||
compatible = "arm,coresight-mali-source-itm";
|
||||
gpu = <&gpu>;
|
||||
|
||||
port {
|
||||
mali_source_itm_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mali-source-etm {
|
||||
compatible = "arm,coresight-mali-source-etm";
|
||||
gpu = <&gpu>;
|
||||
|
||||
port {
|
||||
mali_source_etm_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
mali-source-ela {
|
||||
compatible = "arm,coresight-mali-source-ela";
|
||||
gpu = <&gpu>;
|
||||
|
||||
port {
|
||||
mali_source_ela_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
116
Documentation/devicetree/bindings/arm/mali-coresight-source.txt
Normal file
116
Documentation/devicetree/bindings/arm/mali-coresight-source.txt
Normal file
|
|
@ -0,0 +1,116 @@
|
|||
# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
#
|
||||
# (C) COPYRIGHT 2023 ARM Limited. All rights reserved.
|
||||
#
|
||||
# This program is free software and is provided to you under the terms of the
|
||||
# GNU General Public License version 2 as published by the Free Software
|
||||
# Foundation, and any use by you of this program is subject to the terms
|
||||
# of such GNU license.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, you can access it online at
|
||||
# http://www.gnu.org/licenses/gpl-2.0.html.
|
||||
#
|
||||
#
|
||||
=====================================
|
||||
ARM CoreSight Mali Source integration
|
||||
=====================================
|
||||
|
||||
See Documentation/trace/coresight/coresight.rst for detailed information
|
||||
about Coresight.
|
||||
|
||||
This documentation will cover Mali specific devicetree integration.
|
||||
|
||||
References to Sink ports are given as examples. Access to Sink is specific
|
||||
to an implementation and would require dedicated kernel modules.
|
||||
|
||||
ARM Coresight Mali Source ITM
|
||||
=============================
|
||||
|
||||
Required properties
|
||||
-------------------
|
||||
|
||||
- compatible: Has to be "arm,coresight-mali-source-itm"
|
||||
- gpu : phandle to a Mali GPU definition
|
||||
- port:
|
||||
- endpoint:
|
||||
- remote-endpoint: phandle to a Coresight sink port
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
mali-source-itm {
|
||||
compatible = "arm,coresight-mali-source-itm";
|
||||
gpu = <&gpu>;
|
||||
port {
|
||||
mali_source_itm_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
ARM Coresight Mali Source ETM
|
||||
=============================
|
||||
|
||||
Required properties
|
||||
-------------------
|
||||
|
||||
- compatible: Has to be "arm,coresight-mali-source-etm"
|
||||
- gpu : phandle to a Mali GPU definition
|
||||
- port:
|
||||
- endpoint:
|
||||
- remote-endpoint: phandle to a Coresight sink port
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
mali-source-etm {
|
||||
compatible = "arm,coresight-mali-source-etm";
|
||||
gpu = <&gpu>;
|
||||
port {
|
||||
mali_source_etm_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port1>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
ARM Coresight Mali Source ELA
|
||||
=============================
|
||||
|
||||
Required properties
|
||||
-------------------
|
||||
|
||||
- compatible: Has to be "arm,coresight-mali-source-ela"
|
||||
- gpu : phandle to a Mali GPU definition
|
||||
- port:
|
||||
- endpoint:
|
||||
- remote-endpoint: phandle to a Coresight sink port
|
||||
|
||||
Example: Split JCN request/response channel
|
||||
--------------------------------------------
|
||||
|
||||
This examples applies to implementations with a total of 5 signal groups,
|
||||
where JCN request and response are assigned to independent or shared
|
||||
channels depending on the GPU model.
|
||||
|
||||
mali-source-ela {
|
||||
compatible = "arm,coresight-mali-source-ela";
|
||||
gpu = <&gpu>;
|
||||
port {
|
||||
mali_source_ela_out_port0: endpoint {
|
||||
remote-endpoint = <&mali_sink_in_port2>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
SysFS Configuration
|
||||
--------------------------------------------
|
||||
|
||||
The register values used by CoreSight for ELA can be configured using SysFS
|
||||
interfaces. This implicitly includes configuring the ELA for independent or
|
||||
shared JCN request and response channels.
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
#
|
||||
# (C) COPYRIGHT 2013-2024 ARM Limited. All rights reserved.
|
||||
# (C) COPYRIGHT 2013-2023 ARM Limited. All rights reserved.
|
||||
#
|
||||
# This program is free software and is provided to you under the terms of the
|
||||
# GNU General Public License version 2 as published by the Free Software
|
||||
|
|
@ -35,21 +35,14 @@ Optional:
|
|||
|
||||
- clocks : One or more pairs of phandle to clock and clock specifier
|
||||
for the Mali device. The order is important: the first clock
|
||||
shall correspond to the "clk_mali" source. Other clocks are optional
|
||||
and, if present, they shall correspond to domains like "shadercores",
|
||||
which is available for all GPUs, or "coregroup" and "neuralengines"
|
||||
which are available for newer GPUs. Also notice that the "neuralengines"
|
||||
clock domain, if present, doesn't expect a corresponding regulator.
|
||||
- clock-names : Shall be set to values like: "clk_mali", "shadercores", "coregroup",
|
||||
"neuralengines". Only the first one is mandatory. Most GPUs
|
||||
support only the first two entries.
|
||||
shall correspond to the "clk_mali" source, while the second clock
|
||||
(that is optional) shall correspond to the "shadercores" source.
|
||||
- clock-names : Shall be set to: "clk_mali", "shadercores".
|
||||
- mali-supply : Phandle to the top level regulator for the Mali device.
|
||||
Refer to
|
||||
Documentation/devicetree/bindings/regulator/regulator.txt for details.
|
||||
- shadercores-supply : Phandle to shader cores regulator for the Mali device.
|
||||
This is optional.
|
||||
- coregroup-supply: Phandle to core group regulator for the Mali device.
|
||||
This is optional and only available on newer GPUs.
|
||||
- operating-points-v2 : Refer to Documentation/devicetree/bindings/power/mali-opp.txt
|
||||
for details.
|
||||
- quirks-gpu : Used to write to the JM_CONFIG or CSF_CONFIG register.
|
||||
|
|
@ -140,10 +133,6 @@ for details.
|
|||
set and the setting coresponding to the SYSC_ALLOC register.
|
||||
- propagate-bits: Used to write to L2_CONFIG.PBHA_HWU. This bitset establishes which
|
||||
PBHA bits are propagated on the AXI bus.
|
||||
- mma-wa-id: Sets the PBHA ID to be used for the PBHA override based MMA violation workaround.
|
||||
The read and write allocation override bits for the PBHA are set to NONCACHEABLE
|
||||
and the driver encodes the PBHA ID in the PTEs where this workaround is to be applied.
|
||||
Valid values are from 1 to 15.
|
||||
|
||||
|
||||
Example for a Mali GPU with 1 clock and 1 regulator:
|
||||
|
|
@ -253,7 +242,6 @@ gpu@0xfc010000 {
|
|||
pbha {
|
||||
int-id-override = <2 0x32>, <9 0x05>, <16 0x32>;
|
||||
propagate-bits = /bits/ 8 <0x03>;
|
||||
mma-wa-id = <2>;
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
|
|||
|
|
@ -231,46 +231,6 @@ properties:
|
|||
SNK_READY for non-pd link.
|
||||
type: boolean
|
||||
|
||||
sink-wait-cap-time-ms:
|
||||
description: Represents the max time in ms that USB Type-C port (in sink
|
||||
role) should wait for the port partner (source role) to send source caps.
|
||||
SinkWaitCap timer starts when port in sink role attaches to the source.
|
||||
This timer will stop when sink receives PD source cap advertisement before
|
||||
timeout in which case it'll move to capability negotiation stage. A
|
||||
timeout leads to a hard reset message by the port.
|
||||
minimum: 310
|
||||
maximum: 620
|
||||
default: 310
|
||||
|
||||
ps-source-off-time-ms:
|
||||
description: Represents the max time in ms that a DRP in source role should
|
||||
take to turn off power after the PsSourceOff timer starts. PsSourceOff
|
||||
timer starts when a sink's PHY layer receives EOP of the GoodCRC message
|
||||
(corresponding to an Accept message sent in response to a PR_Swap or a
|
||||
FR_Swap request). This timer stops when last bit of GoodCRC EOP
|
||||
corresponding to the received PS_RDY message is transmitted by the PHY
|
||||
layer. A timeout shall lead to error recovery in the type-c port.
|
||||
minimum: 750
|
||||
maximum: 920
|
||||
default: 920
|
||||
|
||||
cc-debounce-time-ms:
|
||||
description: Represents the max time in ms that a port shall wait to
|
||||
determine if it's attached to a partner.
|
||||
minimum: 100
|
||||
maximum: 200
|
||||
default: 200
|
||||
|
||||
sink-bc12-completion-time-ms:
|
||||
description: Represents the max time in ms that a port in sink role takes
|
||||
to complete Battery Charger (BC1.2) Detection. BC1.2 detection is a
|
||||
hardware mechanism, which in some TCPC implementations, can run in
|
||||
parallel once the Type-C connection state machine reaches the "potential
|
||||
connect as sink" state. In TCPCs where this causes delays to respond to
|
||||
the incoming PD messages, sink-bc12-completion-time-ms is used to delay
|
||||
PD negotiation till BC1.2 detection completes.
|
||||
default: 0
|
||||
|
||||
dependencies:
|
||||
sink-vdos-v1: [ sink-vdos ]
|
||||
sink-vdos: [ sink-vdos-v1 ]
|
||||
|
|
@ -356,7 +316,7 @@ examples:
|
|||
};
|
||||
|
||||
# USB-C connector attached to a typec port controller(ptn5110), which has
|
||||
# power delivery support, explicitly defines time properties and enables drp.
|
||||
# power delivery support and enables drp.
|
||||
- |
|
||||
#include <dt-bindings/usb/pd.h>
|
||||
typec: ptn5110 {
|
||||
|
|
@ -369,10 +329,6 @@ examples:
|
|||
sink-pdos = <PDO_FIXED(5000, 2000, PDO_FIXED_USB_COMM)
|
||||
PDO_VAR(5000, 12000, 2000)>;
|
||||
op-sink-microwatt = <10000000>;
|
||||
sink-wait-cap-time-ms = <465>;
|
||||
ps-source-off-time-ms = <835>;
|
||||
cc-debounce-time-ms = <101>;
|
||||
sink-bc12-completion-time-ms = <500>;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -1,48 +0,0 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/cpufreq/qemu,virtual-cpufreq.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Virtual CPUFreq
|
||||
|
||||
maintainers:
|
||||
- David Dai <davidai@google.com>
|
||||
- Saravana Kannan <saravanak@google.com>
|
||||
|
||||
description:
|
||||
Virtual CPUFreq is a virtualized driver in guest kernels that sends performance
|
||||
selection of its vCPUs as a hint to the host through MMIO regions. Each vCPU
|
||||
is associated with a performance domain which can be shared with other vCPUs.
|
||||
Each performance domain has its own set of registers for performance controls.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qemu,virtual-cpufreq
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description:
|
||||
Address and size of region containing performance controls for each of the
|
||||
performance domains. Regions for each performance domain is placed
|
||||
contiguously and contain registers for controlling DVFS(Dynamic Frequency
|
||||
and Voltage) characteristics. The size of the region is proportional to
|
||||
total number of performance domains.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
soc {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
cpufreq@1040000 {
|
||||
compatible = "qemu,virtual-cpufreq";
|
||||
reg = <0x1040000 0x2000>;
|
||||
};
|
||||
};
|
||||
|
|
@ -1,111 +0,0 @@
|
|||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/cpufreq/virtual,android-v-only-cpufreq.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Android-V-Only Virtual CPUFreq
|
||||
|
||||
maintainers:
|
||||
- David Dai <davidai@google.com>
|
||||
- Saravana Kannan <saravanak@google.com>
|
||||
|
||||
description:
|
||||
Android-V-Only Virtual CPUFreq is a virtualized driver in guest kernels that
|
||||
sends frequency selection of its vCPUs as a hint to the host through MMIO
|
||||
regions. Each vCPU is associated with a frequency domain which can be shared
|
||||
with other vCPUs. Each frequency domain has its own set of registers for
|
||||
frequency controls.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: virtual,android-v-only-cpufreq
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description:
|
||||
Address and size of region containing frequency controls for each of the
|
||||
frequency domains. Regions for each frequency domain is placed
|
||||
contiguously and contain registers for controlling DVFS(Dynamic Frequency
|
||||
and Voltage) characteristics. The size of the region is proportional to
|
||||
total number of frequency domains. This device also needs the CPUs to
|
||||
list their OPPs using operating-points-v2 tables. The OPP tables for the
|
||||
CPUs should use normalized "frequency" values where the OPP with the
|
||||
highest performance among all the vCPUs is listed as 1024 KHz. The rest
|
||||
of the frequencies of all the vCPUs should be normalized based on their
|
||||
performance relative to that 1024 KHz OPP. This makes it much easier to
|
||||
migrate the VM across systems which might have different physical CPU
|
||||
OPPs.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
// This example shows a two CPU configuration with a frequency domain
|
||||
// for each CPU showing normalized performance points.
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
compatible = "arm,armv8";
|
||||
device_type = "cpu";
|
||||
reg = <0x0>;
|
||||
operating-points-v2 = <&opp_table0>;
|
||||
};
|
||||
|
||||
cpu@1 {
|
||||
compatible = "arm,armv8";
|
||||
device_type = "cpu";
|
||||
reg = <0x0>;
|
||||
operating-points-v2 = <&opp_table1>;
|
||||
};
|
||||
};
|
||||
|
||||
opp_table0: opp-table-0 {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp64000 { opp-hz = /bits/ 64 <64000>; };
|
||||
opp128000 { opp-hz = /bits/ 64 <128000>; };
|
||||
opp192000 { opp-hz = /bits/ 64 <192000>; };
|
||||
opp256000 { opp-hz = /bits/ 64 <256000>; };
|
||||
opp320000 { opp-hz = /bits/ 64 <320000>; };
|
||||
opp384000 { opp-hz = /bits/ 64 <384000>; };
|
||||
opp425000 { opp-hz = /bits/ 64 <425000>; };
|
||||
};
|
||||
|
||||
opp_table1: opp-table-1 {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp64000 { opp-hz = /bits/ 64 <64000>; };
|
||||
opp128000 { opp-hz = /bits/ 64 <128000>; };
|
||||
opp192000 { opp-hz = /bits/ 64 <192000>; };
|
||||
opp256000 { opp-hz = /bits/ 64 <256000>; };
|
||||
opp320000 { opp-hz = /bits/ 64 <320000>; };
|
||||
opp384000 { opp-hz = /bits/ 64 <384000>; };
|
||||
opp448000 { opp-hz = /bits/ 64 <448000>; };
|
||||
opp512000 { opp-hz = /bits/ 64 <512000>; };
|
||||
opp576000 { opp-hz = /bits/ 64 <576000>; };
|
||||
opp640000 { opp-hz = /bits/ 64 <640000>; };
|
||||
opp704000 { opp-hz = /bits/ 64 <704000>; };
|
||||
opp768000 { opp-hz = /bits/ 64 <768000>; };
|
||||
opp832000 { opp-hz = /bits/ 64 <832000>; };
|
||||
opp896000 { opp-hz = /bits/ 64 <896000>; };
|
||||
opp960000 { opp-hz = /bits/ 64 <960000>; };
|
||||
opp1024000 { opp-hz = /bits/ 64 <1024000>; };
|
||||
|
||||
};
|
||||
|
||||
soc {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
cpufreq@1040000 {
|
||||
compatible = "virtual,android-v-only-cpufreq";
|
||||
reg = <0x1040000 0x10>;
|
||||
};
|
||||
};
|
||||
|
|
@ -69,17 +69,14 @@ properties:
|
|||
- const: tx
|
||||
- const: tx_reply
|
||||
- const: rx
|
||||
- const: rx_reply
|
||||
minItems: 2
|
||||
|
||||
mboxes:
|
||||
description:
|
||||
List of phandle and mailbox channel specifiers. It should contain
|
||||
exactly one, two, three or four mailboxes; the first one or two for
|
||||
transmitting messages ("tx") and another optional ("rx") for receiving
|
||||
notifications and delayed responses, if supported by the platform.
|
||||
The optional ("rx_reply") is for notifications completion interrupt,
|
||||
if supported by the platform.
|
||||
exactly one, two or three mailboxes; the first one or two for transmitting
|
||||
messages ("tx") and another optional ("rx") for receiving notifications
|
||||
and delayed responses, if supported by the platform.
|
||||
The number of mailboxes needed for transmitting messages depends on the
|
||||
type of channels exposed by the specific underlying mailbox controller;
|
||||
one single channel descriptor is enough if such channel is bidirectional,
|
||||
|
|
@ -92,10 +89,9 @@ properties:
|
|||
2 mbox / 2 shmem => SCMI TX and RX over 2 mailbox bidirectional channels
|
||||
2 mbox / 1 shmem => SCMI TX over 2 mailbox unidirectional channels
|
||||
3 mbox / 2 shmem => SCMI TX and RX over 3 mailbox unidirectional channels
|
||||
4 mbox / 2 shmem => SCMI TX and RX over 4 mailbox unidirectional channels
|
||||
Any other combination of mboxes and shmem is invalid.
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
maxItems: 3
|
||||
|
||||
shmem:
|
||||
description:
|
||||
|
|
@ -118,13 +114,6 @@ properties:
|
|||
atomic mode of operation, even if requested.
|
||||
default: 0
|
||||
|
||||
max-rx-timeout-ms:
|
||||
description:
|
||||
An optional time value, expressed in milliseconds, representing the
|
||||
transport maximum timeout value for the receive channel. The value should
|
||||
be a non-zero value if set.
|
||||
minimum: 1
|
||||
|
||||
arm,smc-id:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description:
|
||||
|
|
@ -251,30 +240,32 @@ properties:
|
|||
protocol@19:
|
||||
type: object
|
||||
allOf:
|
||||
- $ref: '#/$defs/protocol-node'
|
||||
- $ref: /schemas/pinctrl/pinctrl.yaml
|
||||
|
||||
- $ref: "#/$defs/protocol-node"
|
||||
- $ref: "../pinctrl/pinctrl.yaml"
|
||||
unevaluatedProperties: false
|
||||
|
||||
properties:
|
||||
reg:
|
||||
const: 0x19
|
||||
|
||||
'#pinctrl-cells':
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
'-pins$':
|
||||
type: object
|
||||
allOf:
|
||||
- $ref: /schemas/pinctrl/pincfg-node.yaml#
|
||||
- $ref: /schemas/pinctrl/pinmux-node.yaml#
|
||||
- $ref: "../pinctrl/pincfg-node.yaml#"
|
||||
- $ref: "../pinctrl/pinmux-node.yaml#"
|
||||
unevaluatedProperties: false
|
||||
|
||||
description:
|
||||
A pin multiplexing sub-node describes how to configure a
|
||||
set of pins in some desired function.
|
||||
A pin multiplexing sub-node describe how to configure a
|
||||
set of pins is some desired function.
|
||||
A single sub-node may define several pin configurations.
|
||||
This sub-node is using the default pinctrl bindings to configure
|
||||
pin multiplexing and using SCMI protocol to apply a specified
|
||||
configuration.
|
||||
This sub-node is using default pinctrl bindings to configure
|
||||
pin multiplexing and using SCMI protocol to apply specified
|
||||
configuration using SCMI protocol.
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
|
@ -435,19 +426,20 @@ examples:
|
|||
|
||||
scmi_pinctrl: protocol@19 {
|
||||
reg = <0x19>;
|
||||
#pinctrl-cells = <0>;
|
||||
|
||||
i2c2-pins {
|
||||
groups = "g_i2c2_a", "g_i2c2_b";
|
||||
function = "f_i2c2";
|
||||
groups = "i2c2_a", "i2c2_b";
|
||||
function = "i2c2";
|
||||
};
|
||||
|
||||
mdio-pins {
|
||||
groups = "g_avb_mdio";
|
||||
groups = "avb_mdio";
|
||||
drive-strength = <24>;
|
||||
};
|
||||
|
||||
keys_pins: keys-pins {
|
||||
pins = "gpio_5_17", "gpio_5_20", "gpio_5_22", "gpio_2_1";
|
||||
pins = "GP_5_17", "GP_5_20", "GP_5_22", "GP_2_1";
|
||||
bias-pull-up;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,82 +0,0 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/firmware/gunyah-hypervisor.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Gunyah Hypervisor
|
||||
|
||||
maintainers:
|
||||
- Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
|
||||
- Elliot Berman <quic_eberman@quicinc.com>
|
||||
|
||||
description: |+
|
||||
Gunyah virtual machines use this information to determine the capability IDs
|
||||
of the message queues used to communicate with the Gunyah Resource Manager.
|
||||
See also: https://github.com/quic/gunyah-resource-manager/blob/develop/src/vm_creation/dto_construct.c
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: gunyah-hypervisor
|
||||
|
||||
"#address-cells":
|
||||
description: Number of cells needed to represent 64-bit capability IDs.
|
||||
const: 2
|
||||
|
||||
"#size-cells":
|
||||
description: must be 0, because capability IDs are not memory address
|
||||
ranges and do not have a size.
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^gunyah-resource-mgr(@.*)?":
|
||||
type: object
|
||||
description:
|
||||
Resource Manager node which is required to communicate to Resource
|
||||
Manager VM using Gunyah Message Queues.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: gunyah-resource-manager
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: Gunyah capability ID of the TX message queue
|
||||
- description: Gunyah capability ID of the RX message queue
|
||||
|
||||
interrupts:
|
||||
items:
|
||||
- description: Interrupt for the TX message queue
|
||||
- description: Interrupt for the RX message queue
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#address-cells"
|
||||
- "#size-cells"
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
hypervisor {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <0>;
|
||||
compatible = "gunyah-hypervisor";
|
||||
|
||||
gunyah-resource-mgr@0 {
|
||||
compatible = "gunyah-resource-manager";
|
||||
interrupts = <GIC_SPI 3 IRQ_TYPE_EDGE_RISING>, /* TX allowed IRQ */
|
||||
<GIC_SPI 4 IRQ_TYPE_EDGE_RISING>; /* RX requested IRQ */
|
||||
reg = <0x00000000 0x00000000>, /* TX capability ID */
|
||||
<0x00000000 0x00000001>; /* RX capability ID */
|
||||
};
|
||||
};
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/firmware/mediatek,geniezone.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek GenieZone hypervisor
|
||||
|
||||
maintainers:
|
||||
- Yingshiuan Pan <yingshiuan.pan@mediatek.com>
|
||||
|
||||
description:
|
||||
GenieZone is a proprietary type-I hypervisor firmware developed by MediaTek,
|
||||
providing an isolated execution environment for mTEE (MediaTek Trusted
|
||||
Execution Environment) and AVF (Android Virtualization Framework) virtual
|
||||
machines. This binding facilitates the integration of GenieZone into the
|
||||
Android Virtualization Framework (AVF) with Crosvm as the VMM. The driver
|
||||
exposes hypervisor control interfaces to the VMM for managing virtual
|
||||
machine lifecycles and assisting virtual device emulation.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: mediatek,geniezone
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
hypervisor {
|
||||
compatible = "mediatek,geniezone";
|
||||
};
|
||||
|
|
@ -23,6 +23,7 @@ properties:
|
|||
- ak8963
|
||||
- ak09911
|
||||
- ak09912
|
||||
- ak09916
|
||||
deprecated: true
|
||||
|
||||
reg:
|
||||
|
|
|
|||
|
|
@ -34,7 +34,6 @@ properties:
|
|||
and length of the AXI DMA controller IO space, unless
|
||||
axistream-connected is specified, in which case the reg
|
||||
attribute of the node referenced by it is used.
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
|
||||
interrupts:
|
||||
|
|
@ -166,7 +165,7 @@ examples:
|
|||
clock-names = "s_axi_lite_clk", "axis_clk", "ref_clk", "mgt_clk";
|
||||
clocks = <&axi_clk>, <&axi_clk>, <&pl_enet_ref_clk>, <&mgt_clk>;
|
||||
phy-mode = "mii";
|
||||
reg = <0x40000000 0x40000>;
|
||||
reg = <0x00 0x40000000 0x00 0x40000>;
|
||||
xlnx,rxcsum = <0x2>;
|
||||
xlnx,rxmem = <0x800>;
|
||||
xlnx,txcsum = <0x2>;
|
||||
|
|
|
|||
|
|
@ -21,7 +21,6 @@ properties:
|
|||
- nxp,imx8mm-fspi
|
||||
- nxp,imx8mp-fspi
|
||||
- nxp,imx8qxp-fspi
|
||||
- nxp,imx8ulp-fspi
|
||||
- nxp,lx2160a-fspi
|
||||
- items:
|
||||
- enum:
|
||||
|
|
|
|||
|
|
@ -1,2 +0,0 @@
|
|||
# include OWNERS from the top level trusty repo
|
||||
include trusty:refs/meta/config:/OWNERS
|
||||
|
|
@ -1,67 +0,0 @@
|
|||
Trusty irq interface
|
||||
|
||||
Trusty requires non-secure irqs to be forwarded to the secure OS.
|
||||
|
||||
Required properties:
|
||||
- compatible: "android,trusty-irq-v1"
|
||||
|
||||
Optional properties:
|
||||
|
||||
- interrupt-templates: is an optional property that works together
|
||||
with "interrupt-ranges" to specify secure side to kernel IRQs mapping.
|
||||
|
||||
It is a list of entries, each one of which defines a group of interrupts
|
||||
having common properties, and has the following format:
|
||||
< phandle irq_id_pos [templ_data]>
|
||||
phandle - phandle of interrupt controller this template is for
|
||||
irq_id_pos - the position of irq id in interrupt specifier array
|
||||
for interrupt controller referenced by phandle.
|
||||
templ_data - is an array of u32 values (could be empty) in the same
|
||||
format as interrupt specifier for interrupt controller
|
||||
referenced by phandle but with omitted irq id field.
|
||||
|
||||
- interrupt-ranges: list of entries that specifies secure side to kernel
|
||||
IRQs mapping.
|
||||
|
||||
Each entry in the "interrupt-ranges" list has the following format:
|
||||
<beg end templ_idx>
|
||||
beg - first entry in this range
|
||||
end - last entry in this range
|
||||
templ_idx - index of entry in "interrupt-templates" property
|
||||
that must be used as a template for all interrupts
|
||||
in this range
|
||||
|
||||
- ipi-range: optional mapping of a linear range of trusty IRQs to a linear range
|
||||
of IPIs (inter-processor interrupts). This has the following format:
|
||||
<beg end ipi_base>
|
||||
beg - first trusty IRQ number that is an IPI
|
||||
end - last trusty IRQ number that is an IPI
|
||||
ipi_base - IPI number of 'beg'
|
||||
|
||||
Example:
|
||||
{
|
||||
gic: interrupt-controller@50041000 {
|
||||
compatible = "arm,gic-400";
|
||||
#interrupt-cells = <3>;
|
||||
interrupt-controller;
|
||||
...
|
||||
};
|
||||
...
|
||||
trusty {
|
||||
compatible = "android,trusty-smc-v1";
|
||||
ranges;
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
irq {
|
||||
compatible = "android,trusty-irq-v1";
|
||||
interrupt-templates = <&gic 1 GIC_PPI 0>,
|
||||
<&gic 1 GIC_SPI 0>;
|
||||
interrupt-ranges = <16 31 0>,
|
||||
<32 223 1>;
|
||||
ipi-range = <8 15 8>;
|
||||
};
|
||||
}
|
||||
}
|
||||
|
||||
Must be a child of the node that provides the trusty std/fast call interface.
|
||||
|
|
@ -1,6 +0,0 @@
|
|||
Trusty smc interface
|
||||
|
||||
Trusty is running in secure mode on the same (arm) cpu(s) as the current os.
|
||||
|
||||
Required properties:
|
||||
- compatible: "android,trusty-smc-v1"
|
||||
|
|
@ -69,7 +69,6 @@ examples:
|
|||
PDO_FIXED_DATA_SWAP |
|
||||
PDO_FIXED_DUAL_ROLE)
|
||||
PDO_FIXED(9000, 2000, 0)>;
|
||||
sink-bc12-completion-time-ms = <500>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,42 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
|
||||
=====================
|
||||
dma-buf-test-exporter
|
||||
=====================
|
||||
|
||||
**Copyright:** \(C) 2012-2013, 2020-2022, 2024 ARM Limited. All rights reserved.
|
||||
|
||||
..
|
||||
This program is free software and is provided to you under the terms of the
|
||||
GNU General Public License version 2 as published by the Free Software
|
||||
Foundation, and any use by you of this program is subject to the terms
|
||||
of such GNU license.
|
||||
|
||||
This program is distributed in the hope that it will be useful,
|
||||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
GNU General Public License for more details.
|
||||
|
||||
You should have received a copy of the GNU General Public License
|
||||
along with this program; if not, you can access it online at
|
||||
http://www.gnu.org/licenses/gpl-2.0.html.
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The dma-buf-test-exporter is a simple exporter of dma_buf objects.
|
||||
It has a private API to allocate and manipulate the buffers which are represented as dma_buf fds.
|
||||
The private API allows:
|
||||
|
||||
* simple allocation of physically non-contiguous buffers
|
||||
* simple allocation of physically contiguous buffers
|
||||
* query kernel side API usage stats (number of attachments, number of mappings, mmaps)
|
||||
* failure mode configuration (fail attach, mapping, mmap)
|
||||
* kernel side memset of buffers
|
||||
|
||||
The buffers support all of the dma_buf API, including mmap.
|
||||
|
||||
It supports being compiled as a module both in-tree and out-of-tree.
|
||||
|
||||
See **include/uapi/base/arm/dma_buf_test_exporter/dma-buf-test-exporter.h** for the ioctl interface.
|
||||
See **Documentation/dma-buf-sharing.txt** for details on dma_buf.
|
||||
42
Documentation/dma-buf-test-exporter.txt
Normal file
42
Documentation/dma-buf-test-exporter.txt
Normal file
|
|
@ -0,0 +1,42 @@
|
|||
# SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note
|
||||
#
|
||||
# (C) COPYRIGHT 2012-2013, 2020-2022 ARM Limited. All rights reserved.
|
||||
#
|
||||
# This program is free software and is provided to you under the terms of the
|
||||
# GNU General Public License version 2 as published by the Free Software
|
||||
# Foundation, and any use by you of this program is subject to the terms
|
||||
# of such GNU license.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, you can access it online at
|
||||
# http://www.gnu.org/licenses/gpl-2.0.html.
|
||||
#
|
||||
#
|
||||
|
||||
=====================
|
||||
dma-buf-test-exporter
|
||||
=====================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
||||
The dma-buf-test-exporter is a simple exporter of dma_buf objects.
|
||||
It has a private API to allocate and manipulate the buffers which are represented as dma_buf fds.
|
||||
The private API allows:
|
||||
* simple allocation of physically non-contiguous buffers
|
||||
* simple allocation of physically contiguous buffers
|
||||
* query kernel side API usage stats (number of attachments, number of mappings, mmaps)
|
||||
* failure mode configuration (fail attach, mapping, mmap)
|
||||
* kernel side memset of buffers
|
||||
|
||||
The buffers support all of the dma_buf API, including mmap.
|
||||
|
||||
It supports being compiled as a module both in-tree and out-of-tree.
|
||||
|
||||
See include/uapi/base/arm/dma_buf_test_exporter/dma-buf-test-exporter.h for the ioctl interface.
|
||||
See Documentation/dma-buf-sharing.txt for details on dma_buf.
|
||||
|
|
@ -540,7 +540,7 @@ at module load time (for a module) with::
|
|||
alerts_broken
|
||||
|
||||
The addresses are normal I2C addresses. The adapter is the string
|
||||
name of the adapter, as shown in /sys/bus/i2c/devices/i2c-<n>/name.
|
||||
name of the adapter, as shown in /sys/class/i2c-adapter/i2c-<n>/name.
|
||||
It is *NOT* i2c-<n> itself. Also, the comparison is done ignoring
|
||||
spaces, so if the name is "This is an I2C chip" you can say
|
||||
adapter_name=ThisisanI2cchip. This is because it's hard to pass in
|
||||
|
|
|
|||
|
|
@ -182,31 +182,29 @@ fault_type=%d Support configuring fault injection type, should be
|
|||
enabled with fault_injection option, fault type value
|
||||
is shown below, it supports single or combined type.
|
||||
|
||||
=========================== ===========
|
||||
Type_Name Type_Value
|
||||
=========================== ===========
|
||||
FAULT_KMALLOC 0x000000001
|
||||
FAULT_KVMALLOC 0x000000002
|
||||
FAULT_PAGE_ALLOC 0x000000004
|
||||
FAULT_PAGE_GET 0x000000008
|
||||
FAULT_ALLOC_BIO 0x000000010 (obsolete)
|
||||
FAULT_ALLOC_NID 0x000000020
|
||||
FAULT_ORPHAN 0x000000040
|
||||
FAULT_BLOCK 0x000000080
|
||||
FAULT_DIR_DEPTH 0x000000100
|
||||
FAULT_EVICT_INODE 0x000000200
|
||||
FAULT_TRUNCATE 0x000000400
|
||||
FAULT_READ_IO 0x000000800
|
||||
FAULT_CHECKPOINT 0x000001000
|
||||
FAULT_DISCARD 0x000002000
|
||||
FAULT_WRITE_IO 0x000004000
|
||||
FAULT_SLAB_ALLOC 0x000008000
|
||||
FAULT_DQUOT_INIT 0x000010000
|
||||
FAULT_LOCK_OP 0x000020000
|
||||
FAULT_BLKADDR_VALIDITY 0x000040000
|
||||
FAULT_BLKADDR_CONSISTENCE 0x000080000
|
||||
FAULT_NO_SEGMENT 0x000100000
|
||||
=========================== ===========
|
||||
=================== ===========
|
||||
Type_Name Type_Value
|
||||
=================== ===========
|
||||
FAULT_KMALLOC 0x000000001
|
||||
FAULT_KVMALLOC 0x000000002
|
||||
FAULT_PAGE_ALLOC 0x000000004
|
||||
FAULT_PAGE_GET 0x000000008
|
||||
FAULT_ALLOC_BIO 0x000000010 (obsolete)
|
||||
FAULT_ALLOC_NID 0x000000020
|
||||
FAULT_ORPHAN 0x000000040
|
||||
FAULT_BLOCK 0x000000080
|
||||
FAULT_DIR_DEPTH 0x000000100
|
||||
FAULT_EVICT_INODE 0x000000200
|
||||
FAULT_TRUNCATE 0x000000400
|
||||
FAULT_READ_IO 0x000000800
|
||||
FAULT_CHECKPOINT 0x000001000
|
||||
FAULT_DISCARD 0x000002000
|
||||
FAULT_WRITE_IO 0x000004000
|
||||
FAULT_SLAB_ALLOC 0x000008000
|
||||
FAULT_DQUOT_INIT 0x000010000
|
||||
FAULT_LOCK_OP 0x000020000
|
||||
FAULT_BLKADDR 0x000040000
|
||||
=================== ===========
|
||||
mode=%s Control block allocation mode which supports "adaptive"
|
||||
and "lfs". In "lfs" mode, there should be no random
|
||||
writes towards main area.
|
||||
|
|
@ -774,35 +772,6 @@ In order to identify whether the data in the victim segment are valid or not,
|
|||
F2FS manages a bitmap. Each bit represents the validity of a block, and the
|
||||
bitmap is composed of a bit stream covering whole blocks in main area.
|
||||
|
||||
Write-hint Policy
|
||||
-----------------
|
||||
|
||||
F2FS sets the whint all the time with the below policy.
|
||||
|
||||
===================== ======================== ===================
|
||||
User F2FS Block
|
||||
===================== ======================== ===================
|
||||
N/A META WRITE_LIFE_NONE|REQ_META
|
||||
N/A HOT_NODE WRITE_LIFE_NONE
|
||||
N/A WARM_NODE WRITE_LIFE_MEDIUM
|
||||
N/A COLD_NODE WRITE_LIFE_LONG
|
||||
ioctl(COLD) COLD_DATA WRITE_LIFE_EXTREME
|
||||
extension list " "
|
||||
|
||||
-- buffered io
|
||||
N/A COLD_DATA WRITE_LIFE_EXTREME
|
||||
N/A HOT_DATA WRITE_LIFE_SHORT
|
||||
N/A WARM_DATA WRITE_LIFE_NOT_SET
|
||||
|
||||
-- direct io
|
||||
WRITE_LIFE_EXTREME COLD_DATA WRITE_LIFE_EXTREME
|
||||
WRITE_LIFE_SHORT HOT_DATA WRITE_LIFE_SHORT
|
||||
WRITE_LIFE_NOT_SET WARM_DATA WRITE_LIFE_NOT_SET
|
||||
WRITE_LIFE_NONE " WRITE_LIFE_NONE
|
||||
WRITE_LIFE_MEDIUM " WRITE_LIFE_MEDIUM
|
||||
WRITE_LIFE_LONG " WRITE_LIFE_LONG
|
||||
===================== ======================== ===================
|
||||
|
||||
Fallocate(2) Policy
|
||||
-------------------
|
||||
|
||||
|
|
@ -943,47 +912,3 @@ NVMe Zoned Namespace devices
|
|||
can start before the zone-capacity and span across zone-capacity boundary.
|
||||
Such spanning segments are also considered as usable segments. All blocks
|
||||
past the zone-capacity are considered unusable in these segments.
|
||||
|
||||
Device aliasing feature
|
||||
-----------------------
|
||||
|
||||
f2fs can utilize a special file called a "device aliasing file." This file allows
|
||||
the entire storage device to be mapped with a single, large extent, not using
|
||||
the usual f2fs node structures. This mapped area is pinned and primarily intended
|
||||
for holding the space.
|
||||
|
||||
Essentially, this mechanism allows a portion of the f2fs area to be temporarily
|
||||
reserved and used by another filesystem or for different purposes. Once that
|
||||
external usage is complete, the device aliasing file can be deleted, releasing
|
||||
the reserved space back to F2FS for its own use.
|
||||
|
||||
<use-case>
|
||||
|
||||
# ls /dev/vd*
|
||||
/dev/vdb (32GB) /dev/vdc (32GB)
|
||||
# mkfs.ext4 /dev/vdc
|
||||
# mkfs.f2fs -c /dev/vdc@vdc.file /dev/vdb
|
||||
# mount /dev/vdb /mnt/f2fs
|
||||
# ls -l /mnt/f2fs
|
||||
vdc.file
|
||||
# df -h
|
||||
/dev/vdb 64G 33G 32G 52% /mnt/f2fs
|
||||
|
||||
# mount -o loop /dev/vdc /mnt/ext4
|
||||
# df -h
|
||||
/dev/vdb 64G 33G 32G 52% /mnt/f2fs
|
||||
/dev/loop7 32G 24K 30G 1% /mnt/ext4
|
||||
# umount /mnt/ext4
|
||||
|
||||
# f2fs_io getflags /mnt/f2fs/vdc.file
|
||||
get a flag on /mnt/f2fs/vdc.file ret=0, flags=nocow(pinned),immutable
|
||||
# f2fs_io setflags noimmutable /mnt/f2fs/vdc.file
|
||||
get a flag on noimmutable ret=0, flags=800010
|
||||
set a flag on /mnt/f2fs/vdc.file ret=0, flags=noimmutable
|
||||
# rm /mnt/f2fs/vdc.file
|
||||
# df -h
|
||||
/dev/vdb 64G 753M 64G 2% /mnt/f2fs
|
||||
|
||||
So, the key idea is, user can do any file operations on /dev/vdc, and
|
||||
reclaim the space after the use, while the space is counted as /data.
|
||||
That doesn't require modifying partition size and filesystem format.
|
||||
|
|
|
|||
|
|
@ -261,9 +261,9 @@ DIRECT_KEY policies
|
|||
|
||||
The Adiantum encryption mode (see `Encryption modes and usage`_) is
|
||||
suitable for both contents and filenames encryption, and it accepts
|
||||
long IVs --- long enough to hold both an 8-byte data unit index and a
|
||||
16-byte per-file nonce. Also, the overhead of each Adiantum key is
|
||||
greater than that of an AES-256-XTS key.
|
||||
long IVs --- long enough to hold both an 8-byte logical block number
|
||||
and a 16-byte per-file nonce. Also, the overhead of each Adiantum key
|
||||
is greater than that of an AES-256-XTS key.
|
||||
|
||||
Therefore, to improve performance and save memory, for Adiantum a
|
||||
"direct key" configuration is supported. When the user has enabled
|
||||
|
|
@ -300,8 +300,8 @@ IV_INO_LBLK_32 policies
|
|||
|
||||
IV_INO_LBLK_32 policies work like IV_INO_LBLK_64, except that for
|
||||
IV_INO_LBLK_32, the inode number is hashed with SipHash-2-4 (where the
|
||||
SipHash key is derived from the master key) and added to the file data
|
||||
unit index mod 2^32 to produce a 32-bit IV.
|
||||
SipHash key is derived from the master key) and added to the file
|
||||
logical block number mod 2^32 to produce a 32-bit IV.
|
||||
|
||||
This format is optimized for use with inline encryption hardware
|
||||
compliant with the eMMC v5.2 standard, which supports only 32 IV bits
|
||||
|
|
@ -451,62 +451,31 @@ acceleration is recommended:
|
|||
Contents encryption
|
||||
-------------------
|
||||
|
||||
For contents encryption, each file's contents is divided into "data
|
||||
units". Each data unit is encrypted independently. The IV for each
|
||||
data unit incorporates the zero-based index of the data unit within
|
||||
the file. This ensures that each data unit within a file is encrypted
|
||||
differently, which is essential to prevent leaking information.
|
||||
For file contents, each filesystem block is encrypted independently.
|
||||
Starting from Linux kernel 5.5, encryption of filesystems with block
|
||||
size less than system's page size is supported.
|
||||
|
||||
Note: the encryption depending on the offset into the file means that
|
||||
operations like "collapse range" and "insert range" that rearrange the
|
||||
extent mapping of files are not supported on encrypted files.
|
||||
Each block's IV is set to the logical block number within the file as
|
||||
a little endian number, except that:
|
||||
|
||||
There are two cases for the sizes of the data units:
|
||||
- With CBC mode encryption, ESSIV is also used. Specifically, each IV
|
||||
is encrypted with AES-256 where the AES-256 key is the SHA-256 hash
|
||||
of the file's data encryption key.
|
||||
|
||||
* Fixed-size data units. This is how all filesystems other than UBIFS
|
||||
work. A file's data units are all the same size; the last data unit
|
||||
is zero-padded if needed. By default, the data unit size is equal
|
||||
to the filesystem block size. On some filesystems, users can select
|
||||
a sub-block data unit size via the ``log2_data_unit_size`` field of
|
||||
the encryption policy; see `FS_IOC_SET_ENCRYPTION_POLICY`_.
|
||||
- With `DIRECT_KEY policies`_, the file's nonce is appended to the IV.
|
||||
Currently this is only allowed with the Adiantum encryption mode.
|
||||
|
||||
* Variable-size data units. This is what UBIFS does. Each "UBIFS
|
||||
data node" is treated as a crypto data unit. Each contains variable
|
||||
length, possibly compressed data, zero-padded to the next 16-byte
|
||||
boundary. Users cannot select a sub-block data unit size on UBIFS.
|
||||
- With `IV_INO_LBLK_64 policies`_, the logical block number is limited
|
||||
to 32 bits and is placed in bits 0-31 of the IV. The inode number
|
||||
(which is also limited to 32 bits) is placed in bits 32-63.
|
||||
|
||||
In the case of compression + encryption, the compressed data is
|
||||
encrypted. UBIFS compression works as described above. f2fs
|
||||
compression works a bit differently; it compresses a number of
|
||||
filesystem blocks into a smaller number of filesystem blocks.
|
||||
Therefore a f2fs-compressed file still uses fixed-size data units, and
|
||||
it is encrypted in a similar way to a file containing holes.
|
||||
- With `IV_INO_LBLK_32 policies`_, the logical block number is limited
|
||||
to 32 bits and is placed in bits 0-31 of the IV. The inode number
|
||||
is then hashed and added mod 2^32.
|
||||
|
||||
As mentioned in `Key hierarchy`_, the default encryption setting uses
|
||||
per-file keys. In this case, the IV for each data unit is simply the
|
||||
index of the data unit in the file. However, users can select an
|
||||
encryption setting that does not use per-file keys. For these, some
|
||||
kind of file identifier is incorporated into the IVs as follows:
|
||||
|
||||
- With `DIRECT_KEY policies`_, the data unit index is placed in bits
|
||||
0-63 of the IV, and the file's nonce is placed in bits 64-191.
|
||||
|
||||
- With `IV_INO_LBLK_64 policies`_, the data unit index is placed in
|
||||
bits 0-31 of the IV, and the file's inode number is placed in bits
|
||||
32-63. This setting is only allowed when data unit indices and
|
||||
inode numbers fit in 32 bits.
|
||||
|
||||
- With `IV_INO_LBLK_32 policies`_, the file's inode number is hashed
|
||||
and added to the data unit index. The resulting value is truncated
|
||||
to 32 bits and placed in bits 0-31 of the IV. This setting is only
|
||||
allowed when data unit indices and inode numbers fit in 32 bits.
|
||||
|
||||
The byte order of the IV is always little endian.
|
||||
|
||||
If the user selects FSCRYPT_MODE_AES_128_CBC for the contents mode, an
|
||||
ESSIV layer is automatically included. In this case, before the IV is
|
||||
passed to AES-128-CBC, it is encrypted with AES-256 where the AES-256
|
||||
key is the SHA-256 hash of the file's contents encryption key.
|
||||
Note that because file logical block numbers are included in the IVs,
|
||||
filesystems must enforce that blocks are never shifted around within
|
||||
encrypted files, e.g. via "collapse range" or "insert range".
|
||||
|
||||
Filenames encryption
|
||||
--------------------
|
||||
|
|
@ -575,8 +544,7 @@ follows::
|
|||
__u8 contents_encryption_mode;
|
||||
__u8 filenames_encryption_mode;
|
||||
__u8 flags;
|
||||
__u8 log2_data_unit_size;
|
||||
__u8 __reserved[3];
|
||||
__u8 __reserved[4];
|
||||
__u8 master_key_identifier[FSCRYPT_KEY_IDENTIFIER_SIZE];
|
||||
};
|
||||
|
||||
|
|
@ -618,29 +586,6 @@ This structure must be initialized as follows:
|
|||
The DIRECT_KEY, IV_INO_LBLK_64, and IV_INO_LBLK_32 flags are
|
||||
mutually exclusive.
|
||||
|
||||
- ``log2_data_unit_size`` is the log2 of the data unit size in bytes,
|
||||
or 0 to select the default data unit size. The data unit size is
|
||||
the granularity of file contents encryption. For example, setting
|
||||
``log2_data_unit_size`` to 12 causes file contents be passed to the
|
||||
underlying encryption algorithm (such as AES-256-XTS) in 4096-byte
|
||||
data units, each with its own IV.
|
||||
|
||||
Not all filesystems support setting ``log2_data_unit_size``. ext4
|
||||
and f2fs support it since Linux v6.7. On filesystems that support
|
||||
it, the supported nonzero values are 9 through the log2 of the
|
||||
filesystem block size, inclusively. The default value of 0 selects
|
||||
the filesystem block size.
|
||||
|
||||
The main use case for ``log2_data_unit_size`` is for selecting a
|
||||
data unit size smaller than the filesystem block size for
|
||||
compatibility with inline encryption hardware that only supports
|
||||
smaller data unit sizes. ``/sys/block/$disk/queue/crypto/`` may be
|
||||
useful for checking which data unit sizes are supported by a
|
||||
particular system's inline encryption hardware.
|
||||
|
||||
Leave this field zeroed unless you are certain you need it. Using
|
||||
an unnecessarily small data unit size reduces performance.
|
||||
|
||||
- For v2 encryption policies, ``__reserved`` must be zeroed.
|
||||
|
||||
- For v1 encryption policies, ``master_key_descriptor`` specifies how
|
||||
|
|
@ -1134,8 +1079,8 @@ The caller must zero all input fields, then fill in ``key_spec``:
|
|||
On success, 0 is returned and the kernel fills in the output fields:
|
||||
|
||||
- ``status`` indicates whether the key is absent, present, or
|
||||
incompletely removed. Incompletely removed means that removal has
|
||||
been initiated, but some files are still in use; i.e.,
|
||||
incompletely removed. Incompletely removed means that the master
|
||||
secret has been removed, but some files are still in use; i.e.,
|
||||
`FS_IOC_REMOVE_ENCRYPTION_KEY`_ returned 0 but set the informational
|
||||
status flag FSCRYPT_KEY_REMOVAL_STATUS_FLAG_FILES_BUSY.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,85 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================================================
|
||||
incfs: A stacked incremental filesystem for Linux
|
||||
=================================================
|
||||
|
||||
/sys/fs interface
|
||||
=================
|
||||
|
||||
Please update Documentation/ABI/testing/sysfs-fs-incfs if you update this
|
||||
section.
|
||||
|
||||
incfs creates the following files in /sys/fs.
|
||||
|
||||
Features
|
||||
--------
|
||||
|
||||
/sys/fs/incremental-fs/features/corefs
|
||||
Reads 'supported'. Always present.
|
||||
|
||||
/sys/fs/incremental-fs/features/v2
|
||||
Reads 'supported'. Present if all v2 features of incfs are supported. These
|
||||
are:
|
||||
fs-verity support
|
||||
inotify support
|
||||
ioclts:
|
||||
INCFS_IOC_SET_READ_TIMEOUTS
|
||||
INCFS_IOC_GET_READ_TIMEOUTS
|
||||
INCFS_IOC_GET_BLOCK_COUNT
|
||||
INCFS_IOC_CREATE_MAPPED_FILE
|
||||
.incomplete folder
|
||||
.blocks_written pseudo file
|
||||
report_uid mount option
|
||||
|
||||
/sys/fs/incremental-fs/features/zstd
|
||||
Reads 'supported'. Present if zstd compression is supported for data blocks.
|
||||
|
||||
/sys/fs/incremental-fs/features/bugfix_throttling
|
||||
Reads 'supported'. Present if the throttling lock bug is fixed
|
||||
|
||||
Optional per mount
|
||||
------------------
|
||||
|
||||
For each incfs mount, the mount option sysfs_name=[name] creates a /sys/fs
|
||||
node called:
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]
|
||||
|
||||
This will contain the following files:
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]/reads_delayed_min
|
||||
Returns a count of the number of reads that were delayed as a result of the
|
||||
per UID read timeouts min time setting.
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]/reads_delayed_min_us
|
||||
Returns total delay time for all files since first mount as a result of the
|
||||
per UID read timeouts min time setting.
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]/reads_delayed_pending
|
||||
Returns a count of the number of reads that were delayed as a result of
|
||||
waiting for a pending read.
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]/reads_delayed_pending_us
|
||||
Returns total delay time for all files since first mount as a result of
|
||||
waiting for a pending read.
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]/reads_failed_hash_verification
|
||||
Returns number of reads that failed because of hash verification failures.
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]/reads_failed_other
|
||||
Returns number of reads that failed for reasons other than timing out or
|
||||
hash failures.
|
||||
|
||||
/sys/fs/incremental-fs/instances/[name]/reads_failed_timed_out
|
||||
Returns number of reads that timed out.
|
||||
|
||||
For reads_delayed_*** settings, note that a file can count for both
|
||||
reads_delayed_min and reads_delayed_pending if incfs first waits for a pending
|
||||
read then has to wait further for the min time. In that case, the time spent
|
||||
waiting is split between reads_delayed_pending_us, which is increased by the
|
||||
time spent waiting for the pending read, and reads_delayed_min_us, which is
|
||||
increased by the remainder of the time spent waiting.
|
||||
|
||||
Reads that timed out are not added to the reads_delayed_pending or the
|
||||
reads_delayed_pending_us counters.
|
||||
|
|
@ -323,30 +323,6 @@ and
|
|||
The resulting access permissions should be the same. The difference is in
|
||||
the time of copy (on-demand vs. up-front).
|
||||
|
||||
### Non overlapping credentials
|
||||
|
||||
As noted above, all access to the upper, lower and work directories is the
|
||||
recorded mounter's MAC and DAC credentials. The incoming accesses are
|
||||
checked against the caller's credentials.
|
||||
|
||||
In the case where caller MAC or DAC credentials do not overlap the mounter, a
|
||||
use case available in older versions of the driver, the override_creds mount
|
||||
flag can be turned off. For when the use pattern has caller with legitimate
|
||||
credentials where the mounter does not. For example init may have been the
|
||||
mounter, but the caller would have execute or read MAC permissions where
|
||||
init would not. override_creds off means all access, incoming, upper, lower
|
||||
or working, will be tested against the caller.
|
||||
|
||||
Several unintended side effects will occur though. The caller without certain
|
||||
key capabilities or lower privilege will not always be able to delete files or
|
||||
directories, create nodes, or search some restricted directories. The ability
|
||||
to search and read a directory entry is spotty as a result of the cache
|
||||
mechanism not re-testing the credentials because of the assumption, a
|
||||
privileged caller can fill cache, then a lower privilege can read the directory
|
||||
cache. The uneven security model where cache, upperdir and workdir are opened
|
||||
at privilege, but accessed without creating a form of privilege escalation,
|
||||
should only be used with strict understanding of the side effects and of the
|
||||
security policies.
|
||||
|
||||
Multiple lower layers
|
||||
---------------------
|
||||
|
|
|
|||
|
|
@ -528,9 +528,9 @@ replaced by copy-on-write) part of the underlying shmem object out on swap.
|
|||
does not take into account swapped out page of underlying shmem objects.
|
||||
"Locked" indicates whether the mapping is locked in memory or not.
|
||||
|
||||
"THPeligible" indicates whether the mapping is eligible for allocating
|
||||
naturally aligned THP pages of any currently enabled size. 1 if true, 0
|
||||
otherwise.
|
||||
"THPeligible" indicates whether the mapping is eligible for allocating THP
|
||||
pages as well as the THP is PMD mappable or not - 1 if true, 0 otherwise.
|
||||
It just shows the current status.
|
||||
|
||||
"VmFlags" field deserves a separate description. This member represents the
|
||||
kernel flags associated with the particular virtual memory area in two letter
|
||||
|
|
@ -571,7 +571,6 @@ encoded manner. The codes are the following:
|
|||
um userfaultfd missing tracking
|
||||
uw userfaultfd wr-protect tracking
|
||||
ss shadow stack page
|
||||
sl sealed
|
||||
== =======================================
|
||||
|
||||
Note that there is no guarantee that every flag and associated mnemonic will
|
||||
|
|
|
|||
|
|
@ -32,11 +32,6 @@ Additional options to pass when preprocessing. The preprocessing options
|
|||
will be used in all cases where kbuild does preprocessing including
|
||||
building C files and assembler files.
|
||||
|
||||
KCPPFLAGS_COMPAT
|
||||
----------------
|
||||
Additional options to pass to $(CC_COMPAT) when preprocessing C and assembler
|
||||
files.
|
||||
|
||||
KAFLAGS
|
||||
-------
|
||||
Additional options to the assembler (for built-in and modules).
|
||||
|
|
|
|||
|
|
@ -21,7 +21,6 @@ This document describes how to build an out-of-tree kernel module.
|
|||
--- 4.1 Kernel Includes
|
||||
--- 4.2 Single Subdirectory
|
||||
--- 4.3 Several Subdirectories
|
||||
--- 4.4 UAPI Headers Installation
|
||||
=== 5. Module Installation
|
||||
--- 5.1 INSTALL_MOD_PATH
|
||||
--- 5.2 INSTALL_MOD_DIR
|
||||
|
|
@ -132,10 +131,6 @@ executed to make module versioning work.
|
|||
/lib/modules/<kernel_release>/updates/, but a prefix may
|
||||
be added with INSTALL_MOD_PATH (discussed in section 5).
|
||||
|
||||
headers_install
|
||||
Export headers in a format suitable for userspace. The default
|
||||
location is $PWD/usr. INSTALL_HDR_PATH can change this path.
|
||||
|
||||
clean
|
||||
Remove all generated files in the module directory only.
|
||||
|
||||
|
|
@ -411,17 +406,6 @@ according to the following rule:
|
|||
pointing to the directory where the currently executing kbuild
|
||||
file is located.
|
||||
|
||||
4.4 UAPI Headers Installation
|
||||
-----------------------------
|
||||
|
||||
External modules may export headers to userspace in a similar
|
||||
fashion to the in-tree counterpart drivers. kbuild supports
|
||||
running headers_install target in an out-of-tree. The location
|
||||
where kbuild searches for headers is $(M)/include/uapi and
|
||||
$(M)/arch/$(SRCARCH)/include/uapi.
|
||||
|
||||
See also Documentation/kbuild/headers_install.rst.
|
||||
|
||||
|
||||
5. Module Installation
|
||||
======================
|
||||
|
|
|
|||
|
|
@ -117,7 +117,7 @@ pages:
|
|||
|
||||
- map/unmap of a PMD entry for the whole THP increment/decrement
|
||||
folio->_entire_mapcount and also increment/decrement
|
||||
folio->_nr_pages_mapped by ENTIRELY_MAPPED when _entire_mapcount
|
||||
folio->_nr_pages_mapped by COMPOUND_MAPPED when _entire_mapcount
|
||||
goes from -1 to 0 or 0 to -1.
|
||||
|
||||
- map/unmap of individual pages with PTE entry increment/decrement
|
||||
|
|
@ -156,7 +156,7 @@ Partial unmap and deferred_split_folio()
|
|||
|
||||
Unmapping part of THP (with munmap() or other way) is not going to free
|
||||
memory immediately. Instead, we detect that a subpage of THP is not in use
|
||||
in folio_remove_rmap_*() and queue the THP for splitting if memory pressure
|
||||
in page_remove_rmap() and queue the THP for splitting if memory pressure
|
||||
comes. Splitting will free up unused subpages.
|
||||
|
||||
Splitting the page right away is not an option due to locking context in
|
||||
|
|
|
|||
|
|
@ -486,7 +486,7 @@ munlock the pages if we're removing the last VM_LOCKED VMA that maps the pages.
|
|||
Before the unevictable/mlock changes, mlocking did not mark the pages in any
|
||||
way, so unmapping them required no processing.
|
||||
|
||||
For each PTE (or PMD) being unmapped from a VMA, folio_remove_rmap_*() calls
|
||||
For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
|
||||
munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
|
||||
(unless it was a PTE mapping of a part of a transparent huge page).
|
||||
|
||||
|
|
@ -511,7 +511,7 @@ userspace; truncation even unmaps and deletes any private anonymous pages
|
|||
which had been Copied-On-Write from the file pages now being truncated.
|
||||
|
||||
Mlocked pages can be munlocked and deleted in this way: like with munmap(),
|
||||
for each PTE (or PMD) being unmapped from a VMA, folio_remove_rmap_*() calls
|
||||
for each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls
|
||||
munlock_vma_folio(), which calls munlock_folio() when the VMA is VM_LOCKED
|
||||
(unless it was a PTE mapping of a part of a transparent huge page).
|
||||
|
||||
|
|
|
|||
|
|
@ -71,31 +71,6 @@ whose performance is scaled together. Performance domains generally have a
|
|||
required to have the same micro-architecture. CPUs in different performance
|
||||
domains can have different micro-architectures.
|
||||
|
||||
To better reflect power variation due to static power (leakage) the EM
|
||||
supports runtime modifications of the power values. The mechanism relies on
|
||||
RCU to free the modifiable EM perf_state table memory. Its user, the task
|
||||
scheduler, also uses RCU to access this memory. The EM framework provides
|
||||
API for allocating/freeing the new memory for the modifiable EM table.
|
||||
The old memory is freed automatically using RCU callback mechanism when there
|
||||
are no owners anymore for the given EM runtime table instance. This is tracked
|
||||
using kref mechanism. The device driver which provided the new EM at runtime,
|
||||
should call EM API to free it safely when it's no longer needed. The EM
|
||||
framework will handle the clean-up when it's possible.
|
||||
|
||||
The kernel code which want to modify the EM values is protected from concurrent
|
||||
access using a mutex. Therefore, the device driver code must run in sleeping
|
||||
context when it tries to modify the EM.
|
||||
|
||||
With the runtime modifiable EM we switch from a 'single and during the entire
|
||||
runtime static EM' (system property) design to a 'single EM which can be
|
||||
changed during runtime according e.g. to the workload' (system and workload
|
||||
property) design.
|
||||
|
||||
It is possible also to modify the CPU performance values for each EM's
|
||||
performance state. Thus, the full power and performance profile (which
|
||||
is an exponential curve) can be changed according e.g. to the workload
|
||||
or system property.
|
||||
|
||||
|
||||
2. Core APIs
|
||||
------------
|
||||
|
|
@ -200,82 +175,10 @@ CPUfreq governor is in use in case of CPU device. Currently this calculation is
|
|||
not provided for other type of devices.
|
||||
|
||||
More details about the above APIs can be found in ``<linux/energy_model.h>``
|
||||
or in Section 2.5
|
||||
or in Section 2.4
|
||||
|
||||
|
||||
2.4 Runtime modifications
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Drivers willing to update the EM at runtime should use the following dedicated
|
||||
function to allocate a new instance of the modified EM. The API is listed
|
||||
below::
|
||||
|
||||
struct em_perf_table __rcu *em_table_alloc(struct em_perf_domain *pd);
|
||||
|
||||
This allows to allocate a structure which contains the new EM table with
|
||||
also RCU and kref needed by the EM framework. The 'struct em_perf_table'
|
||||
contains array 'struct em_perf_state state[]' which is a list of performance
|
||||
states in ascending order. That list must be populated by the device driver
|
||||
which wants to update the EM. The list of frequencies can be taken from
|
||||
existing EM (created during boot). The content in the 'struct em_perf_state'
|
||||
must be populated by the driver as well.
|
||||
|
||||
This is the API which does the EM update, using RCU pointers swap::
|
||||
|
||||
int em_dev_update_perf_domain(struct device *dev,
|
||||
struct em_perf_table __rcu *new_table);
|
||||
|
||||
Drivers must provide a pointer to the allocated and initialized new EM
|
||||
'struct em_perf_table'. That new EM will be safely used inside the EM framework
|
||||
and will be visible to other sub-systems in the kernel (thermal, powercap).
|
||||
The main design goal for this API is to be fast and avoid extra calculations
|
||||
or memory allocations at runtime. When pre-computed EMs are available in the
|
||||
device driver, than it should be possible to simply re-use them with low
|
||||
performance overhead.
|
||||
|
||||
In order to free the EM, provided earlier by the driver (e.g. when the module
|
||||
is unloaded), there is a need to call the API::
|
||||
|
||||
void em_table_free(struct em_perf_table __rcu *table);
|
||||
|
||||
It will allow the EM framework to safely remove the memory, when there is
|
||||
no other sub-system using it, e.g. EAS.
|
||||
|
||||
To use the power values in other sub-systems (like thermal, powercap) there is
|
||||
a need to call API which protects the reader and provide consistency of the EM
|
||||
table data::
|
||||
|
||||
struct em_perf_state *em_perf_state_from_pd(struct em_perf_domain *pd);
|
||||
|
||||
It returns the 'struct em_perf_state' pointer which is an array of performance
|
||||
states in ascending order.
|
||||
This function must be called in the RCU read lock section (after the
|
||||
rcu_read_lock()). When the EM table is not needed anymore there is a need to
|
||||
call rcu_real_unlock(). In this way the EM safely uses the RCU read section
|
||||
and protects the users. It also allows the EM framework to manage the memory
|
||||
and free it. More details how to use it can be found in Section 3.2 in the
|
||||
example driver.
|
||||
|
||||
There is dedicated API for device drivers to calculate em_perf_state::cost
|
||||
values::
|
||||
|
||||
int em_dev_compute_costs(struct device *dev, struct em_perf_state *table,
|
||||
int nr_states);
|
||||
|
||||
These 'cost' values from EM are used in EAS. The new EM table should be passed
|
||||
together with the number of entries and device pointer. When the computation
|
||||
of the cost values is done properly the return value from the function is 0.
|
||||
The function takes care for right setting of inefficiency for each performance
|
||||
state as well. It updates em_perf_state::flags accordingly.
|
||||
Then such prepared new EM can be passed to the em_dev_update_perf_domain()
|
||||
function, which will allow to use it.
|
||||
|
||||
More details about the above APIs can be found in ``<linux/energy_model.h>``
|
||||
or in Section 3.2 with an example code showing simple implementation of the
|
||||
updating mechanism in a device driver.
|
||||
|
||||
|
||||
2.5 Description details of this API
|
||||
2.4 Description details of this API
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
.. kernel-doc:: include/linux/energy_model.h
|
||||
:internal:
|
||||
|
|
@ -284,11 +187,8 @@ updating mechanism in a device driver.
|
|||
:export:
|
||||
|
||||
|
||||
3. Examples
|
||||
-----------
|
||||
|
||||
3.1 Example driver with EM registration
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
3. Example driver
|
||||
-----------------
|
||||
|
||||
The CPUFreq framework supports dedicated callback for registering
|
||||
the EM for a given CPU(s) 'policy' object: cpufreq_driver::register_em().
|
||||
|
|
@ -342,78 +242,3 @@ EM framework::
|
|||
39 static struct cpufreq_driver foo_cpufreq_driver = {
|
||||
40 .register_em = foo_cpufreq_register_em,
|
||||
41 };
|
||||
|
||||
|
||||
3.2 Example driver with EM modification
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
This section provides a simple example of a thermal driver modifying the EM.
|
||||
The driver implements a foo_thermal_em_update() function. The driver is woken
|
||||
up periodically to check the temperature and modify the EM data::
|
||||
|
||||
-> drivers/soc/example/example_em_mod.c
|
||||
|
||||
01 static void foo_get_new_em(struct foo_context *ctx)
|
||||
02 {
|
||||
03 struct em_perf_table __rcu *em_table;
|
||||
04 struct em_perf_state *table, *new_table;
|
||||
05 struct device *dev = ctx->dev;
|
||||
06 struct em_perf_domain *pd;
|
||||
07 unsigned long freq;
|
||||
08 int i, ret;
|
||||
09
|
||||
10 pd = em_pd_get(dev);
|
||||
11 if (!pd)
|
||||
12 return;
|
||||
13
|
||||
14 em_table = em_table_alloc(pd);
|
||||
15 if (!em_table)
|
||||
16 return;
|
||||
17
|
||||
18 new_table = em_table->state;
|
||||
19
|
||||
20 rcu_read_lock();
|
||||
21 table = em_perf_state_from_pd(pd);
|
||||
22 for (i = 0; i < pd->nr_perf_states; i++) {
|
||||
23 freq = table[i].frequency;
|
||||
24 foo_get_power_perf_values(dev, freq, &new_table[i]);
|
||||
25 }
|
||||
26 rcu_read_unlock();
|
||||
27
|
||||
28 /* Calculate 'cost' values for EAS */
|
||||
29 ret = em_dev_compute_costs(dev, table, pd->nr_perf_states);
|
||||
30 if (ret) {
|
||||
31 dev_warn(dev, "EM: compute costs failed %d\n", ret);
|
||||
32 em_free_table(em_table);
|
||||
33 return;
|
||||
34 }
|
||||
35
|
||||
36 ret = em_dev_update_perf_domain(dev, em_table);
|
||||
37 if (ret) {
|
||||
38 dev_warn(dev, "EM: update failed %d\n", ret);
|
||||
39 em_free_table(em_table);
|
||||
40 return;
|
||||
41 }
|
||||
42
|
||||
43 /*
|
||||
44 * Since it's one-time-update drop the usage counter.
|
||||
45 * The EM framework will later free the table when needed.
|
||||
46 */
|
||||
47 em_table_free(em_table);
|
||||
48 }
|
||||
49
|
||||
50 /*
|
||||
51 * Function called periodically to check the temperature and
|
||||
52 * update the EM if needed
|
||||
53 */
|
||||
54 static void foo_thermal_em_update(struct foo_context *ctx)
|
||||
55 {
|
||||
56 struct device *dev = ctx->dev;
|
||||
57 int cpu;
|
||||
58
|
||||
59 ctx->temperature = foo_get_temp(dev, ctx);
|
||||
60 if (ctx->temperature < FOO_EM_UPDATE_TEMP_THRESHOLD)
|
||||
61 return;
|
||||
62
|
||||
63 foo_get_new_em(ctx);
|
||||
64 }
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ you probably needn't concern yourself with pcmciautils.
|
|||
====================== =============== ========================================
|
||||
GNU C 5.1 gcc --version
|
||||
Clang/LLVM (optional) 11.0.0 clang --version
|
||||
Rust (optional) 1.71.1 rustc --version
|
||||
Rust (optional) 1.73.0 rustc --version
|
||||
bindgen (optional) 0.65.1 bindgen --version
|
||||
GNU make 3.82 make --version
|
||||
bash 4.2 bash --version
|
||||
|
|
|
|||
|
|
@ -402,7 +402,7 @@ Consequently, the only sane governor to use together with EAS is schedutil,
|
|||
because it is the only one providing some degree of consistency between
|
||||
frequency requests and energy predictions.
|
||||
|
||||
Using EAS with any other governor than schedutil is not recommended.
|
||||
Using EAS with any other governor than schedutil is not supported.
|
||||
|
||||
|
||||
6.5 Scale-invariant utilization signals
|
||||
|
|
|
|||
|
|
@ -90,8 +90,8 @@ For more detail see:
|
|||
- Documentation/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization"
|
||||
|
||||
|
||||
UTIL_EST
|
||||
========
|
||||
UTIL_EST / UTIL_EST_FASTUP
|
||||
==========================
|
||||
|
||||
Because periodic tasks have their averages decayed while they sleep, even
|
||||
though when running their expected utilization will be the same, they suffer a
|
||||
|
|
@ -99,7 +99,8 @@ though when running their expected utilization will be the same, they suffer a
|
|||
|
||||
To alleviate this (a default enabled option) UTIL_EST drives an Infinite
|
||||
Impulse Response (IIR) EWMA with the 'running' value on dequeue -- when it is
|
||||
highest. UTIL_EST filters to instantly increase and only decay on decrease.
|
||||
highest. A further default enabled option UTIL_EST_FASTUP modifies the IIR
|
||||
filter to instantly increase and only decay on decrease.
|
||||
|
||||
A further runqueue wide sum (of runnable tasks) is maintained of:
|
||||
|
||||
|
|
|
|||
|
|
@ -107,14 +107,14 @@ GetOptions(
|
|||
);
|
||||
|
||||
# Defaults for dynamically discovered regex's
|
||||
my $regex_direct_begin_default = 'order=([0-9]*) gfp_flags=([A-Z_|]*)';
|
||||
my $regex_direct_begin_default = 'order=([0-9]*) may_writepage=([0-9]*) gfp_flags=([A-Z_|]*)';
|
||||
my $regex_direct_end_default = 'nr_reclaimed=([0-9]*)';
|
||||
my $regex_kswapd_wake_default = 'nid=([0-9]*) order=([0-9]*)';
|
||||
my $regex_kswapd_sleep_default = 'nid=([0-9]*)';
|
||||
my $regex_wakeup_kswapd_default = 'nid=([0-9]*) order=([0-9]*) gfp_flags=([A-Z_|]*)';
|
||||
my $regex_lru_isolate_default = 'classzone=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) nr_taken=([0-9]*) lru=([a-z_]*)';
|
||||
my $regex_wakeup_kswapd_default = 'nid=([0-9]*) zid=([0-9]*) order=([0-9]*) gfp_flags=([A-Z_|]*)';
|
||||
my $regex_lru_isolate_default = 'isolate_mode=([0-9]*) classzone_idx=([0-9]*) order=([0-9]*) nr_requested=([0-9]*) nr_scanned=([0-9]*) nr_skipped=([0-9]*) nr_taken=([0-9]*) lru=([a-z_]*)';
|
||||
my $regex_lru_shrink_inactive_default = 'nid=([0-9]*) nr_scanned=([0-9]*) nr_reclaimed=([0-9]*) nr_dirty=([0-9]*) nr_writeback=([0-9]*) nr_congested=([0-9]*) nr_immediate=([0-9]*) nr_activate_anon=([0-9]*) nr_activate_file=([0-9]*) nr_ref_keep=([0-9]*) nr_unmap_fail=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)';
|
||||
my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_taken=([0-9]*) nr_active=([0-9]*) nr_deactivated=([0-9]*) nr_referenced=([0-9]*) priority=([0-9]*) flags=([A-Z_|]*)' ;
|
||||
my $regex_lru_shrink_active_default = 'lru=([A-Z_]*) nr_scanned=([0-9]*) nr_rotated=([0-9]*) priority=([0-9]*)';
|
||||
my $regex_writepage_default = 'page=([0-9a-f]*) pfn=([0-9]*) flags=([A-Z_|]*)';
|
||||
|
||||
# Dyanically discovered regex
|
||||
|
|
@ -184,7 +184,8 @@ sub generate_traceevent_regex {
|
|||
$regex_direct_begin = generate_traceevent_regex(
|
||||
"vmscan/mm_vmscan_direct_reclaim_begin",
|
||||
$regex_direct_begin_default,
|
||||
"order", "gfp_flags");
|
||||
"order", "may_writepage",
|
||||
"gfp_flags");
|
||||
$regex_direct_end = generate_traceevent_regex(
|
||||
"vmscan/mm_vmscan_direct_reclaim_end",
|
||||
$regex_direct_end_default,
|
||||
|
|
@ -200,11 +201,11 @@ $regex_kswapd_sleep = generate_traceevent_regex(
|
|||
$regex_wakeup_kswapd = generate_traceevent_regex(
|
||||
"vmscan/mm_vmscan_wakeup_kswapd",
|
||||
$regex_wakeup_kswapd_default,
|
||||
"nid", "order", "gfp_flags");
|
||||
"nid", "zid", "order", "gfp_flags");
|
||||
$regex_lru_isolate = generate_traceevent_regex(
|
||||
"vmscan/mm_vmscan_lru_isolate",
|
||||
$regex_lru_isolate_default,
|
||||
"classzone", "order",
|
||||
"isolate_mode", "classzone_idx", "order",
|
||||
"nr_requested", "nr_scanned", "nr_skipped", "nr_taken",
|
||||
"lru");
|
||||
$regex_lru_shrink_inactive = generate_traceevent_regex(
|
||||
|
|
@ -217,10 +218,11 @@ $regex_lru_shrink_inactive = generate_traceevent_regex(
|
|||
$regex_lru_shrink_active = generate_traceevent_regex(
|
||||
"vmscan/mm_vmscan_lru_shrink_active",
|
||||
$regex_lru_shrink_active_default,
|
||||
"nid", "nr_taken", "nr_active", "nr_deactivated", "nr_referenced",
|
||||
"priority", "flags");
|
||||
"nid", "zid",
|
||||
"lru",
|
||||
"nr_scanned", "nr_rotated", "priority");
|
||||
$regex_writepage = generate_traceevent_regex(
|
||||
"vmscan/mm_vmscan_write_folio",
|
||||
"vmscan/mm_vmscan_writepage",
|
||||
$regex_writepage_default,
|
||||
"page", "pfn", "flags");
|
||||
|
||||
|
|
@ -369,7 +371,7 @@ EVENT_PROCESS:
|
|||
print " $regex_wakeup_kswapd\n";
|
||||
next;
|
||||
}
|
||||
my $order = $2;
|
||||
my $order = $3;
|
||||
$perprocesspid{$process_pid}->{MM_VMSCAN_WAKEUP_KSWAPD_PERORDER}[$order]++;
|
||||
} elsif ($tracepoint eq "mm_vmscan_lru_isolate") {
|
||||
$details = $6;
|
||||
|
|
@ -379,14 +381,18 @@ EVENT_PROCESS:
|
|||
print " $regex_lru_isolate/o\n";
|
||||
next;
|
||||
}
|
||||
my $nr_scanned = $4;
|
||||
my $lru = $7;
|
||||
my $isolate_mode = $1;
|
||||
my $nr_scanned = $5;
|
||||
my $file = $8;
|
||||
|
||||
# To closer match vmstat scanning statistics, only count
|
||||
# inactive lru as scanning
|
||||
if ($lru =~ /inactive_/) {
|
||||
# To closer match vmstat scanning statistics, only count isolate_both
|
||||
# and isolate_inactive as scanning. isolate_active is rotation
|
||||
# isolate_inactive == 1
|
||||
# isolate_active == 2
|
||||
# isolate_both == 3
|
||||
if ($isolate_mode != 2) {
|
||||
$perprocesspid{$process_pid}->{HIGH_NR_SCANNED} += $nr_scanned;
|
||||
if ($lru =~ /_file/) {
|
||||
if ($file =~ /_file/) {
|
||||
$perprocesspid{$process_pid}->{HIGH_NR_FILE_SCANNED} += $nr_scanned;
|
||||
} else {
|
||||
$perprocesspid{$process_pid}->{HIGH_NR_ANON_SCANNED} += $nr_scanned;
|
||||
|
|
|
|||
|
|
@ -89,15 +89,16 @@ r_cpu被定义为当前CPU的最高性能水平与系统中任何其它CPU的最
|
|||
- Documentation/translations/zh_CN/scheduler/sched-capacity.rst:"1. CPU Capacity + 2. Task utilization"
|
||||
|
||||
|
||||
UTIL_EST
|
||||
========
|
||||
UTIL_EST / UTIL_EST_FASTUP
|
||||
==========================
|
||||
|
||||
由于周期性任务的平均数在睡眠时会衰减，而在运行时其预期利用率会和睡眠前相同，
|
||||
因此它们在再次运行后会面临（DVFS）的上涨。
|
||||
|
||||
为了缓解这个问题，（一个默认使能的编译选项）UTIL_EST驱动一个无限脉冲响应
|
||||
（Infinite Impulse Response，IIR）的EWMA，“运行”值在出队时是最高的。
|
||||
UTIL_EST滤波使其在遇到更高值时立刻增加，而遇到低值时会缓慢衰减。
|
||||
另一个默认使能的编译选项UTIL_EST_FASTUP修改了IIR滤波器，使其允许立即增加，
|
||||
仅在利用率下降时衰减。
|
||||
|
||||
进一步，运行队列的（可运行任务的）利用率之和由下式计算：
|
||||
|
||||
|
|
|
|||
|
|
@ -137,7 +137,6 @@ Code Seq# Include File Comments
|
|||
'F' DD video/sstfb.h conflict!
|
||||
'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict!
|
||||
'G' 00-0F xen/gntalloc.h, xen/gntdev.h conflict!
|
||||
'G' 00-0F linux/gunyah.h conflict!
|
||||
'H' 00-7F linux/hiddev.h conflict!
|
||||
'H' 00-0F linux/hidraw.h conflict!
|
||||
'H' 01 linux/mei.h conflict!
|
||||
|
|
|
|||
|
|
@ -602,17 +602,6 @@ Buffer Flags
|
|||
the format. Any subsequent call to the
|
||||
:ref:`VIDIOC_DQBUF <VIDIOC_QBUF>` ioctl will not block anymore,
|
||||
but return an ``EPIPE`` error code.
|
||||
* .. _`V4L2-BUF-FLAG-HEADERS-ONLY`:
|
||||
|
||||
- ``V4L2_BUF_FLAG_HEADERS_ONLY``
|
||||
- 0x00200000
|
||||
- This flag may be set when the buffer only contains codec
|
||||
header, but does not contain any frame data. Usually the codec
|
||||
header is merged to the next idr frame, with the flag
|
||||
``V4L2_BUF_FLAG_KEYFRAME``, but there is still some scenes that will
|
||||
split the header and queue it separately. This flag can set only when
|
||||
codec support V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE,
|
||||
and the header mode is set to V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE
|
||||
* .. _`V4L2-BUF-FLAG-REQUEST-FD`:
|
||||
|
||||
- ``V4L2_BUF_FLAG_REQUEST_FD``
|
||||
|
|
|
|||
|
|
@ -1386,12 +1386,8 @@ enum v4l2_mpeg_video_intra_refresh_period_type -
|
|||
(enum)
|
||||
|
||||
enum v4l2_mpeg_video_header_mode -
|
||||
Determines whether the header is returned as the first buffer
|
||||
with flag V4L2_BUF_FLAG_HEADERS_ONLY or is
|
||||
it returned together with the first frame.
|
||||
Applicable to encoders and decoders.
|
||||
If it's not implemented in a driver,
|
||||
V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME is to be assumed,
|
||||
Determines whether the header is returned as the first buffer or is
|
||||
it returned together with the first frame. Applicable to encoders.
|
||||
Possible values are:
|
||||
|
||||
.. raw:: latex
|
||||
|
|
@ -1405,7 +1401,7 @@ enum v4l2_mpeg_video_header_mode -
|
|||
:stub-columns: 0
|
||||
|
||||
* - ``V4L2_MPEG_VIDEO_HEADER_MODE_SEPARATE``
|
||||
- The stream header is returned separately in the first buffer with the flag V4L2_BUF_FLAG_HEADERS_ONLY.
|
||||
- The stream header is returned separately in the first buffer.
|
||||
* - ``V4L2_MPEG_VIDEO_HEADER_MODE_JOINED_WITH_1ST_FRAME``
|
||||
- The stream header is returned together with the first encoded
|
||||
frame.
|
||||
|
|
|
|||
|
|
@ -1,87 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
======================
|
||||
GenieZone Introduction
|
||||
======================
|
||||
|
||||
Overview
|
||||
========
|
||||
GenieZone hypervisor (gzvm) is a type-I hypervisor that supports various virtual
|
||||
machine types and provides security features such as TEE-like scenarios and
|
||||
secure boot. It can create guest VMs for security use cases and has
|
||||
virtualization capabilities for both platform and interrupt. Although the
|
||||
hypervisor can be booted independently, it requires the assistance of GenieZone
|
||||
hypervisor kernel driver (also named gzvm) to leverage the ability of Linux
|
||||
kernel for vCPU scheduling, memory management, inter-VM communication and virtio
|
||||
backend support.
|
||||
|
||||
Supported Architecture
|
||||
======================
|
||||
GenieZone now only supports MediaTek ARM64 SoC.
|
||||
|
||||
Features
|
||||
========
|
||||
|
||||
- vCPU Management
|
||||
|
||||
VM manager aims to provide vCPUs on the basis of time sharing on physical
|
||||
CPUs. It requires Linux kernel in host VM for vCPU scheduling and VM power
|
||||
management.
|
||||
|
||||
- Memory Management
|
||||
|
||||
Direct use of physical memory from VMs is forbidden and designed to be
|
||||
dictated to the privilege models managed by GenieZone hypervisor for security
|
||||
reason. With the help of the gzvm module, the hypervisor is able to manipulate
|
||||
memory as objects.
|
||||
|
||||
- Virtual Platform
|
||||
|
||||
The gzvm hypervisor emulates a virtual mobile platform for guest OS running on
|
||||
guest VM. The platform supports various architecture-defined devices, such as
|
||||
virtual arch timer, GIC, MMIO, PSCI, and exception watching...etc.
|
||||
|
||||
- Inter-VM Communication
|
||||
|
||||
Communication among guest VMs is provided mainly on RPC. More communication
|
||||
mechanisms will be provided in the future based on VirtIO-vsock.
|
||||
|
||||
- Device Virtualization
|
||||
|
||||
The solution is provided using the well-known VirtIO. The gzvm module redirects
|
||||
MMIO traps back to VMM where the virtual devices are mostly emulated.
|
||||
Ioeventfd is implemented using eventfd for signaling host VM that some IO
|
||||
events in guest VMs need to be processed.
|
||||
|
||||
- Interrupt virtualization
|
||||
|
||||
All interrupts during some guest VMs running are handled by GenieZone
|
||||
hypervisor with the help of gzvm module, both virtual and physical ones.
|
||||
In case there's no guest VM running, physical interrupts are handled by host
|
||||
VM directly for performance reason. Irqfd is also implemented using eventfd
|
||||
for accepting vIRQ requests in gzvm module.
|
||||
|
||||
Platform architecture component
|
||||
===============================
|
||||
|
||||
- vm
|
||||
|
||||
The vm component is responsible for setting up the capability and memory
|
||||
management for the protected VMs. The capability is mainly about the lifecycle
|
||||
control and boot context initialization. And the memory management is highly
|
||||
integrated with ARM 2-stage translation tables to convert VA to IPA to PA
|
||||
under proper security measures required by protected VMs.
|
||||
|
||||
- vcpu
|
||||
|
||||
The vcpu component is the core of virtualizing an aarch64 physical CPU, and it
|
||||
controls the vCPU lifecycle including creating, running and destroying.
|
||||
With self-defined exit handler, the vm component is able to act accordingly
|
||||
before termination.
|
||||
|
||||
- vgic
|
||||
|
||||
The vgic component exposes control interfaces to Linux kernel via irqchip, and
|
||||
we intend to support all SPI, PPI, and SGI. When it comes to virtual
|
||||
interrupts, the GenieZone hypervisor writes to list registers and triggers
|
||||
vIRQ injection in guest VMs via GIC.
|
||||
|
|
@ -1,135 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================
|
||||
Gunyah Hypervisor
|
||||
=================
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 1
|
||||
|
||||
message-queue
|
||||
|
||||
Gunyah is a Type-1 hypervisor which is independent of any OS kernel, and runs in
|
||||
a more privileged CPU level (EL2 on Aarch64). It does not depend on a less
|
||||
privileged operating system for its core functionality. This increases its
|
||||
security and can support a much smaller trusted computing base than a Type-2
|
||||
hypervisor.
|
||||
|
||||
Gunyah is an open source hypervisor. The source repository is available at
|
||||
https://github.com/quic/gunyah-hypervisor.
|
||||
|
||||
Gunyah provides these following features.
|
||||
|
||||
- Scheduling:
|
||||
|
||||
A scheduler for virtual CPUs (vCPUs) on physical CPUs enables time-sharing
|
||||
of the CPUs. Gunyah supports two models of scheduling which can coexist on
|
||||
a running system:
|
||||
|
||||
1. Hypervisor vCPU scheduling in which Gunyah hypervisor schedules vCPUS on
|
||||
its own. The default is a real-time priority with round-robin scheduler.
|
||||
2. "Proxy" scheduling in which an owner-VM can donate the remainder of its
|
||||
own vCPU's time slice to an owned-VM's vCPU via a hypercall.
|
||||
|
||||
- Memory Management:
|
||||
|
||||
APIs handling memory, abstracted as objects, limiting direct use of physical
|
||||
addresses. Memory ownership and usage tracking of all memory under its control.
|
||||
Memory partitioning between VMs is a fundamental security feature.
|
||||
|
||||
- Interrupt Virtualization:
|
||||
|
||||
Interrupt ownership is tracked and interrupt delivery is directly to the
|
||||
assigned VM. Gunyah makes use of hardware interrupt virtualization where
|
||||
possible.
|
||||
|
||||
- Inter-VM Communication:
|
||||
|
||||
There are several different mechanisms provided for communicating between VMs.
|
||||
|
||||
1. Message queues
|
||||
2. Doorbells
|
||||
3. Virtio MMIO transport
|
||||
4. Shared memory
|
||||
|
||||
- Virtual platform:
|
||||
|
||||
Architectural devices such as interrupt controllers and CPU timers are
|
||||
directly provided by the hypervisor as well as core virtual platform devices
|
||||
and system APIs such as ARM PSCI.
|
||||
|
||||
- Device Virtualization:
|
||||
|
||||
Para-virtualization of devices is supported using inter-VM communication and
|
||||
virtio transport support. Select stage 2 faults by virtual machines that use
|
||||
proxy-scheduled vCPUs can be handled directly by Linux to provide Type-2
|
||||
hypervisor style on-demand paging and/or device emulation.
|
||||
|
||||
Architectures supported
|
||||
=======================
|
||||
AArch64 with a GICv3 or GICv4.1
|
||||
|
||||
Resources and Capabilities
|
||||
==========================
|
||||
|
||||
Services/resources provided by the Gunyah hypervisor are accessible to a
|
||||
virtual machine through capabilities. A capability is an access control
|
||||
token granting the holder a set of permissions to operate on a specific
|
||||
hypervisor object (conceptually similar to a file-descriptor).
|
||||
For example, inter-VM communication using Gunyah doorbells and message queues
|
||||
is performed using hypercalls taking Capability ID arguments for the required
|
||||
IPC objects. These resources are described in Linux as a struct gunyah_resource.
|
||||
|
||||
Unlike UNIX file descriptors, there is no path-based or similar lookup of
|
||||
an object to create a new Capability, meaning simpler security analysis.
|
||||
Creation of a new Capability requires the holding of a set of privileged
|
||||
Capabilities which are typically never given out by the Resource Manager (RM).
|
||||
|
||||
Gunyah itself provides no APIs for Capability ID discovery. Enumeration of
|
||||
Capability IDs is provided by RM as a higher level service to VMs.
|
||||
|
||||
Resource Manager
|
||||
================
|
||||
|
||||
The Gunyah Resource Manager (RM) is a privileged application VM supporting the
|
||||
Gunyah Hypervisor. It provides policy enforcement aspects of the virtualization
|
||||
system. The resource manager can be treated as an extension of the Hypervisor
|
||||
but is separated to its own partition to ensure that the hypervisor layer itself
|
||||
remains small and secure and to maintain a separation of policy and mechanism in
|
||||
the platform. The resource manager runs at arm64 NS-EL1, similar to other
|
||||
virtual machines.
|
||||
|
||||
Communication with the resource manager from other virtual machines happens as
|
||||
described in message-queue.rst. Details about the specific messages can be found
|
||||
in drivers/virt/gunyah/rsc_mgr.c
|
||||
|
||||
::
|
||||
|
||||
+-------+ +--------+ +--------+
|
||||
| RM | | VM_A | | VM_B |
|
||||
+-.-.-.-+ +---.----+ +---.----+
|
||||
| | | |
|
||||
+-.-.-----------.------------.----+
|
||||
| | \==========/ | |
|
||||
| \========================/ |
|
||||
| Gunyah |
|
||||
+---------------------------------+
|
||||
|
||||
The source for the resource manager is available at
|
||||
https://github.com/quic/gunyah-resource-manager.
|
||||
|
||||
The resource manager provides the following features:
|
||||
|
||||
- VM lifecycle management: allocating a VM, starting VMs, destruction of VMs
|
||||
- VM access control policy, including memory sharing and lending
|
||||
- Interrupt routing configuration
|
||||
- Forwarding of system-level events (e.g. VM shutdown) to owner VM
|
||||
- Resource (capability) discovery
|
||||
|
||||
A VM requires boot configuration to establish communication with the resource
|
||||
manager. This is provided to VMs via a 'hypervisor' device tree node which is
|
||||
overlaid to the VMs DT by the RM. This node lets guests know they are running
|
||||
as a Gunyah guest VM, how to communicate with resource manager, and basic
|
||||
description and capabilities of this VM. See
|
||||
Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml for a
|
||||
description of this node.
|
||||
|
|
@ -1,68 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Message Queues
|
||||
==============
|
||||
Message queue is a simple low-capacity IPC channel between two virtual machines.
|
||||
It is intended for sending small control and configuration messages. Each
|
||||
message queue is unidirectional and buffered in the hypervisor. A full-duplex
|
||||
IPC channel requires a pair of queues.
|
||||
|
||||
The size of the queue and the maximum size of the message that can be passed is
|
||||
fixed at creation of the message queue. Resource manager is presently the only
|
||||
use case for message queues, and creates messages queues between itself and VMs
|
||||
with a fixed maximum message size of 240 bytes. Longer messages require a
|
||||
further protocol on top of the message queue messages themselves. For instance,
|
||||
communication with the resource manager adds a header field for sending longer
|
||||
messages which are split into smaller fragments.
|
||||
|
||||
The diagram below shows how message queue works. A typical configuration
|
||||
involves 2 message queues. Message queue 1 allows VM_A to send messages to VM_B.
|
||||
Message queue 2 allows VM_B to send messages to VM_A.
|
||||
|
||||
1. VM_A sends a message of up to 240 bytes in length. It makes a hypercall
|
||||
with the message to request the hypervisor to add the message to
|
||||
message queue 1's queue. The hypervisor copies memory into the internal
|
||||
message queue buffer; the memory doesn't need to be shared between
|
||||
VM_A and VM_B.
|
||||
|
||||
2. Gunyah raises the corresponding interrupt for VM_B (Rx vIRQ) when any of
|
||||
these happens:
|
||||
|
||||
a. gunyah_msgq_send() has PUSH flag. This is a typical case when the message
|
||||
queue is being used to implement an RPC-like interface.
|
||||
b. Explicitly with gunyah_msgq_push hypercall from VM_A.
|
||||
c. Message queue has reached a threshold depth. Typically, this threshold
|
||||
depth is the size of the queue (in other words: when queue is full, Rx
|
||||
vIRQ is raised).
|
||||
|
||||
3. VM_B calls gunyah_msgq_recv() and Gunyah copies message to requested buffer.
|
||||
|
||||
4. Gunyah raises the corresponding interrupt for VM_A (Tx vIRQ) when the message
|
||||
queue falls below a watermark depth. Typically, this is when the queue is
|
||||
drained. Note the watermark depth and the threshold depth for the Rx vIRQ are
|
||||
independent values. Coincidentally, this signal is conceptually similar to
|
||||
Clear-to-Send.
|
||||
|
||||
For VM_B to send a message to VM_A, the process is identical, except that
|
||||
hypercalls reference message queue 2's capability ID. The IRQ will be different
|
||||
for the second message queue.
|
||||
|
||||
::
|
||||
|
||||
+-------------------+ +-----------------+ +-------------------+
|
||||
| VM_A | |Gunyah hypervisor| | VM_B |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
| | Tx | | | |
|
||||
| |-------->| | Rx vIRQ | |
|
||||
|gunyah_msgq_send() | Tx vIRQ |Message queue 1 |-------->|gunyah_msgq_recv() |
|
||||
| |<------- | | | |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
| | | | Tx | |
|
||||
| | Rx vIRQ | |<--------| |
|
||||
|gunyah_msgq_recv() |<--------|Message queue 2 | Tx vIRQ |gunyah_msgq_send() |
|
||||
| | | |-------->| |
|
||||
| | | | | |
|
||||
| | | | | |
|
||||
+-------------------+ +-----------------+ +---------------+
|
||||
|
|
@ -16,8 +16,6 @@ Virtualization Support
|
|||
coco/sev-guest
|
||||
coco/tdx-guest
|
||||
hyperv/index
|
||||
geniezone/introduction
|
||||
gunyah/index
|
||||
|
||||
.. only:: html and subproject
|
||||
|
||||
|
|
|
|||
|
|
@ -6612,13 +6612,6 @@ Note that KVM does not skip the faulting instruction as it does for
|
|||
KVM_EXIT_MMIO, but userspace has to emulate any change to the processing state
|
||||
if it decides to decode and emulate the instruction.
|
||||
|
||||
This feature isn't available to protected VMs, as userspace does not
|
||||
have access to the state that is required to perform the emulation.
|
||||
Instead, a data abort exception is directly injected in the guest.
|
||||
Note that although KVM_CAP_ARM_NISV_TO_USER will be reported if
|
||||
queried outside of a protected VM context, the feature will not be
|
||||
exposed if queried on a protected VM file descriptor.
|
||||
|
||||
::
|
||||
|
||||
/* KVM_EXIT_X86_RDMSR / KVM_EXIT_X86_WRMSR */
|
||||
|
|
|
|||
|
|
@ -1,138 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=======================================
|
||||
ARM firmware pseudo-registers interface
|
||||
=======================================
|
||||
|
||||
KVM handles the hypercall services as requested by the guests. New hypercall
|
||||
services are regularly made available by the ARM specification or by KVM (as
|
||||
vendor services) if they make sense from a virtualization point of view.
|
||||
|
||||
This means that a guest booted on two different versions of KVM can observe
|
||||
two different "firmware" revisions. This could cause issues if a given guest
|
||||
is tied to a particular version of a hypercall service, or if a migration
|
||||
causes a different version to be exposed out of the blue to an unsuspecting
|
||||
guest.
|
||||
|
||||
In order to remedy this situation, KVM exposes a set of "firmware
|
||||
pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
|
||||
interface. These registers can be saved/restored by userspace, and set
|
||||
to a convenient value as required.
|
||||
|
||||
The following registers are defined:
|
||||
|
||||
* KVM_REG_ARM_PSCI_VERSION:
|
||||
|
||||
KVM implements the PSCI (Power State Coordination Interface)
|
||||
specification in order to provide services such as CPU on/off, reset
|
||||
and power-off to the guest.
|
||||
|
||||
- Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set
|
||||
(and thus has already been initialized)
|
||||
- Returns the current PSCI version on GET_ONE_REG (defaulting to the
|
||||
highest PSCI version implemented by KVM and compatible with v0.2)
|
||||
- Allows any PSCI version implemented by KVM and compatible with
|
||||
v0.2 to be set with SET_ONE_REG
|
||||
- Affects the whole VM (even if the register view is per-vcpu)
|
||||
|
||||
* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
|
||||
Holds the state of the firmware support to mitigate CVE-2017-5715, as
|
||||
offered by KVM to the guest via a HVC call. The workaround is described
|
||||
under SMCCC_ARCH_WORKAROUND_1 in [1].
|
||||
|
||||
Accepted values are:
|
||||
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL:
|
||||
KVM does not offer
|
||||
firmware support for the workaround. The mitigation status for the
|
||||
guest is unknown.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL:
|
||||
The workaround HVC call is
|
||||
available to the guest and required for the mitigation.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED:
|
||||
The workaround HVC call
|
||||
is available to the guest, but it is not needed on this VCPU.
|
||||
|
||||
* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
|
||||
Holds the state of the firmware support to mitigate CVE-2018-3639, as
|
||||
offered by KVM to the guest via a HVC call. The workaround is described
|
||||
under SMCCC_ARCH_WORKAROUND_2 in [1]_.
|
||||
|
||||
Accepted values are:
|
||||
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
|
||||
A workaround is not
|
||||
available. KVM does not offer firmware support for the workaround.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
|
||||
The workaround state is
|
||||
unknown. KVM does not offer firmware support for the workaround.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
|
||||
The workaround is available,
|
||||
and can be disabled by a vCPU. If
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED is set, it is active for
|
||||
this vCPU.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
|
||||
The workaround is always active on this vCPU or it is not needed.
|
||||
|
||||
|
||||
Bitmap Feature Firmware Registers
|
||||
---------------------------------
|
||||
|
||||
Contrary to the above registers, the following registers exposes the
|
||||
hypercall services in the form of a feature-bitmap to the userspace. This
|
||||
bitmap is translated to the services that are available to the guest.
|
||||
There is a register defined per service call owner and can be accessed via
|
||||
GET/SET_ONE_REG interface.
|
||||
|
||||
By default, these registers are set with the upper limit of the features
|
||||
that are supported. This way userspace can discover all the usable
|
||||
hypercall services via GET_ONE_REG. The user-space can write-back the
|
||||
desired bitmap back via SET_ONE_REG. The features for the registers that
|
||||
are untouched, probably because userspace isn't aware of them, will be
|
||||
exposed as is to the guest.
|
||||
|
||||
Note that KVM will not allow the userspace to configure the registers
|
||||
anymore once any of the vCPUs has run at least once. Instead, it will
|
||||
return a -EBUSY.
|
||||
|
||||
The pseudo-firmware bitmap register are as follows:
|
||||
|
||||
* KVM_REG_ARM_STD_BMAP:
|
||||
Controls the bitmap of the ARM Standard Secure Service Calls.
|
||||
|
||||
The following bits are accepted:
|
||||
|
||||
Bit-0: KVM_REG_ARM_STD_BIT_TRNG_V1_0:
|
||||
The bit represents the services offered under v1.0 of ARM True Random
|
||||
Number Generator (TRNG) specification, ARM DEN0098.
|
||||
|
||||
* KVM_REG_ARM_STD_HYP_BMAP:
|
||||
Controls the bitmap of the ARM Standard Hypervisor Service Calls.
|
||||
|
||||
The following bits are accepted:
|
||||
|
||||
Bit-0: KVM_REG_ARM_STD_HYP_BIT_PV_TIME:
|
||||
The bit represents the Paravirtualized Time service as represented by
|
||||
ARM DEN0057A.
|
||||
|
||||
* KVM_REG_ARM_VENDOR_HYP_BMAP:
|
||||
Controls the bitmap of the Vendor specific Hypervisor Service Calls.
|
||||
|
||||
The following bits are accepted:
|
||||
|
||||
Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT
|
||||
The bit represents the ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID
|
||||
and ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID function-ids.
|
||||
|
||||
Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP:
|
||||
The bit represents the Precision Time Protocol KVM service.
|
||||
|
||||
Errors:
|
||||
|
||||
======= =============================================================
|
||||
-ENOENT Unknown register accessed.
|
||||
-EBUSY Attempt a 'write' to the register after the VM has started.
|
||||
-EINVAL Invalid bitmap written to the register.
|
||||
======= =============================================================
|
||||
|
||||
.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
|
||||
|
|
@ -1,190 +1,138 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===============================================
|
||||
KVM/arm64-specific hypercalls exposed to guests
|
||||
===============================================
|
||||
=======================
|
||||
ARM Hypercall Interface
|
||||
=======================
|
||||
|
||||
This file documents the KVM/arm64-specific hypercalls which may be
|
||||
exposed by KVM/arm64 to guest operating systems. These hypercalls are
|
||||
issued using the HVC instruction according to version 1.1 of the Arm SMC
|
||||
Calling Convention (DEN0028/C):
|
||||
KVM handles the hypercall services as requested by the guests. New hypercall
|
||||
services are regularly made available by the ARM specification or by KVM (as
|
||||
vendor services) if they make sense from a virtualization point of view.
|
||||
|
||||
https://developer.arm.com/docs/den0028/c
|
||||
This means that a guest booted on two different versions of KVM can observe
|
||||
two different "firmware" revisions. This could cause issues if a given guest
|
||||
is tied to a particular version of a hypercall service, or if a migration
|
||||
causes a different version to be exposed out of the blue to an unsuspecting
|
||||
guest.
|
||||
|
||||
All KVM/arm64-specific hypercalls are allocated within the "Vendor
|
||||
Specific Hypervisor Service Call" range with a UID of
|
||||
``28b46fb6-2ec5-11e9-a9ca-4b564d003a74``. This UID should be queried by the
|
||||
guest using the standard "Call UID" function for the service range in
|
||||
order to determine that the KVM/arm64-specific hypercalls are available.
|
||||
In order to remedy this situation, KVM exposes a set of "firmware
|
||||
pseudo-registers" that can be manipulated using the GET/SET_ONE_REG
|
||||
interface. These registers can be saved/restored by userspace, and set
|
||||
to a convenient value as required.
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_FEATURES``
|
||||
---------------------------------------------
|
||||
The following registers are defined:
|
||||
|
||||
Provides a discovery mechanism for other KVM/arm64 hypercalls.
|
||||
* KVM_REG_ARM_PSCI_VERSION:
|
||||
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Presence: | Mandatory for the KVM/arm64 UID |
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Calling convention: | HVC32 |
|
||||
+---------------------+----------+--------------------------------------------------+
|
||||
| Function ID: | (uint32) | 0x86000000 |
|
||||
+---------------------+----------+--------------------------------------------------+
|
||||
| Arguments: | None |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Return Values: | (uint32) | R0 | Bitmap of available function numbers 0-31 |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint32) | R1 | Bitmap of available function numbers 32-63 |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint32) | R2 | Bitmap of available function numbers 64-95 |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint32) | R3 | Bitmap of available function numbers 96-127 |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
KVM implements the PSCI (Power State Coordination Interface)
|
||||
specification in order to provide services such as CPU on/off, reset
|
||||
and power-off to the guest.
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_PTP``
|
||||
----------------------------------------
|
||||
- Only valid if the vcpu has the KVM_ARM_VCPU_PSCI_0_2 feature set
|
||||
(and thus has already been initialized)
|
||||
- Returns the current PSCI version on GET_ONE_REG (defaulting to the
|
||||
highest PSCI version implemented by KVM and compatible with v0.2)
|
||||
- Allows any PSCI version implemented by KVM and compatible with
|
||||
v0.2 to be set with SET_ONE_REG
|
||||
- Affects the whole VM (even if the register view is per-vcpu)
|
||||
|
||||
See ptp_kvm.rst
|
||||
* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1:
|
||||
Holds the state of the firmware support to mitigate CVE-2017-5715, as
|
||||
offered by KVM to the guest via a HVC call. The workaround is described
|
||||
under SMCCC_ARCH_WORKAROUND_1 in [1].
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO``
|
||||
----------------------------------
|
||||
Accepted values are:
|
||||
|
||||
Query the memory protection parameters for a protected virtual machine.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_AVAIL:
|
||||
KVM does not offer
|
||||
firmware support for the workaround. The mitigation status for the
|
||||
guest is unknown.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_AVAIL:
|
||||
The workaround HVC call is
|
||||
available to the guest and required for the mitigation.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_1_NOT_REQUIRED:
|
||||
The workaround HVC call
|
||||
is available to the guest, but it is not needed on this VCPU.
|
||||
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Presence: | Optional; protected guests only. |
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Calling convention: | HVC64 |
|
||||
+---------------------+----------+--------------------------------------------------+
|
||||
| Function ID: | (uint32) | 0xC6000002 |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Arguments: | (uint64) | R1 | Reserved / Must be zero |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R2 | Reserved / Must be zero |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R3 | Reserved / Must be zero |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Return Values: | (int64) | R0 | ``INVALID_PARAMETER (-3)`` on error, else |
|
||||
| | | | memory protection granule in bytes |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (int64) | R1 | ``KVM_FUNC_HAS_RANGE (1)`` if MEM_SHARE and |
|
||||
| | | | MEM_UNSHARE take a range argument. |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
* KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2:
|
||||
Holds the state of the firmware support to mitigate CVE-2018-3639, as
|
||||
offered by KVM to the guest via a HVC call. The workaround is described
|
||||
under SMCCC_ARCH_WORKAROUND_2 in [1]_.
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_MEM_SHARE``
|
||||
--------------------------------
|
||||
Accepted values are:
|
||||
|
||||
Share a region of memory with the KVM host, granting it read, write and execute
|
||||
permissions. The size of the region is equal to the memory protection granule
|
||||
advertised by ``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO`` times the number of granules
|
||||
set in R2. See the ``KVM_FUNC_HAS_RANGE`` paragraph for more details about this
|
||||
argument.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_AVAIL:
|
||||
A workaround is not
|
||||
available. KVM does not offer firmware support for the workaround.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_UNKNOWN:
|
||||
The workaround state is
|
||||
unknown. KVM does not offer firmware support for the workaround.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_AVAIL:
|
||||
The workaround is available,
|
||||
and can be disabled by a vCPU. If
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_ENABLED is set, it is active for
|
||||
this vCPU.
|
||||
KVM_REG_ARM_SMCCC_ARCH_WORKAROUND_2_NOT_REQUIRED:
|
||||
The workaround is always active on this vCPU or it is not needed.
|
||||
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Presence: | Optional; protected guests only. |
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Calling convention: | HVC64 |
|
||||
+---------------------+----------+--------------------------------------------------+
|
||||
| Function ID: | (uint32) | 0xC6000003 |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Arguments: | (uint64) | R1 | Base IPA of memory region to share |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R2 | Number of granules to share |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R3 | Reserved / Must be zero |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Return Values: | (int64) | R0 | ``SUCCESS (0)`` |
|
||||
| | | +---------------------------------------------+
|
||||
| | | | ``INVALID_PARAMETER (-3)`` |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R1 | Number of shared granules |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_MEM_UNSHARE``
|
||||
----------------------------------
|
||||
Bitmap Feature Firmware Registers
|
||||
---------------------------------
|
||||
|
||||
Revoke access permission from the KVM host to a memory region previously shared
|
||||
with ``ARM_SMCCC_KVM_FUNC_MEM_SHARE``. The size of the region is equal to the
|
||||
memory protection granule advertised by ``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO`` times
|
||||
the number of granules set in R2. See the ``KVM_FUNC_HAS_RANGE`` paragraph for
|
||||
more details about this argument.
|
||||
Contrary to the above registers, the following registers exposes the
|
||||
hypercall services in the form of a feature-bitmap to the userspace. This
|
||||
bitmap is translated to the services that are available to the guest.
|
||||
There is a register defined per service call owner and can be accessed via
|
||||
GET/SET_ONE_REG interface.
|
||||
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Presence: | Optional; protected guests only. |
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Calling convention: | HVC64 |
|
||||
+---------------------+----------+--------------------------------------------------+
|
||||
| Function ID: | (uint32) | 0xC6000004 |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Arguments: | (uint64) | R1 | Base IPA of memory region to unshare |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R2 | Number of granules to unshare |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R3 | Reserved / Must be zero |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Return Values: | (int64) | R0 | ``SUCCESS (0)`` |
|
||||
| | | +---------------------------------------------+
|
||||
| | | | ``INVALID_PARAMETER (-3)`` |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R1 | Number of unshared granules |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
By default, these registers are set with the upper limit of the features
|
||||
that are supported. This way userspace can discover all the usable
|
||||
hypercall services via GET_ONE_REG. The user-space can write-back the
|
||||
desired bitmap back via SET_ONE_REG. The features for the registers that
|
||||
are untouched, probably because userspace isn't aware of them, will be
|
||||
exposed as is to the guest.
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_MEM_RELINQUISH``
|
||||
--------------------------------------
|
||||
Note that KVM will not allow the userspace to configure the registers
|
||||
anymore once any of the vCPUs has run at least once. Instead, it will
|
||||
return a -EBUSY.
|
||||
|
||||
Cooperatively relinquish ownership of a memory region. The size of the
|
||||
region is equal to the memory protection granule advertised by
|
||||
``ARM_SMCCC_KVM_FUNC_HYP_MEMINFO``. If this hypercall is advertised
|
||||
then it is mandatory to call it before freeing memory via, for
|
||||
example, virtio balloon. If the caller is a protected VM, it is
|
||||
guaranteed that the memory region will be completely cleared before
|
||||
becoming visible to another VM.
|
||||
The pseudo-firmware bitmap register are as follows:
|
||||
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Presence: | Optional. |
|
||||
+---------------------+-------------------------------------------------------------+
|
||||
| Calling convention: | HVC64 |
|
||||
+---------------------+----------+--------------------------------------------------+
|
||||
| Function ID: | (uint32) | 0xC6000009 |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Arguments: | (uint64) | R1 | Base IPA of memory region to relinquish |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R2 | Reserved / Must be zero |
|
||||
| +----------+----+---------------------------------------------+
|
||||
| | (uint64) | R3 | Reserved / Must be zero |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
| Return Values: | (int64) | R0 | ``SUCCESS (0)`` |
|
||||
| | | +---------------------------------------------+
|
||||
| | | | ``INVALID_PARAMETER (-3)`` |
|
||||
+---------------------+----------+----+---------------------------------------------+
|
||||
* KVM_REG_ARM_STD_BMAP:
|
||||
Controls the bitmap of the ARM Standard Secure Service Calls.
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_MMIO_GUARD_*``
|
||||
-----------------------------------
|
||||
The following bits are accepted:
|
||||
|
||||
See mmio-guard.rst
|
||||
Bit-0: KVM_REG_ARM_STD_BIT_TRNG_V1_0:
|
||||
The bit represents the services offered under v1.0 of ARM True Random
|
||||
Number Generator (TRNG) specification, ARM DEN0098.
|
||||
|
||||
``KVM_FUNC_HAS_RANGE``
|
||||
----------------------
|
||||
* KVM_REG_ARM_STD_HYP_BMAP:
|
||||
Controls the bitmap of the ARM Standard Hypervisor Service Calls.
|
||||
|
||||
This flag, when set in ARM_SMCCC_KVM_FUNC_HYP_MEMINFO, indicates the guest can
|
||||
pass a number of granules as an argument to:
|
||||
The following bits are accepted:
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MEM_SHARE
|
||||
* ARM_SMCCC_KVM_FUNC_MEM_UNSHARE
|
||||
Bit-0: KVM_REG_ARM_STD_HYP_BIT_PV_TIME:
|
||||
The bit represents the Paravirtualized Time service as represented by
|
||||
ARM DEN0057A.
|
||||
|
||||
In order to support legacy guests, the kernel still accepts ``0`` as a value. In
|
||||
that case a single granule is shared/unshared.
|
||||
* KVM_REG_ARM_VENDOR_HYP_BMAP:
|
||||
Controls the bitmap of the Vendor specific Hypervisor Service Calls.
|
||||
|
||||
When set in ARM_SMCCC_KVM_FUNC_MMIO_GUARD_INFO, indicates the guest can call the
|
||||
HVCs:
|
||||
The following bits are accepted:
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_MAP
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_UNMAP
|
||||
Bit-0: KVM_REG_ARM_VENDOR_HYP_BIT_FUNC_FEAT
|
||||
The bit represents the ARM_SMCCC_VENDOR_HYP_KVM_FEATURES_FUNC_ID
|
||||
and ARM_SMCCC_VENDOR_HYP_CALL_UID_FUNC_ID function-ids.
|
||||
|
||||
For all those HVCs, the hypervisor is free to stop the process at any time
|
||||
either because the range isn't physically contiguous or to limit the time spent
|
||||
at EL2. In a such case, the number of actually shared granules is returned (R1)
|
||||
and the caller can start again where it stopped, that is, the base IPA + (Number
|
||||
of processed granules * protection granule size).
|
||||
Bit-1: KVM_REG_ARM_VENDOR_HYP_BIT_PTP:
|
||||
The bit represents the Precision Time Protocol KVM service.
|
||||
|
||||
If the number of processed granules returned is zero (R1), an error (R0) will be
|
||||
set.
|
||||
Errors:
|
||||
|
||||
======= =============================================================
|
||||
-ENOENT Unknown register accessed.
|
||||
-EBUSY Attempt a 'write' to the register after the VM has started.
|
||||
-EINVAL Invalid bitmap written to the register.
|
||||
======= =============================================================
|
||||
|
||||
.. [1] https://developer.arm.com/-/media/developer/pdf/ARM_DEN_0070A_Firmware_interfaces_for_mitigating_CVE-2017-5715.pdf
|
||||
|
|
|
|||
|
|
@ -7,10 +7,7 @@ ARM
|
|||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
fw-pseudo-registers
|
||||
hyp-abi
|
||||
hypercalls
|
||||
pkvm
|
||||
pvtime
|
||||
ptp_kvm
|
||||
mmio-guard
|
||||
|
|
|
|||
|
|
@ -1,114 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
==============
|
||||
KVM MMIO guard
|
||||
==============
|
||||
|
||||
KVM implements device emulation by handling translation faults to any
|
||||
IPA range that is not contained in a memory slot. Such a translation
|
||||
fault is in most cases passed on to userspace (or in rare cases to the
|
||||
host kernel) with the address, size and possibly data of the access
|
||||
for emulation.
|
||||
|
||||
Should the guest exit with an address that is not one that corresponds
|
||||
to an emulatable device, userspace may take measures that are not the
|
||||
most graceful as far as the guest is concerned (such as terminating it
|
||||
or delivering a fatal exception).
|
||||
|
||||
There is also an element of trust: by forwarding the request to
|
||||
userspace, the kernel assumes that the guest trusts userspace to do
|
||||
the right thing.
|
||||
|
||||
The KVM MMIO guard offers a way to mitigate this last point: a guest
|
||||
can request that only certain regions of the IPA space are valid as
|
||||
MMIO. Only these regions will be handled as an MMIO, and any other
|
||||
will result in an exception being delivered to the guest.
|
||||
|
||||
This relies on a set of hypercalls defined in the KVM-specific range,
|
||||
using the HVC64 calling convention.
|
||||
|
||||
When operating on a range of contiguous IPA space, it is recommended
|
||||
to use ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_MAP and
|
||||
ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_UNMAP. Those HVCs take a number of
|
||||
granules as an argument. See ``KVM_FUNC_HAS_RANGE`` in hypercalls.rst
|
||||
for a complete description.
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_GUARD_INFO
|
||||
|
||||
============== ======== ================================
|
||||
Function ID: (uint32) 0xC6000005
|
||||
Arguments: r1-r3 Reserved / Must be zero
|
||||
Return Values: (int64) NOT_SUPPORTED(-1) on error, or
|
||||
(uint64) Protection Granule (PG) size in
|
||||
bytes (r0). KVM_FUNC_HAS_RANGE(1)
|
||||
is set (r1) if RGUARD_MAP and
|
||||
RGUARD_UNMAP HVCs are available.
|
||||
============== ======== ================================
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_GUARD_ENROLL
|
||||
|
||||
============== ======== ==============================
|
||||
Function ID: (uint32) 0xC6000006
|
||||
Arguments: none
|
||||
Return Values: (int64) NOT_SUPPORTED(-1) on error, or
|
||||
RET_SUCCESS(0) (r0)
|
||||
============== ======== ==============================
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_GUARD_MAP
|
||||
|
||||
============== ======== ====================================
|
||||
Function ID: (uint32) 0xC6000007
|
||||
Arguments: (uint64) The base of the PG-sized IPA range
|
||||
that is allowed to be accessed as
|
||||
MMIO. Must be aligned to the PG size
|
||||
(r1)
|
||||
(uint64) Index in the MAIR_EL1 register
|
||||
providing the memory attribute that
|
||||
is used by the guest (r2)
|
||||
Return Values: (int64) NOT_SUPPORTED(-1) on error, or
|
||||
RET_SUCCESS(0) (r0)
|
||||
============== ======== ====================================
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_GUARD_UNMAP
|
||||
|
||||
============== ======== ======================================
|
||||
Function ID: (uint32) 0xC6000008
|
||||
Arguments: (uint64) PG-sized IPA range aligned to the PG
|
||||
size which has been previously mapped.
|
||||
Must be aligned to the PG size and
|
||||
have been previously mapped (r1)
|
||||
Return Values: (int64) NOT_SUPPORTED(-1) on error, or
|
||||
RET_SUCCESS(0) (r0)
|
||||
============== ======== ======================================
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_MAP
|
||||
|
||||
============== ======== ====================================
|
||||
Function ID: (uint32) 0xC600000A
|
||||
Arguments: (uint64) The base of the PG-sized IPA range
|
||||
that is allowed to be accessed as
|
||||
MMIO. Must be aligned to the PG size
|
||||
(r1)
|
||||
(uint64) Number of granules to guard (r2). See
|
||||
``KVM_FUNC_HAS_RANGE`` in
|
||||
hypercalls.rst for more details
|
||||
Return Values: (int64) NOT_SUPPORTED(-1) on error, or
|
||||
RET_SUCCESS(0) (r0)
|
||||
(uint64) Number of shared granules (r1)
|
||||
============== ======== ====================================
|
||||
|
||||
* ARM_SMCCC_KVM_FUNC_MMIO_RGUARD_UNMAP
|
||||
|
||||
============== ======== ======================================
|
||||
Function ID: (uint32) 0xC600000B
|
||||
Arguments: (uint64) PG-sized IPA range aligned to the PG
|
||||
size which has been previously mapped.
|
||||
Must be aligned to the PG size and
|
||||
have been previously mapped (r1)
|
||||
(uint64) Number of granules to unguard (r2). See
|
||||
``KVM_FUNC_HAS_RANGE`` in
|
||||
hypercalls.rst for more details
|
||||
Return Values: (int64) NOT_SUPPORTED(-1) on error, or
|
||||
RET_SUCCESS(0) (r0)
|
||||
(uint64) Number of shared granules (r1)
|
||||
============== ======== ======================================
|
||||
|
|
@ -1,96 +0,0 @@
|
|||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Protected virtual machines (pKVM)
|
||||
=================================
|
||||
|
||||
Introduction
|
||||
------------
|
||||
|
||||
Protected KVM (pKVM) is a KVM/arm64 extension which uses the two-stage
|
||||
translation capability of the Armv8 MMU to isolate guest memory from the host
|
||||
system. This allows for the creation of a confidential computing environment
|
||||
without relying on whizz-bang features in hardware, but still allowing room for
|
||||
complementary technologies such as memory encryption and hardware-backed
|
||||
attestation.
|
||||
|
||||
The major implementation change brought about by pKVM is that the hypervisor
|
||||
code running at EL2 is now largely independent of (and isolated from) the rest
|
||||
of the host kernel running at EL1 and therefore additional hypercalls are
|
||||
introduced to manage manipulation of guest stage-2 page tables, creation of VM
|
||||
data structures and reclamation of memory on teardown. An immediate consequence
|
||||
of this change is that the host itself runs with an identity mapping enabled
|
||||
at stage-2, providing the hypervisor code with a mechanism to restrict host
|
||||
access to an arbitrary physical page.
|
||||
|
||||
Enabling pKVM
|
||||
-------------
|
||||
|
||||
The pKVM hypervisor is enabled by booting the host kernel at EL2 with
|
||||
"``kvm-arm.mode=protected``" on the command-line. Once enabled, VMs can be spawned
|
||||
in either protected or non-protected state, although the hypervisor is still
|
||||
responsible for managing most of the VM metadata in either case.
|
||||
|
||||
Limitations
|
||||
-----------
|
||||
|
||||
Enabling pKVM places some significant limitations on KVM guests, regardless of
|
||||
whether they are spawned in protected state. It is therefore recommended only
|
||||
to enable pKVM if protected VMs are required, with non-protected state acting
|
||||
primarily as a debug and development aid.
|
||||
|
||||
If you're still keen, then here is an incomplete list of caveats that apply
|
||||
to all VMs running under pKVM:
|
||||
|
||||
- Guest memory cannot be file-backed (with the exception of shmem/memfd) and is
|
||||
pinned as it is mapped into the guest. This prevents the host from
|
||||
swapping-out, migrating, merging or generally doing anything useful with the
|
||||
guest pages. It also requires that the VMM has either ``CAP_IPC_LOCK`` or
|
||||
sufficient ``RLIMIT_MEMLOCK`` to account for this pinned memory.
|
||||
|
||||
- GICv2 is not supported and therefore GICv3 hardware is required in order
|
||||
to expose a virtual GICv3 to the guest.
|
||||
|
||||
- Read-only memslots are unsupported and therefore dirty logging cannot be
|
||||
enabled.
|
||||
|
||||
- Memslot configuration is fixed once a VM has started running, with subsequent
|
||||
move or deletion requests being rejected with ``-EPERM``.
|
||||
|
||||
- There are probably many others.
|
||||
|
||||
Since the host is unable to tear down the hypervisor when pKVM is enabled,
|
||||
hibernation (``CONFIG_HIBERNATION``) and kexec (``CONFIG_KEXEC``) will fail
|
||||
with ``-EBUSY``.
|
||||
|
||||
If you are not happy with these limitations, then please don't enable pKVM :)
|
||||
|
||||
VM creation
|
||||
-----------
|
||||
|
||||
When pKVM is enabled, protected VMs can be created by specifying the
|
||||
``KVM_VM_TYPE_ARM_PROTECTED`` flag in the machine type identifier parameter
|
||||
passed to ``KVM_CREATE_VM``.
|
||||
|
||||
Protected VMs are instantiated according to a fixed vCPU configuration
|
||||
described by the ID register definitions in
|
||||
``arch/arm64/include/asm/kvm_pkvm.h``. Only a subset of the architectural
|
||||
features that may be available to the host are exposed to the guest and the
|
||||
capabilities advertised by ``KVM_CHECK_EXTENSION`` are limited accordingly,
|
||||
with the vCPU registers being initialised to their architecturally-defined
|
||||
values.
|
||||
|
||||
Where not defined by the architecture, the registers of a protected vCPU
|
||||
are reset to zero with the exception of the PC and X0 which can be set
|
||||
either by the ``KVM_SET_ONE_REG`` interface or by a call to PSCI ``CPU_ON``.
|
||||
|
||||
VM runtime
|
||||
----------
|
||||
|
||||
By default, memory pages mapped into a protected guest are inaccessible to the
|
||||
host and any attempt by the host to access such a page will result in the
|
||||
injection of an abort at EL1 by the hypervisor. For accesses originating from
|
||||
EL0, the host will then terminate the current task with a ``SIGSEGV``.
|
||||
|
||||
pKVM exposes additional hypercalls to protected guests, primarily for the
|
||||
purpose of establishing shared-memory regions with the host for communication
|
||||
and I/O. These hypercalls are documented in hypercalls.rst.
|
||||
|
|
@ -7,29 +7,19 @@ PTP_KVM is used for high precision time sync between host and guests.
|
|||
It relies on transferring the wall clock and counter value from the
|
||||
host to the guest using a KVM-specific hypercall.
|
||||
|
||||
``ARM_SMCCC_KVM_FUNC_PTP``
|
||||
----------------------------------------
|
||||
* ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID: 0x86000001
|
||||
|
||||
Retrieve current time information for the specific counter. There are no
|
||||
endianness restrictions.
|
||||
This hypercall uses the SMC32/HVC32 calling convention:
|
||||
|
||||
+---------------------+-------------------------------------------------------+
|
||||
| Presence: | Optional |
|
||||
+---------------------+-------------------------------------------------------+
|
||||
| Calling convention: | HVC32 |
|
||||
+---------------------+----------+--------------------------------------------+
|
||||
| Function ID: | (uint32) | 0x86000001 |
|
||||
+---------------------+----------+----+---------------------------------------+
|
||||
| Arguments: | (uint32) | R1 | ``KVM_PTP_VIRT_COUNTER (0)`` |
|
||||
| | | +---------------------------------------+
|
||||
| | | | ``KVM_PTP_PHYS_COUNTER (1)`` |
|
||||
+---------------------+----------+----+---------------------------------------+
|
||||
| Return Values: | (int32) | R0 | ``NOT_SUPPORTED (-1)`` on error, else |
|
||||
| | | | upper 32 bits of wall clock time |
|
||||
| +----------+----+---------------------------------------+
|
||||
| | (uint32) | R1 | Lower 32 bits of wall clock time |
|
||||
| +----------+----+---------------------------------------+
|
||||
| | (uint32) | R2 | Upper 32 bits of counter |
|
||||
| +----------+----+---------------------------------------+
|
||||
| | (uint32) | R3 | Lower 32 bits of counter |
|
||||
+---------------------+----------+----+---------------------------------------+
|
||||
ARM_SMCCC_VENDOR_HYP_KVM_PTP_FUNC_ID
|
||||
============== ======== =====================================
|
||||
Function ID: (uint32) 0x86000001
|
||||
Arguments: (uint32) KVM_PTP_VIRT_COUNTER(0)
|
||||
KVM_PTP_PHYS_COUNTER(1)
|
||||
Return Values: (int32) NOT_SUPPORTED(-1) on error, or
|
||||
(uint32) Upper 32 bits of wall clock time (r0)
|
||||
(uint32) Lower 32 bits of wall clock time (r1)
|
||||
(uint32) Upper 32 bits of counter (r2)
|
||||
(uint32) Lower 32 bits of counter (r3)
|
||||
Endianness: No Restrictions.
|
||||
============== ======== =====================================
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ KVM Lock Overview
|
|||
|
||||
The acquisition orders for mutexes are as follows:
|
||||
|
||||
- cpus_read_lock() is taken outside kvm_lock and kvm_usage_lock
|
||||
- cpus_read_lock() is taken outside kvm_lock
|
||||
|
||||
- kvm->lock is taken outside vcpu->mutex
|
||||
|
||||
|
|
@ -24,13 +24,6 @@ The acquisition orders for mutexes are as follows:
|
|||
are taken on the waiting side when modifying memslots, so MMU notifiers
|
||||
must not take either kvm->slots_lock or kvm->slots_arch_lock.
|
||||
|
||||
cpus_read_lock() vs kvm_lock:
|
||||
|
||||
- Taking cpus_read_lock() outside of kvm_lock is problematic, despite that
|
||||
being the official ordering, as it is quite easy to unknowingly trigger
|
||||
cpus_read_lock() while holding kvm_lock. Use caution when walking vm_list,
|
||||
e.g. avoid complex operations when possible.
|
||||
|
||||
For SRCU:
|
||||
|
||||
- ``synchronize_srcu(&kvm->srcu)`` is called inside critical sections
|
||||
|
|
@ -235,17 +228,10 @@ time it will be set using the Dirty tracking mechanism described above.
|
|||
:Type: mutex
|
||||
:Arch: any
|
||||
:Protects: - vm_list
|
||||
|
||||
``kvm_usage_lock``
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
|
||||
:Type: mutex
|
||||
:Arch: any
|
||||
:Protects: - kvm_usage_count
|
||||
- kvm_usage_count
|
||||
- hardware virtualization enable/disable
|
||||
:Comment: Exists because using kvm_lock leads to deadlock (see earlier comment
|
||||
on cpus_read_lock() vs kvm_lock). Note, KVM also disables CPU hotplug via
|
||||
cpus_read_lock() when enabling/disabling virtualization.
|
||||
:Comment: KVM also disables CPU hotplug via cpus_read_lock() during
|
||||
enable/disable.
|
||||
|
||||
``kvm->mn_invalidate_lock``
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
|
@ -305,12 +291,11 @@ time it will be set using the Dirty tracking mechanism described above.
|
|||
wakeup.
|
||||
|
||||
``vendor_module_lock``
|
||||
^^^^^^^^^^^^^^^^^^^^^^
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
:Type: mutex
|
||||
:Arch: x86
|
||||
:Protects: loading a vendor module (kvm_amd or kvm_intel)
|
||||
:Comment: Exists because using kvm_lock leads to deadlock. kvm_lock is taken
|
||||
in notifiers, e.g. __kvmclock_cpufreq_notifier(), that may be invoked while
|
||||
cpu_hotplug_lock is held, e.g. from cpufreq_boost_trigger_state(), and many
|
||||
operations need to take cpu_hotplug_lock when loading a vendor module, e.g.
|
||||
updating static calls.
|
||||
:Comment: Exists because using kvm_lock leads to deadlock. cpu_hotplug_lock is
|
||||
taken outside of kvm_lock, e.g. in KVM's CPU online/offline callbacks, and
|
||||
many operations need to take cpu_hotplug_lock when loading a vendor module,
|
||||
e.g. updating static calls.
|
||||
|
|
|
|||
3
Kconfig
3
Kconfig
|
|
@ -30,6 +30,3 @@ source "lib/Kconfig"
|
|||
source "lib/Kconfig.debug"
|
||||
|
||||
source "Documentation/Kconfig"
|
||||
|
||||
# ANDROID: Set KCONFIG_EXT_PREFIX to decend into an external project.
|
||||
source "$(KCONFIG_EXT_PREFIX)Kconfig.ext"
|
||||
|
|
|
|||
|
|
@ -1,3 +0,0 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
# This file is intentionally empty. It's used as a placeholder for when
|
||||
# KCONFIG_EXT_PREFIX isn't defined.
|
||||
44
MAINTAINERS
44
MAINTAINERS
|
|
@ -5053,13 +5053,6 @@ F: scripts/Makefile.clang
|
|||
F: scripts/clang-tools/
|
||||
K: \b(?i:clang|llvm)\b
|
||||
|
||||
CLEANCACHE API
|
||||
M: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
|
||||
L: linux-kernel@vger.kernel.org
|
||||
S: Maintained
|
||||
F: include/linux/cleancache.h
|
||||
F: mm/cleancache.c
|
||||
|
||||
CLK API
|
||||
M: Russell King <linux@armlinux.org.uk>
|
||||
L: linux-clk@vger.kernel.org
|
||||
|
|
@ -8801,17 +8794,6 @@ F: include/vdso/
|
|||
F: kernel/time/vsyscall.c
|
||||
F: lib/vdso/
|
||||
|
||||
GENIEZONE HYPERVISOR DRIVER
|
||||
M: Yingshiuan Pan <yingshiuan.pan@mediatek.com>
|
||||
M: Ze-Yu Wang <ze-yu.wang@mediatek.com>
|
||||
M: Liju Chen <liju-clr.chen@mediatek.com>
|
||||
F: Documentation/devicetree/bindings/firmware/mediatek,geniezone.yaml
|
||||
F: Documentation/virt/geniezone/
|
||||
F: arch/arm64/geniezone/
|
||||
F: drivers/virt/geniezone/
|
||||
F: include/linux/soc/mediatek/gzvm_drv.h
|
||||
F: include/uapi/linux/gzvm.h
|
||||
|
||||
GENWQE (IBM Generic Workqueue Card)
|
||||
M: Frank Haverkamp <haver@linux.ibm.com>
|
||||
S: Supported
|
||||
|
|
@ -9101,18 +9083,6 @@ L: linux-efi@vger.kernel.org
|
|||
S: Maintained
|
||||
F: block/partitions/efi.*
|
||||
|
||||
GUNYAH HYPERVISOR DRIVER
|
||||
M: Elliot Berman <quic_eberman@quicinc.com>
|
||||
M: Prakruthi Deepak Heragu <quic_pheragu@quicinc.com>
|
||||
L: linux-arm-msm@vger.kernel.org
|
||||
S: Supported
|
||||
F: Documentation/devicetree/bindings/firmware/gunyah-hypervisor.yaml
|
||||
F: Documentation/virt/gunyah/
|
||||
F: arch/arm64/gunyah/
|
||||
F: drivers/virt/gunyah/
|
||||
F: include/linux/gunyah*.h
|
||||
K: gunyah
|
||||
|
||||
HABANALABS PCI DRIVER
|
||||
M: Oded Gabbay <ogabbay@kernel.org>
|
||||
L: dri-devel@lists.freedesktop.org
|
||||
|
|
@ -10313,13 +10283,6 @@ F: Documentation/hwmon/ina2xx.rst
|
|||
F: drivers/hwmon/ina2xx.c
|
||||
F: include/linux/platform_data/ina2xx.h
|
||||
|
||||
INCREMENTAL FILE SYSTEM
|
||||
M: Paul Lawrence <paullawrence@google.com>
|
||||
L: linux-unionfs@vger.kernel.org
|
||||
S: Supported
|
||||
F: fs/incfs/
|
||||
F: tools/testing/selftests/filesystems/incfs/
|
||||
|
||||
INDEX OF FURTHER KERNEL DOCUMENTATION
|
||||
M: Carlos Bilbao <carlos.bilbao@amd.com>
|
||||
S: Maintained
|
||||
|
|
@ -20984,6 +20947,13 @@ F: include/linux/sc[mp]i_protocol.h
|
|||
F: include/trace/events/scmi.h
|
||||
F: include/uapi/linux/virtio_scmi.h
|
||||
|
||||
PINCTRL DRIVER FOR SYSTEM CONTROL MANAGEMENT INTERFACE (SCMI)
|
||||
M: Oleksii Moisieiev <oleksii_moisieiev@epam.com>
|
||||
L: linux-arm-kernel@lists.infradead.org
|
||||
S: Maintained
|
||||
F: drivers/firmware/arm_scmi/pinctrl.c
|
||||
F: drivers/pinctrl/pinctrl-scmi.c
|
||||
|
||||
SYSTEM RESET/SHUTDOWN DRIVERS
|
||||
M: Sebastian Reichel <sre@kernel.org>
|
||||
L: linux-pm@vger.kernel.org
|
||||
|
|
|
|||
119
Makefile
119
Makefile
|
|
@ -1,9 +1,9 @@
|
|||
# SPDX-License-Identifier: GPL-2.0
|
||||
VERSION = 6
|
||||
PATCHLEVEL = 6
|
||||
SUBLEVEL = 58
|
||||
SUBLEVEL = 52
|
||||
EXTRAVERSION =
|
||||
NAME = Pinguïn Aangedreven
|
||||
NAME = Hurr durr I'ma ninja sloth
|
||||
|
||||
# *DOCUMENTATION*
|
||||
# To see a list of typical targets execute "make help"
|
||||
|
|
@ -155,24 +155,6 @@ endif
|
|||
|
||||
export KBUILD_EXTMOD
|
||||
|
||||
# ANDROID: set up mixed-build support. mixed-build allows device kernel modules
|
||||
# to be compiled against a GKI kernel. This approach still uses the headers and
|
||||
# Kbuild from device kernel, so care must be taken to ensure that those headers match.
|
||||
ifdef KBUILD_MIXED_TREE
|
||||
# Need vmlinux.symvers for modpost and System.map for depmod, check whether they exist in KBUILD_MIXED_TREE
|
||||
required_mixed_files=vmlinux.symvers System.map
|
||||
$(if $(filter-out $(words $(required_mixed_files)), \
|
||||
$(words $(wildcard $(add-prefix $(KBUILD_MIXED_TREE)/,$(required_mixed_files))))),,\
|
||||
$(error KBUILD_MIXED_TREE=$(KBUILD_MIXED_TREE) doesn't contain $(required_mixed_files)))
|
||||
endif
|
||||
|
||||
mixed-build-prefix = $(if $(KBUILD_MIXED_TREE),$(KBUILD_MIXED_TREE)/)
|
||||
export KBUILD_MIXED_TREE
|
||||
# This is a hack for kleaf to set mixed-build-prefix within the execution of a make rule, e.g.
|
||||
# within __modinst_pre.
|
||||
# TODO(b/205893923): Revert this hack once it is properly handled.
|
||||
export mixed-build-prefix
|
||||
|
||||
# Kbuild will save output files in the current working directory.
|
||||
# This does not need to match to the root of the kernel source tree.
|
||||
#
|
||||
|
|
@ -536,7 +518,7 @@ KGZIP = gzip
|
|||
KBZIP2 = bzip2
|
||||
KLZOP = lzop
|
||||
LZMA = lzma
|
||||
LZ4 = lz4
|
||||
LZ4 = lz4c
|
||||
XZ = xz
|
||||
ZSTD = zstd
|
||||
|
||||
|
|
@ -766,13 +748,11 @@ drivers-y :=
|
|||
libs-y := lib/
|
||||
endif # KBUILD_EXTMOD
|
||||
|
||||
ifndef KBUILD_MIXED_TREE
|
||||
# The all: target is the default when no target is given on the
|
||||
# command line.
|
||||
# This allow a user to issue only 'make' to build a kernel including modules
|
||||
# Defaults to vmlinux, but the arch makefile usually adds further targets
|
||||
all: vmlinux
|
||||
endif
|
||||
|
||||
CFLAGS_GCOV := -fprofile-arcs -ftest-coverage
|
||||
ifdef CONFIG_CC_IS_GCC
|
||||
|
|
@ -974,13 +954,7 @@ CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
|
|||
else
|
||||
CC_FLAGS_LTO := -flto
|
||||
endif
|
||||
|
||||
ifeq ($(SRCARCH),x86)
|
||||
# Workaround for compiler / linker bug
|
||||
CC_FLAGS_LTO += -fvisibility=hidden
|
||||
else
|
||||
CC_FLAGS_LTO += -fvisibility=default
|
||||
endif
|
||||
|
||||
# Limit inlining across translation units to reduce binary size
|
||||
KBUILD_LDFLAGS += -mllvm -import-instr-limit=5
|
||||
|
|
@ -1001,11 +975,8 @@ export CC_FLAGS_LTO
|
|||
endif
|
||||
|
||||
ifdef CONFIG_CFI_CLANG
|
||||
CC_FLAGS_CFI := -fsanitize=kcfi
|
||||
ifdef CONFIG_RUST
|
||||
$(error "Enabling Rust and CFI silently changes the KMI.")
|
||||
endif
|
||||
KBUILD_CFLAGS += $(CC_FLAGS_CFI)
|
||||
CC_FLAGS_CFI := -fsanitize=kcfi
|
||||
KBUILD_CFLAGS += $(CC_FLAGS_CFI)
|
||||
export CC_FLAGS_CFI
|
||||
endif
|
||||
|
||||
|
|
@ -1129,40 +1100,6 @@ export extmod_prefix = $(if $(KBUILD_EXTMOD),$(KBUILD_EXTMOD)/)
|
|||
export MODORDER := $(extmod_prefix)modules.order
|
||||
export MODULES_NSDEPS := $(extmod_prefix)modules.nsdeps
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Kernel headers
|
||||
|
||||
PHONY += headers
|
||||
|
||||
#Default location for installed headers
|
||||
ifeq ($(KBUILD_EXTMOD),)
|
||||
PHONY += archheaders archscripts
|
||||
hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
|
||||
headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
|
||||
else
|
||||
hdr-prefix = $(KBUILD_EXTMOD)/
|
||||
hdr-inst := -f $(srctree)/scripts/Makefile.headersinst dst=$(KBUILD_EXTMOD)/usr/include objtree=$(objtree)/$(KBUILD_EXTMOD) obj
|
||||
endif
|
||||
|
||||
export INSTALL_HDR_PATH = $(objtree)/$(hdr-prefix)usr
|
||||
|
||||
quiet_cmd_headers_install = INSTALL $(INSTALL_HDR_PATH)/include
|
||||
cmd_headers_install = \
|
||||
mkdir -p $(INSTALL_HDR_PATH); \
|
||||
rsync -mrl --include='*/' --include='*\.h' --exclude='*' \
|
||||
$(hdr-prefix)usr/include $(INSTALL_HDR_PATH);
|
||||
|
||||
PHONY += headers_install
|
||||
headers_install: headers
|
||||
$(call cmd,headers_install)
|
||||
|
||||
headers:
|
||||
ifeq ($(KBUILD_EXTMOD),)
|
||||
$(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
|
||||
endif
|
||||
$(Q)$(MAKE) $(hdr-inst)=$(hdr-prefix)include/uapi
|
||||
$(Q)$(MAKE) $(hdr-inst)=$(hdr-prefix)arch/$(SRCARCH)/include/uapi
|
||||
|
||||
ifeq ($(KBUILD_EXTMOD),)
|
||||
|
||||
build-dir := .
|
||||
|
|
@ -1203,7 +1140,6 @@ targets += vmlinux.a
|
|||
vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
|
||||
$(call if_changed,ar_vmlinux.a)
|
||||
|
||||
ifndef KBUILD_MIXED_TREE
|
||||
PHONY += vmlinux_o
|
||||
vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS)
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux_o
|
||||
|
|
@ -1226,7 +1162,6 @@ vmlinux: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
|
|||
vmlinux: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
|
||||
vmlinux: vmlinux.o $(KBUILD_LDS) modpost
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux
|
||||
endif
|
||||
|
||||
# The actual objects are generated when descending,
|
||||
# make sure no implicit rule kicks in
|
||||
|
|
@ -1336,6 +1271,32 @@ headerdep:
|
|||
$(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 \
|
||||
$(srctree)/scripts/headerdep.pl -I$(srctree)/include
|
||||
|
||||
# ---------------------------------------------------------------------------
|
||||
# Kernel headers
|
||||
|
||||
#Default location for installed headers
|
||||
export INSTALL_HDR_PATH = $(objtree)/usr
|
||||
|
||||
quiet_cmd_headers_install = INSTALL $(INSTALL_HDR_PATH)/include
|
||||
cmd_headers_install = \
|
||||
mkdir -p $(INSTALL_HDR_PATH); \
|
||||
rsync -mrl --include='*/' --include='*\.h' --exclude='*' \
|
||||
usr/include $(INSTALL_HDR_PATH)
|
||||
|
||||
PHONY += headers_install
|
||||
headers_install: headers
|
||||
$(call cmd,headers_install)
|
||||
|
||||
PHONY += archheaders archscripts
|
||||
|
||||
hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
|
||||
|
||||
PHONY += headers
|
||||
headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
|
||||
$(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
|
||||
$(Q)$(MAKE) $(hdr-inst)=include/uapi
|
||||
$(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi
|
||||
|
||||
ifdef CONFIG_HEADERS_INSTALL
|
||||
prepare: headers
|
||||
endif
|
||||
|
|
@ -1421,9 +1382,7 @@ kselftest-merge:
|
|||
# Devicetree files
|
||||
|
||||
ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
|
||||
# ANDROID: allow this to be overridden by the build environment. This allows
|
||||
# one to compile a device tree that is located out-of-tree.
|
||||
dtstree ?= arch/$(SRCARCH)/boot/dts
|
||||
dtstree := arch/$(SRCARCH)/boot/dts
|
||||
endif
|
||||
|
||||
ifneq ($(dtstree),)
|
||||
|
|
@ -1501,7 +1460,7 @@ endif
|
|||
# is an exception.
|
||||
ifdef CONFIG_DEBUG_INFO_BTF_MODULES
|
||||
KBUILD_BUILTIN := 1
|
||||
modules: $(mixed-build-prefix)vmlinux
|
||||
modules: vmlinux
|
||||
endif
|
||||
|
||||
modules: modules_prepare
|
||||
|
|
@ -1845,8 +1804,6 @@ help:
|
|||
@echo ''
|
||||
@echo ' modules - default target, build the module(s)'
|
||||
@echo ' modules_install - install the module'
|
||||
@echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'
|
||||
@echo ' (default: $(abspath $(INSTALL_HDR_PATH)))'
|
||||
@echo ' clean - remove generated files in module directory only'
|
||||
@echo ' rust-analyzer - generate rust-project.json rust-analyzer support file'
|
||||
@echo ''
|
||||
|
|
@ -1911,7 +1868,7 @@ KBUILD_MODULES :=
|
|||
endif # CONFIG_MODULES
|
||||
|
||||
PHONY += modpost
|
||||
modpost: $(if $(single-build),, $(if $(KBUILD_MIXED_TREE),,$(if $(KBUILD_BUILTIN), vmlinux.o))) \
|
||||
modpost: $(if $(single-build),, $(if $(KBUILD_BUILTIN), vmlinux.o)) \
|
||||
$(if $(KBUILD_MODULES), modules_check)
|
||||
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
||||
|
||||
|
|
@ -1961,7 +1918,7 @@ endif
|
|||
# Error messages still appears in the original language
|
||||
PHONY += $(build-dir)
|
||||
$(build-dir): prepare
|
||||
$(Q)$(MAKE) $(build)=$@ $(if $(KBUILD_MIXED_TREE),,need-builtin=1) need-modorder=1 $(single-goals)
|
||||
$(Q)$(MAKE) $(build)=$@ need-builtin=1 need-modorder=1 $(single-goals)
|
||||
|
||||
clean-dirs := $(addprefix _clean_, $(clean-dirs))
|
||||
PHONY += $(clean-dirs) clean
|
||||
|
|
@ -1970,9 +1927,7 @@ $(clean-dirs):
|
|||
|
||||
clean: $(clean-dirs)
|
||||
$(call cmd,rmfiles)
|
||||
@find $(or $(KBUILD_EXTMOD), .) \
|
||||
$(if $(filter-out arch/$(SRCARCH)/boot/dts, $(dtstree)), $(dtstree)) \
|
||||
$(RCS_FIND_IGNORE) \
|
||||
@find $(or $(KBUILD_EXTMOD), .) $(RCS_FIND_IGNORE) \
|
||||
\( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
|
||||
-o -name '*.ko.*' \
|
||||
-o -name '*.dtb' -o -name '*.dtbo' \
|
||||
|
|
@ -2019,7 +1974,7 @@ quiet_cmd_gen_compile_commands = GEN $@
|
|||
cmd_gen_compile_commands = $(PYTHON3) $< -a $(AR) -o $@ $(filter-out $<, $(real-prereqs))
|
||||
|
||||
$(extmod_prefix)compile_commands.json: scripts/clang-tools/gen_compile_commands.py \
|
||||
$(if $(KBUILD_EXTMOD)$(KBUILD_MIXED_TREE),, vmlinux.a $(KBUILD_VMLINUX_LIBS)) \
|
||||
$(if $(KBUILD_EXTMOD),, vmlinux.a $(KBUILD_VMLINUX_LIBS)) \
|
||||
$(if $(CONFIG_MODULES), $(MODORDER)) FORCE
|
||||
$(call if_changed,gen_compile_commands)
|
||||
|
||||
|
|
|
|||
12
OWNERS
12
OWNERS
|
|
@ -1,12 +0,0 @@
|
|||
set noparent
|
||||
|
||||
# GKI Dr. No Enforcement is active on this branch. Approval of one of the Dr.
|
||||
# No reviewers is required following a regular CodeReview+2 vote of a code
|
||||
# reviewer.
|
||||
#
|
||||
# See the GKI release documentation (go/gki-dr-no) for further details.
|
||||
#
|
||||
# The expanded list of reviewers can be found at:
|
||||
# https://android.googlesource.com/kernel/common/+/android-mainline/OWNERS_DrNo
|
||||
|
||||
include kernel/common:android-mainline:/OWNERS_DrNo
|
||||
|
|
@ -1,7 +0,0 @@
|
|||
[Builtin Hooks]
|
||||
checkpatch = true
|
||||
commit_msg_bug_field = true
|
||||
commit_msg_changeid_field = true
|
||||
|
||||
[Builtin Hooks Options]
|
||||
checkpatch = --ignore=FILE_PATH_CHANGES,GERRIT_CHANGE_ID
|
||||
150
README.md
150
README.md
|
|
@ -1,150 +0,0 @@
|
|||
# How do I submit patches to Android Common Kernels
|
||||
|
||||
1. BEST: Make all of your changes to upstream Linux. If appropriate, backport to the stable releases.
|
||||
These patches will be merged automatically in the corresponding common kernels. If the patch is already
|
||||
in upstream Linux, post a backport of the patch that conforms to the patch requirements below.
|
||||
- Do not send patches upstream that contain only symbol exports. To be considered for upstream Linux,
|
||||
additions of `EXPORT_SYMBOL_GPL()` require an in-tree modular driver that uses the symbol -- so include
|
||||
the new driver or changes to an existing driver in the same patchset as the export.
|
||||
- When sending patches upstream, the commit message must contain a clear case for why the patch
|
||||
is needed and beneficial to the community. Enabling out-of-tree drivers or functionality is not
|
||||
a persuasive case.
|
||||
|
||||
2. LESS GOOD: Develop your patches out-of-tree (from an upstream Linux point-of-view). Unless these are
|
||||
fixing an Android-specific bug, these are very unlikely to be accepted unless they have been
|
||||
coordinated with kernel-team@android.com. If you want to proceed, post a patch that conforms to the
|
||||
patch requirements below.
|
||||
|
||||
# Common Kernel patch requirements
|
||||
|
||||
- All patches must conform to the Linux kernel coding standards and pass `scripts/checkpatch.pl`
|
||||
- Patches shall not break gki_defconfig or allmodconfig builds for arm, arm64, x86, x86_64 architectures
|
||||
(see https://source.android.com/setup/build/building-kernels)
|
||||
- If the patch is not merged from an upstream branch, the subject must be tagged with the type of patch:
|
||||
`UPSTREAM:`, `BACKPORT:`, `FROMGIT:`, `FROMLIST:`, or `ANDROID:`.
|
||||
- All patches must have a `Change-Id:` tag (see https://gerrit-review.googlesource.com/Documentation/user-changeid.html)
|
||||
- If an Android bug has been assigned, there must be a `Bug:` tag.
|
||||
- All patches must have a `Signed-off-by:` tag by the author and the submitter
|
||||
|
||||
Additional requirements are listed below based on patch type
|
||||
|
||||
## Requirements for backports from mainline Linux: `UPSTREAM:`, `BACKPORT:`
|
||||
|
||||
- If the patch is a cherry-pick from Linux mainline with no changes at all
|
||||
- tag the patch subject with `UPSTREAM:`.
|
||||
- add upstream commit information with a `(cherry picked from commit ...)` line
|
||||
- Example:
|
||||
- if the upstream commit message is
|
||||
```
|
||||
important patch from upstream
|
||||
|
||||
This is the detailed description of the important patch
|
||||
|
||||
Signed-off-by: Fred Jones <fred.jones@foo.org>
|
||||
```
|
||||
>- then Joe Smith would upload the patch for the common kernel as
|
||||
```
|
||||
UPSTREAM: important patch from upstream
|
||||
|
||||
This is the detailed description of the important patch
|
||||
|
||||
Signed-off-by: Fred Jones <fred.jones@foo.org>
|
||||
|
||||
Bug: 135791357
|
||||
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
|
||||
(cherry picked from commit c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
|
||||
Signed-off-by: Joe Smith <joe.smith@foo.org>
|
||||
```
|
||||
|
||||
- If the patch requires any changes from the upstream version, tag the patch with `BACKPORT:`
|
||||
instead of `UPSTREAM:`.
|
||||
- use the same tags as `UPSTREAM:`
|
||||
- add comments about the changes under the `(cherry picked from commit ...)` line
|
||||
- Example:
|
||||
```
|
||||
BACKPORT: important patch from upstream
|
||||
|
||||
This is the detailed description of the important patch
|
||||
|
||||
Signed-off-by: Fred Jones <fred.jones@foo.org>
|
||||
|
||||
Bug: 135791357
|
||||
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
|
||||
(cherry picked from commit c31e73121f4c1ec41143423ac6ce3ce6dafdcec1)
|
||||
[joe: Resolved minor conflict in drivers/foo/bar.c ]
|
||||
Signed-off-by: Joe Smith <joe.smith@foo.org>
|
||||
```
|
||||
|
||||
## Requirements for other backports: `FROMGIT:`, `FROMLIST:`,
|
||||
|
||||
- If the patch has been merged into an upstream maintainer tree, but has not yet
|
||||
been merged into Linux mainline
|
||||
- tag the patch subject with `FROMGIT:`
|
||||
- add info on where the patch came from as `(cherry picked from commit <sha1> <repo> <branch>)`. This
|
||||
must be a stable maintainer branch (not rebased, so don't use `linux-next` for example).
|
||||
- if changes were required, use `BACKPORT: FROMGIT:`
|
||||
- Example:
|
||||
- if the commit message in the maintainer tree is
|
||||
```
|
||||
important patch from upstream
|
||||
|
||||
This is the detailed description of the important patch
|
||||
|
||||
Signed-off-by: Fred Jones <fred.jones@foo.org>
|
||||
```
|
||||
>- then Joe Smith would upload the patch for the common kernel as
|
||||
```
|
||||
FROMGIT: important patch from upstream
|
||||
|
||||
This is the detailed description of the important patch
|
||||
|
||||
Signed-off-by: Fred Jones <fred.jones@foo.org>
|
||||
|
||||
Bug: 135791357
|
||||
(cherry picked from commit 878a2fd9de10b03d11d2f622250285c7e63deace
|
||||
https://git.kernel.org/pub/scm/linux/kernel/git/foo/bar.git test-branch)
|
||||
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
|
||||
Signed-off-by: Joe Smith <joe.smith@foo.org>
|
||||
```
|
||||
|
||||
|
||||
- If the patch has been submitted to LKML, but not accepted into any maintainer tree
|
||||
- tag the patch subject with `FROMLIST:`
|
||||
- add a `Link:` tag with a link to the submittal on lore.kernel.org
|
||||
- add a `Bug:` tag with the Android bug (required for patches not accepted into
|
||||
a maintainer tree)
|
||||
- if changes were required, use `BACKPORT: FROMLIST:`
|
||||
- Example:
|
||||
```
|
||||
FROMLIST: important patch from upstream
|
||||
|
||||
This is the detailed description of the important patch
|
||||
|
||||
Signed-off-by: Fred Jones <fred.jones@foo.org>
|
||||
|
||||
Bug: 135791357
|
||||
Link: https://lore.kernel.org/lkml/20190619171517.GA17557@someone.com/
|
||||
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
|
||||
Signed-off-by: Joe Smith <joe.smith@foo.org>
|
||||
```
|
||||
|
||||
## Requirements for Android-specific patches: `ANDROID:`
|
||||
|
||||
- If the patch is fixing a bug to Android-specific code
|
||||
- tag the patch subject with `ANDROID:`
|
||||
- add a `Fixes:` tag that cites the patch with the bug
|
||||
- Example:
|
||||
```
|
||||
ANDROID: fix android-specific bug in foobar.c
|
||||
|
||||
This is the detailed description of the important fix
|
||||
|
||||
Fixes: 1234abcd2468 ("foobar: add cool feature")
|
||||
Change-Id: I4caaaa566ea080fa148c5e768bb1a0b6f7201c01
|
||||
Signed-off-by: Joe Smith <joe.smith@foo.org>
|
||||
```
|
||||
|
||||
- If the patch is a new feature
|
||||
- tag the patch subject with `ANDROID:`
|
||||
- add a `Bug:` tag with the Android bug (required for android-specific features)
|
||||
|
||||
136
abi.bzl
136
abi.bzl
|
|
@ -1,136 +0,0 @@
|
|||
# SPDX-License-Identifier: GPL-2.0 OR Apache-2.0
|
||||
# Copyright (C) 2023 The Android Open Source Project
|
||||
|
||||
"""
|
||||
ABI aware build rules.
|
||||
"""
|
||||
|
||||
load("@bazel_skylib//lib:paths.bzl", "paths")
|
||||
load("@bazel_skylib//rules:copy_file.bzl", "copy_file")
|
||||
load("@bazel_skylib//rules:native_binary.bzl", "native_binary")
|
||||
|
||||
visibility("private")
|
||||
|
||||
_ALL_ABIS = ["arm", "arm64", "x86", "x86_64"]
|
||||
|
||||
def _copy_with_abi(
|
||||
name,
|
||||
visibility = None,
|
||||
path_prefix = None,
|
||||
abis = None,
|
||||
out = None):
|
||||
if not path_prefix:
|
||||
path_prefix = ""
|
||||
if not abis:
|
||||
abis = _ALL_ABIS
|
||||
if not out:
|
||||
out = name
|
||||
|
||||
for abi in abis:
|
||||
copy_file(
|
||||
name = "{name}_{abi}".format(name = name, abi = abi),
|
||||
src = ":{name}".format(name = name),
|
||||
out = paths.join(path_prefix, abi, out),
|
||||
allow_symlink = True,
|
||||
visibility = visibility,
|
||||
)
|
||||
|
||||
def cc_binary_with_abi(
|
||||
name,
|
||||
path_prefix = None,
|
||||
abis = None,
|
||||
visibility = None,
|
||||
out = None,
|
||||
**kwargs):
|
||||
"""A cc_binary replacement that generates output in each subdirectory named by abi.
|
||||
|
||||
For example:
|
||||
```
|
||||
cc_binary_with_abi(
|
||||
name = "a_binary",
|
||||
abis = ["x86_64", "arm64"],
|
||||
path_prefix = "my/path",
|
||||
)
|
||||
```
|
||||
generates 2 rules:
|
||||
* Rule a_binary_x86_64: Builds the cc_binary and put output in my/path/x86_64/a_binary.
|
||||
* Rule a_binary_arm64: Builds the cc_binary and put output in my/path/arm64/a_binary.
|
||||
|
||||
Args:
|
||||
name: the name of the build rule.
|
||||
path_prefix: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The path prefix to attach to output.
|
||||
abis: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The intended abis to generate. Default is arm64 & x86_64.
|
||||
visibility: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The visibility attribute on a target controls whether the target can be used in other packages.
|
||||
out: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The output filename. Default is `name`.
|
||||
**kwargs: the rest args that cc_binary uses.
|
||||
"""
|
||||
native.cc_binary(
|
||||
name = name,
|
||||
visibility = visibility,
|
||||
**kwargs
|
||||
)
|
||||
|
||||
_copy_with_abi(
|
||||
name = name,
|
||||
path_prefix = path_prefix,
|
||||
abis = abis,
|
||||
visibility = visibility,
|
||||
out = out,
|
||||
)
|
||||
|
||||
def sh_binary_with_abi(
|
||||
name,
|
||||
path_prefix = None,
|
||||
abis = None,
|
||||
visibility = None,
|
||||
out = None,
|
||||
**kwargs):
|
||||
"""A sh_binary replacement that generates output in each subdirectory named by abi.
|
||||
|
||||
For example:
|
||||
```
|
||||
sh_binary_with_abi(
|
||||
name = "a_binary",
|
||||
abis = ["x86_64", "arm64"],
|
||||
path_prefix = "my/path",
|
||||
)
|
||||
```
|
||||
generates 2 rules:
|
||||
* Rule a_binary_x86_64: Copies a_binary and put output in my/path/x86_64/a_binary.
|
||||
* Rule a_binary_arm64: Copies a_binary and put output in my/path/arm64/a_binary.
|
||||
|
||||
Args:
|
||||
name: the name of the build rule.
|
||||
path_prefix: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The path prefix to attach to output.
|
||||
abis: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The intended abis to generate. Default is arm64 & x86_64.
|
||||
visibility: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The visibility attribute on a target controls whether the target can be used in other packages.
|
||||
out: [Nonconfigurable](https://bazel.build/reference/be/common-definitions#configurable-attributes).
|
||||
The output filename. Default is `name`.
|
||||
**kwargs: the rest args that native_binary uses.
|
||||
"""
|
||||
if not out:
|
||||
out = name
|
||||
|
||||
# Uses native_binary instead of sh_binary because sh_binary is not
|
||||
# compatible with copy_file (sh_binary generates more than 1 outs).
|
||||
native_binary(
|
||||
name = name,
|
||||
visibility = visibility,
|
||||
out = out,
|
||||
**kwargs
|
||||
)
|
||||
|
||||
_copy_with_abi(
|
||||
name = name,
|
||||
path_prefix = path_prefix,
|
||||
abis = abis,
|
||||
visibility = visibility,
|
||||
out = out,
|
||||
)
|
||||
|
|
@ -1,5 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
# commonly used symbols
|
||||
module_layout
|
||||
__put_task_struct
|
||||
utf8_data_table
|
||||
438092
android/abi_gki_aarch64.stg
438092
android/abi_gki_aarch64.stg
File diff suppressed because it is too large
Load Diff
|
|
@ -1,103 +0,0 @@
|
|||
# How to use this file: http://go/approve-abi-break
|
||||
# ABI freeze commit: 666cbbfe5c567ca79da30dccad8b5257ca88f02c
|
||||
|
||||
type 'struct shash_alg' changed
|
||||
member 'u64 android_backport_reserved1' was removed
|
||||
member 'u64 android_backport_reserved2' was removed
|
||||
member 'union { int(* finup_mb)(struct shash_desc*, const u8* const*, unsigned int, u8* const*, unsigned int); struct { u64 android_backport_reserved1; }; union { }; }' was added
|
||||
member 'union { unsigned int mb_max_msgs; struct { u64 android_backport_reserved2; }; union { }; }' was added
|
||||
|
||||
type 'struct fsverity_info' changed
|
||||
byte size changed from 272 to 264
|
||||
member 'spinlock_t hash_page_init_lock' was removed
|
||||
|
||||
type 'enum binder_work_type' changed
|
||||
enumerator 'BINDER_WORK_FROZEN_BINDER' (10) was added
|
||||
... 1 other enumerator(s) added
|
||||
|
||||
type 'struct ufs_clk_scaling' changed
|
||||
member 'bool suspend_on_no_request' was added
|
||||
|
||||
type 'struct tty_operations' changed
|
||||
member 'u64 android_kabi_reserved1' was removed
|
||||
member 'union { int(* ldisc_ok)(struct tty_struct*, int); struct { u64 android_kabi_reserved1; }; union { }; }' was added
|
||||
|
||||
type 'struct kvm_hyp_iommu' changed
|
||||
member changed from 'hyp_spinlock_t lock' to 'u32 lock'
|
||||
type changed from 'hyp_spinlock_t' = 'union hyp_spinlock' to 'u32' = '__u32' = 'unsigned int'
|
||||
resolved type changed from 'union hyp_spinlock' to 'unsigned int'
|
||||
|
||||
type 'struct fsverity_hash_alg' changed
|
||||
member 'int mb_max_msgs' was added
|
||||
|
||||
type 'struct pkvm_module_ops' changed
|
||||
member 'u64 android_kabi_reserved1' was removed
|
||||
member 'u64 android_kabi_reserved2' was removed
|
||||
member 'u64 android_kabi_reserved3' was removed
|
||||
member 'union { void(* iommu_flush_unmap_cache)(struct kvm_iommu_paddr_cache*); struct { u64 android_kabi_reserved1; }; union { }; }' was added
|
||||
member 'union { int(* host_stage2_enable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved2; }; union { }; }' was added
|
||||
member 'union { int(* host_stage2_disable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved3; }; union { }; }' was added
|
||||
|
||||
type 'struct kvm_hyp_iommu' changed
|
||||
member 'u32 unused' was removed
|
||||
member 'u32 lock' was added
|
||||
|
||||
type 'struct pkvm_module_ops' changed
|
||||
member 'u64 android_kabi_reserved2' was removed
|
||||
member 'u64 android_kabi_reserved3' was removed
|
||||
member 'union { int(* host_stage2_enable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved2; }; union { }; }' was added
|
||||
member 'union { int(* host_stage2_disable_lazy_pte)(u64, u64); struct { u64 android_kabi_reserved3; }; union { }; }' was added
|
||||
|
||||
11 function symbol(s) removed
|
||||
'int __traceiter_android_rvh_ogki_hiview_hievent_create(void*, unsigned int, void**)'
|
||||
'int __traceiter_android_rvh_ogki_hiview_hievent_destroy(void*, void*)'
|
||||
'int __traceiter_android_rvh_ogki_hiview_hievent_put_integral(void*, void*, const char*, long long, int*)'
|
||||
'int __traceiter_android_rvh_ogki_hiview_hievent_put_string(void*, void*, const char*, const char*, int*)'
|
||||
'int __traceiter_android_rvh_ogki_hiview_hievent_report(void*, void*, int*)'
|
||||
'int __traceiter_android_rvh_ogki_security_audit_log_module_sign(void*, int)'
|
||||
'int __traceiter_android_rvh_ogki_security_audit_log_usercopy(void*, bool, const char*, unsigned long)'
|
||||
'int __traceiter_android_vh_ogki_security_audit_log_cfi(void*, unsigned long, unsigned long*)'
|
||||
'int __traceiter_android_vh_ogki_security_audit_log_setid(void*, u32, u32, u32)'
|
||||
'int __traceiter_android_vh_ogki_tcp_rcv_established_fast_path(void*, struct sock*)'
|
||||
'int __traceiter_android_vh_ogki_tcp_rcv_established_slow_path(void*, struct sock*)'
|
||||
|
||||
11 variable symbol(s) removed
|
||||
'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_create'
|
||||
'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_destroy'
|
||||
'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_put_integral'
|
||||
'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_put_string'
|
||||
'struct tracepoint __tracepoint_android_rvh_ogki_hiview_hievent_report'
|
||||
'struct tracepoint __tracepoint_android_rvh_ogki_security_audit_log_module_sign'
|
||||
'struct tracepoint __tracepoint_android_rvh_ogki_security_audit_log_usercopy'
|
||||
'struct tracepoint __tracepoint_android_vh_ogki_security_audit_log_cfi'
|
||||
'struct tracepoint __tracepoint_android_vh_ogki_security_audit_log_setid'
|
||||
'struct tracepoint __tracepoint_android_vh_ogki_tcp_rcv_established_fast_path'
|
||||
'struct tracepoint __tracepoint_android_vh_ogki_tcp_rcv_established_slow_path'
|
||||
|
||||
type 'enum ftrace_dump_mode' changed
|
||||
enumerator 'DUMP_PARAM' (3) was added
|
||||
|
||||
1 function symbol(s) removed
|
||||
'int __traceiter_android_vh_suitable_migration_target_bypass(void*, struct page*, bool*)'
|
||||
|
||||
1 variable symbol(s) removed
|
||||
'struct tracepoint __tracepoint_android_vh_suitable_migration_target_bypass'
|
||||
|
||||
type 'struct cgroup_root' changed
|
||||
member 'u8 android_backport_reserved1[28]' was removed
|
||||
member 'union { struct callback_head rcu; struct { u8 android_backport_reserved1[28]; }; union { }; }' was added
|
||||
|
||||
1 function symbol(s) removed
|
||||
'int __traceiter_android_vh_mutex_unlock_slowpath_before_wakeq(void*, struct mutex*)'
|
||||
|
||||
1 variable symbol(s) removed
|
||||
'struct tracepoint __tracepoint_android_vh_mutex_unlock_slowpath_before_wakeq'
|
||||
|
||||
2 function symbol(s) removed
|
||||
'int __traceiter_android_vh_mutex_unlock_slowpath_before_wakeq(void*, struct mutex*)'
|
||||
'int __traceiter_android_vh_suitable_migration_target_bypass(void*, struct page*, bool*)'
|
||||
|
||||
2 variable symbol(s) removed
|
||||
'struct tracepoint __tracepoint_android_vh_mutex_unlock_slowpath_before_wakeq'
|
||||
'struct tracepoint __tracepoint_android_vh_suitable_migration_target_bypass'
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,74 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
|
||||
# required by asr5803.ko
|
||||
sdhci_enable_sdio_irq
|
||||
|
||||
# required by asr_serial.ko
|
||||
uart_get_divisor
|
||||
uart_handle_cts_change
|
||||
uart_handle_dcd_change
|
||||
uart_insert_char
|
||||
|
||||
# required by ehci-asr-ci.ko
|
||||
ehci_init_driver
|
||||
ehci_setup
|
||||
|
||||
# required by phy-asr-ci-usb2.ko
|
||||
usb_add_phy_dev
|
||||
usb_remove_phy
|
||||
|
||||
# required by pvrsrvkm.ko
|
||||
call_rcu
|
||||
devm_devfreq_remove_device
|
||||
dev_pm_opp_remove
|
||||
dma_fence_array_ops
|
||||
dma_fence_enable_sw_signaling
|
||||
idr_replace
|
||||
kthread_freezable_should_stop
|
||||
rcu_barrier
|
||||
|
||||
# required by sdhci_asr.ko
|
||||
sdhci_resume_host
|
||||
sdhci_send_tuning
|
||||
sdhci_set_clock
|
||||
sdhci_set_uhs_signaling
|
||||
sdhci_suspend_host
|
||||
|
||||
# required by vh_sched.ko
|
||||
__traceiter_android_vh_map_util_freq
|
||||
__tracepoint_android_vh_map_util_freq
|
||||
|
||||
# required by asr_drm.ko
|
||||
clk_set_rate_exclusive
|
||||
clk_rate_exclusive_put
|
||||
|
||||
# required by mercury.ko
|
||||
media_device_register_entity
|
||||
media_device_unregister_entity
|
||||
v4l2_ctrl_get_menu
|
||||
v4l2_ctrl_type_op_equal
|
||||
v4l2_ctrl_type_op_init
|
||||
v4l2_ctrl_type_op_log
|
||||
v4l2_m2m_buf_done_and_job_finish
|
||||
v4l2_m2m_last_buf
|
||||
v4l2_type_names
|
||||
devm_devfreq_register_opp_notifier
|
||||
|
||||
# required by jpu_heap.ko
|
||||
kmem_cache_size
|
||||
memset16
|
||||
|
||||
# required by dwc3.ko
|
||||
extcon_find_edev_by_node
|
||||
phy_pm_runtime_put_sync
|
||||
usb_get_maximum_ssp_rate
|
||||
|
||||
# required by xhci-asr.ko
|
||||
extcon_find_edev_by_node
|
||||
|
||||
# required by clk-asr.ko
|
||||
clk_register_mux_table
|
||||
|
||||
# required by keypad-asr.ko
|
||||
input_device_enabled
|
||||
fwnode_create_software_node
|
||||
|
|
@ -1,11 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
# aura sync
|
||||
hid_unregister_driver
|
||||
hid_hw_raw_request
|
||||
hid_open_report
|
||||
hid_hw_start
|
||||
hid_hw_stop
|
||||
__hid_register_driver
|
||||
hid_hw_output_report
|
||||
hid_hw_open
|
||||
hid_hw_close
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -1,146 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
# commonly used symbols
|
||||
module_layout
|
||||
__put_task_struct
|
||||
|
||||
# required by fips140.ko
|
||||
aead_register_instance
|
||||
ahash_register_instance
|
||||
arch_timer_read_counter
|
||||
bcmp
|
||||
complete_all
|
||||
completion_done
|
||||
cpu_have_feature
|
||||
crypto_aead_decrypt
|
||||
crypto_aead_encrypt
|
||||
crypto_aead_setauthsize
|
||||
crypto_aead_setkey
|
||||
crypto_ahash_finup
|
||||
crypto_ahash_setkey
|
||||
crypto_alg_list
|
||||
crypto_alg_sem
|
||||
crypto_alloc_aead
|
||||
crypto_alloc_rng
|
||||
crypto_alloc_shash
|
||||
crypto_alloc_skcipher
|
||||
crypto_attr_alg_name
|
||||
crypto_check_attr_type
|
||||
crypto_cipher_encrypt_one
|
||||
crypto_cipher_setkey
|
||||
crypto_clone_cipher
|
||||
crypto_clone_shash
|
||||
crypto_destroy_tfm
|
||||
crypto_drop_spawn
|
||||
crypto_get_default_null_skcipher
|
||||
crypto_grab_aead
|
||||
crypto_grab_ahash
|
||||
crypto_grab_shash
|
||||
crypto_grab_skcipher
|
||||
crypto_grab_spawn
|
||||
crypto_inst_setname
|
||||
crypto_put_default_null_skcipher
|
||||
crypto_register_aead
|
||||
crypto_register_aeads
|
||||
crypto_register_ahash
|
||||
crypto_register_ahashes
|
||||
crypto_register_alg
|
||||
crypto_register_algs
|
||||
crypto_register_rng
|
||||
crypto_register_rngs
|
||||
crypto_register_shash
|
||||
crypto_register_shashes
|
||||
crypto_register_skcipher
|
||||
crypto_register_skciphers
|
||||
crypto_register_template
|
||||
crypto_register_templates
|
||||
crypto_remove_spawns
|
||||
crypto_req_done
|
||||
crypto_rng_reset
|
||||
crypto_shash_digest
|
||||
crypto_shash_final
|
||||
crypto_shash_finup
|
||||
crypto_shash_setkey
|
||||
crypto_shash_tfm_digest
|
||||
crypto_shash_update
|
||||
crypto_skcipher_decrypt
|
||||
crypto_skcipher_encrypt
|
||||
crypto_skcipher_setkey
|
||||
crypto_spawn_tfm
|
||||
crypto_spawn_tfm2
|
||||
crypto_unregister_aeads
|
||||
crypto_unregister_alg
|
||||
crypto_unregister_rng
|
||||
crypto_unregister_rngs
|
||||
crypto_unregister_shash
|
||||
crypto_unregister_shashes
|
||||
crypto_unregister_skciphers
|
||||
crypto_unregister_template
|
||||
crypto_unregister_templates
|
||||
down_read
|
||||
down_write
|
||||
fortify_panic
|
||||
fpsimd_context_busy
|
||||
get_random_bytes
|
||||
__init_swait_queue_head
|
||||
irq_stat
|
||||
jiffies
|
||||
kasan_flag_enabled
|
||||
kernel_neon_begin
|
||||
kernel_neon_end
|
||||
kfree
|
||||
kfree_sensitive
|
||||
__kmalloc
|
||||
kmalloc_caches
|
||||
kmalloc_trace
|
||||
kmemdup
|
||||
ktime_get
|
||||
__list_add_valid_or_report
|
||||
__list_del_entry_valid_or_report
|
||||
memcpy
|
||||
memset
|
||||
__mutex_init
|
||||
mutex_lock
|
||||
mutex_unlock
|
||||
panic
|
||||
preempt_schedule_notrace
|
||||
_printk
|
||||
___ratelimit
|
||||
_raw_spin_lock
|
||||
_raw_spin_unlock
|
||||
refcount_warn_saturate
|
||||
rng_is_initialized
|
||||
scatterwalk_ffwd
|
||||
scatterwalk_map_and_copy
|
||||
sg_init_one
|
||||
sg_init_table
|
||||
sg_next
|
||||
shash_free_singlespawn_instance
|
||||
shash_no_setkey
|
||||
shash_register_instance
|
||||
skcipher_alloc_instance_simple
|
||||
skcipher_register_instance
|
||||
skcipher_walk_aead_decrypt
|
||||
skcipher_walk_aead_encrypt
|
||||
skcipher_walk_done
|
||||
skcipher_walk_virt
|
||||
snprintf
|
||||
__stack_chk_fail
|
||||
strcmp
|
||||
strlen
|
||||
strncmp
|
||||
strnlen
|
||||
strscpy
|
||||
__traceiter_android_vh_aes_decrypt
|
||||
__traceiter_android_vh_aes_encrypt
|
||||
__traceiter_android_vh_aes_expandkey
|
||||
__traceiter_android_vh_sha256
|
||||
__tracepoint_android_vh_aes_decrypt
|
||||
__tracepoint_android_vh_aes_encrypt
|
||||
__tracepoint_android_vh_aes_expandkey
|
||||
__tracepoint_android_vh_sha256
|
||||
tracepoint_probe_register
|
||||
up_read
|
||||
up_write
|
||||
wait_for_completion
|
||||
xa_load
|
||||
xa_store
|
||||
|
|
@ -1,250 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
blkcg_activate_policy
|
||||
blkcg_deactivate_policy
|
||||
blkcg_root
|
||||
blkdev_get_by_path
|
||||
blkdev_issue_flush
|
||||
blk_mq_sched_mark_restart_hctx
|
||||
blk_mq_sched_try_insert_merge
|
||||
blk_mq_sched_try_merge
|
||||
blk_queue_rq_timeout
|
||||
blk_req_needs_zone_write_lock
|
||||
__blk_req_zone_write_lock
|
||||
__blk_req_zone_write_unlock
|
||||
caches_clean_inval_pou
|
||||
cleancache_register_ops
|
||||
compact_node_async
|
||||
copy_page
|
||||
_dev_alert
|
||||
device_pm_wait_for_dev
|
||||
__devm_alloc_percpu
|
||||
dma_heap_try_get_pool_size_kb
|
||||
elv_bio_merge_ok
|
||||
elv_rb_add
|
||||
elv_rb_del
|
||||
elv_rb_find
|
||||
elv_rb_former_request
|
||||
elv_rb_latter_request
|
||||
elv_rqhash_add
|
||||
elv_rqhash_del
|
||||
free_hpage
|
||||
file_ra_state_init
|
||||
file_write_and_wait_range
|
||||
generic_perform_write
|
||||
getboottime64
|
||||
get_options
|
||||
__get_task_ioprio
|
||||
gpiochip_find
|
||||
gs_alloc_req
|
||||
gserial_free_line
|
||||
gserial_resume
|
||||
gserial_suspend
|
||||
gs_free_req
|
||||
kick_all_cpus_sync
|
||||
mas_walk
|
||||
mas_prev
|
||||
mas_next
|
||||
mm_access
|
||||
netlink_ack
|
||||
param_get_uint
|
||||
param_set_uint
|
||||
pidfd_get_pid
|
||||
prep_compound_page
|
||||
prep_new_hpage
|
||||
proc_set_size
|
||||
pstore_register
|
||||
pstore_unregister
|
||||
rfkill_find_type
|
||||
rfkill_get_led_trigger_name
|
||||
rfkill_pause_polling
|
||||
rfkill_set_led_trigger_name
|
||||
rfkill_set_states
|
||||
rfkill_soft_blocked
|
||||
scsi_device_quiesce
|
||||
scsi_device_resume
|
||||
smpboot_unregister_percpu_thread
|
||||
stack_trace_save_regs
|
||||
swp_swapcount
|
||||
__kfree_skb
|
||||
__traceiter_android_rvh_arm64_serror_panic
|
||||
__traceiter_android_rvh_die_kernel_fault
|
||||
__traceiter_android_rvh_do_el1_bti
|
||||
__traceiter_android_rvh_do_el1_fpac
|
||||
__traceiter_android_rvh_do_el1_undef
|
||||
__traceiter_android_rvh_do_sea
|
||||
__traceiter_android_rvh_do_sp_pc_abort
|
||||
__traceiter_android_rvh_ksys_umount
|
||||
__traceiter_android_rvh_panic_unhandled
|
||||
__traceiter_android_rvh_process_madvise_bypass
|
||||
__traceiter_android_rvh_report_bug
|
||||
__traceiter_android_rvh_try_alloc_pages
|
||||
__traceiter_android_rvh_try_alloc_pages_gfp
|
||||
__traceiter_android_rvh_usb_dev_suspend
|
||||
__traceiter_android_vh_alloc_contig_range_not_isolated
|
||||
__traceiter_android_vh_alloc_pages_slowpath_start
|
||||
__traceiter_android_vh_alloc_pages_slowpath_end
|
||||
__traceiter_android_vh_cache_show
|
||||
__traceiter_android_vh_cma_alloc_set_max_retries
|
||||
__traceiter_android_vh_cma_debug_show_areas
|
||||
__traceiter_android_vh_direct_reclaim_begin
|
||||
__traceiter_android_vh_direct_reclaim_end
|
||||
__traceiter_android_vh_dma_heap_buffer_alloc_start
|
||||
__traceiter_android_vh_dma_heap_buffer_alloc_end
|
||||
__traceiter_android_vh_dmabuf_page_pool_free_bypass
|
||||
__traceiter_android_vh_do_read_fault
|
||||
__traceiter_android_vh_dpm_wait_finish
|
||||
__traceiter_android_vh_dpm_wait_start
|
||||
__traceiter_android_vh_exit_mm
|
||||
__traceiter_android_vh_filemap_fault_start
|
||||
__traceiter_android_vh_filemap_fault_end
|
||||
__traceiter_android_vh_filemap_read
|
||||
__traceiter_android_vh_filemap_map_pages
|
||||
__traceiter_android_vh_flush_work_wait_finish
|
||||
__traceiter_android_vh_flush_work_wait_start
|
||||
__traceiter_android_vh_flush_wq_wait_finish
|
||||
__traceiter_android_vh_flush_wq_wait_start
|
||||
__traceiter_android_vh_free_pages_prepare_bypass
|
||||
__traceiter_android_vh_free_pages_ok_bypass
|
||||
__traceiter_android_vh_is_fpsimd_save
|
||||
__traceiter_android_vh_logbuf
|
||||
__traceiter_android_vh_logbuf_pr_cont
|
||||
__traceiter_android_vh_madvise_pageout_bypass
|
||||
__traceiter_android_vh_madvise_pageout_return_error
|
||||
__traceiter_android_vh_madvise_pageout_swap_entry
|
||||
__traceiter_android_vh_madvise_swapin_walk_pmd_entry
|
||||
__traceiter_android_vh_meminfo_proc_show
|
||||
__traceiter_android_vh_migration_target_bypass
|
||||
__traceiter_android_vh_mmc_update_mmc_queue
|
||||
__traceiter_android_vh_si_meminfo_adjust_shmem
|
||||
__traceiter_android_vh_shmem_mod_shmem
|
||||
__traceiter_android_vh_shmem_mod_swapped
|
||||
__traceiter_android_vh_page_cache_readahead_start
|
||||
__traceiter_android_vh_page_cache_readahead_end
|
||||
__traceiter_android_vh_print_slabinfo_header
|
||||
__traceiter_android_vh_process_madvise
|
||||
__traceiter_android_vh_process_madvise_return_error
|
||||
__traceiter_android_vh_psi_update_triggers
|
||||
__traceiter_android_vh_ptype_head
|
||||
__traceiter_android_vh_rebalance_anon_lru_bypass
|
||||
__traceiter_android_vh_rtmutex_wait_finish
|
||||
__traceiter_android_vh_show_mem
|
||||
__traceiter_android_vh_show_smap
|
||||
__traceiter_android_vh_smaps_pte_entry
|
||||
__traceiter_android_vh_smaps_swap_shared
|
||||
__traceiter_android_vh_show_smap_swap_shared
|
||||
__traceiter_android_vh_split_large_folio_bypass
|
||||
__traceiter_android_vh_sync_irq_wait_finish
|
||||
__traceiter_android_vh_sync_irq_wait_start
|
||||
__traceiter_android_vh_try_to_freeze_todo
|
||||
__traceiter_android_vh_try_to_freeze_todo_unfrozen
|
||||
__traceiter_android_vh_tune_scan_control
|
||||
__traceiter_android_vh_usb_dev_resume
|
||||
__traceiter_android_vh_usb_new_device_added
|
||||
__traceiter_android_vh_use_vm_swappiness
|
||||
__traceiter_android_vh_warn_alloc_tune_ratelimit
|
||||
__traceiter_android_vh_warn_alloc_show_mem_bypass
|
||||
__traceiter_android_vh_watchdog_timer_softlockup
|
||||
__traceiter_android_vh_wq_lockup_pool
|
||||
__traceiter_android_vh_xhci_resume
|
||||
__traceiter_android_vh_xhci_suspend
|
||||
__traceiter_android_vh_zs_shrinker_adjust
|
||||
__traceiter_android_vh_zs_shrinker_bypass
|
||||
__traceiter_console
|
||||
__traceiter_consume_skb
|
||||
__traceiter_error_report_end
|
||||
__traceiter_vm_unmapped_area
|
||||
__traceiter_workqueue_execute_start
|
||||
__traceiter_kfree_skb
|
||||
__tracepoint_android_rvh_arm64_serror_panic
|
||||
__tracepoint_android_rvh_die_kernel_fault
|
||||
__tracepoint_android_rvh_do_el1_bti
|
||||
__tracepoint_android_rvh_do_el1_fpac
|
||||
__tracepoint_android_rvh_do_el1_undef
|
||||
__tracepoint_android_rvh_do_sea
|
||||
__tracepoint_android_rvh_do_sp_pc_abort
|
||||
__tracepoint_android_rvh_ksys_umount
|
||||
__tracepoint_android_rvh_panic_unhandled
|
||||
__tracepoint_android_rvh_process_madvise_bypass
|
||||
__tracepoint_android_rvh_report_bug
|
||||
__tracepoint_android_rvh_try_alloc_pages
|
||||
__tracepoint_android_rvh_try_alloc_pages_gfp
|
||||
__tracepoint_android_rvh_usb_dev_suspend
|
||||
__tracepoint_android_vh_alloc_contig_range_not_isolated
|
||||
__tracepoint_android_vh_alloc_pages_slowpath_start
|
||||
__tracepoint_android_vh_alloc_pages_slowpath_end
|
||||
__tracepoint_android_vh_cache_show
|
||||
__tracepoint_android_vh_cma_alloc_set_max_retries
|
||||
__tracepoint_android_vh_cma_debug_show_areas
|
||||
__tracepoint_android_vh_direct_reclaim_begin
|
||||
__tracepoint_android_vh_direct_reclaim_end
|
||||
__tracepoint_android_vh_dma_heap_buffer_alloc_start
|
||||
__tracepoint_android_vh_dma_heap_buffer_alloc_end
|
||||
__tracepoint_android_vh_dmabuf_page_pool_free_bypass
|
||||
__tracepoint_android_vh_do_read_fault
|
||||
__tracepoint_android_vh_dpm_wait_finish
|
||||
__tracepoint_android_vh_dpm_wait_start
|
||||
__tracepoint_android_vh_exit_mm
|
||||
__tracepoint_android_vh_filemap_fault_start
|
||||
__tracepoint_android_vh_filemap_fault_end
|
||||
__tracepoint_android_vh_filemap_read
|
||||
__tracepoint_android_vh_filemap_map_pages
|
||||
__tracepoint_android_vh_flush_work_wait_finish
|
||||
__tracepoint_android_vh_flush_work_wait_start
|
||||
__tracepoint_android_vh_flush_wq_wait_finish
|
||||
__tracepoint_android_vh_flush_wq_wait_start
|
||||
__tracepoint_android_vh_free_pages_prepare_bypass
|
||||
__tracepoint_android_vh_free_pages_ok_bypass
|
||||
__tracepoint_android_vh_is_fpsimd_save
|
||||
__tracepoint_android_vh_logbuf
|
||||
__tracepoint_android_vh_logbuf_pr_cont
|
||||
__tracepoint_android_vh_madvise_pageout_bypass
|
||||
__tracepoint_android_vh_madvise_pageout_return_error
|
||||
__tracepoint_android_vh_madvise_pageout_swap_entry
|
||||
__tracepoint_android_vh_madvise_swapin_walk_pmd_entry
|
||||
__tracepoint_android_vh_meminfo_proc_show
|
||||
__tracepoint_android_vh_migration_target_bypass
|
||||
__tracepoint_android_vh_mmc_update_mmc_queue
|
||||
__tracepoint_android_vh_si_meminfo_adjust_shmem
|
||||
__tracepoint_android_vh_shmem_mod_shmem
|
||||
__tracepoint_android_vh_shmem_mod_swapped
|
||||
__tracepoint_android_vh_page_cache_readahead_start
|
||||
__tracepoint_android_vh_page_cache_readahead_end
|
||||
__tracepoint_android_vh_print_slabinfo_header
|
||||
__tracepoint_android_vh_process_madvise
|
||||
__tracepoint_android_vh_process_madvise_return_error
|
||||
__tracepoint_android_vh_psi_update_triggers
|
||||
__tracepoint_android_vh_ptype_head
|
||||
__tracepoint_android_vh_rebalance_anon_lru_bypass
|
||||
__tracepoint_android_vh_rtmutex_wait_finish
|
||||
__tracepoint_android_vh_show_mem
|
||||
__tracepoint_android_vh_show_smap
|
||||
__tracepoint_android_vh_smaps_pte_entry
|
||||
__tracepoint_android_vh_smaps_swap_shared
|
||||
__tracepoint_android_vh_show_smap_swap_shared
|
||||
__tracepoint_android_vh_split_large_folio_bypass
|
||||
__tracepoint_android_vh_sync_irq_wait_finish
|
||||
__tracepoint_android_vh_sync_irq_wait_start
|
||||
__tracepoint_android_vh_try_to_freeze_todo
|
||||
__tracepoint_android_vh_try_to_freeze_todo_unfrozen
|
||||
__tracepoint_android_vh_tune_scan_control
|
||||
__tracepoint_android_vh_usb_dev_resume
|
||||
__tracepoint_android_vh_usb_new_device_added
|
||||
__tracepoint_android_vh_use_vm_swappiness
|
||||
__tracepoint_android_vh_warn_alloc_tune_ratelimit
|
||||
__tracepoint_android_vh_warn_alloc_show_mem_bypass
|
||||
__tracepoint_android_vh_watchdog_timer_softlockup
|
||||
__tracepoint_android_vh_wq_lockup_pool
|
||||
__tracepoint_android_vh_xhci_resume
|
||||
__tracepoint_android_vh_xhci_suspend
|
||||
__tracepoint_android_vh_zs_shrinker_adjust
|
||||
__tracepoint_android_vh_zs_shrinker_bypass
|
||||
__tracepoint_console
|
||||
__tracepoint_consume_skb
|
||||
__tracepoint_error_report_end
|
||||
__tracepoint_vm_unmapped_area
|
||||
__tracepoint_workqueue_execute_start
|
||||
__tracepoint_kfree_skb
|
||||
usb_set_device_state
|
||||
yield
|
||||
regulator_get_current_limit
|
||||
android_create_function_device
|
||||
|
|
@ -1,254 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
is_vmalloc_or_module_addr
|
||||
kfree
|
||||
__kmalloc
|
||||
arch_vma_name
|
||||
anon_vma_name
|
||||
walk_page_range
|
||||
vm_normal_page
|
||||
pmd_clear_bad
|
||||
__pmd_trans_huge_lock
|
||||
__pte_offset_map_lock
|
||||
mod_node_page_state
|
||||
page_cache_sync_ra
|
||||
proc_create
|
||||
profile_event_register
|
||||
si_swapinfo
|
||||
single_open
|
||||
sock_from_file
|
||||
task_cputime_adjusted
|
||||
tcp_sync_mss
|
||||
netdev_get_name
|
||||
tcp_send_active_reset
|
||||
fwnode_usb_role_switch_get
|
||||
usb_for_each_dev
|
||||
dev_valid_name
|
||||
sock_from_file
|
||||
tcp_done
|
||||
udp4_lib_lookup
|
||||
udp6_lib_lookup
|
||||
rtc_time64_to_tm
|
||||
proc_create_net_single
|
||||
proc_create_net_single_write
|
||||
snmp_fold_field
|
||||
call_usermodehelper
|
||||
pm_wakeup_irq
|
||||
nla_append
|
||||
skb_append
|
||||
sysctl_max_skb_frags
|
||||
__show_mem
|
||||
find_vm_area
|
||||
profile_event_unregister
|
||||
binder_alloc_copy_from_buffer
|
||||
ufshcd_query_descriptor_retry
|
||||
ufshcd_query_attr
|
||||
nvmem_device_find
|
||||
device_match_of_node
|
||||
drop_super
|
||||
filp_open_block
|
||||
mm_trace_rss_stat
|
||||
get_slabinfo
|
||||
xas_find
|
||||
contpte_ptep_test_and_clear_young
|
||||
tty_dev_name_to_number
|
||||
tty_kopen_exclusive
|
||||
tty_unlock
|
||||
tty_set_ldisc
|
||||
tty_kclose
|
||||
android_debug_per_cpu_symbol
|
||||
android_debug_symbol
|
||||
__traceiter_rpm_idle
|
||||
__tracepoint_rpm_idle
|
||||
__traceiter_rpm_suspend
|
||||
__tracepoint_rpm_suspend
|
||||
__traceiter_rpm_resume
|
||||
__tracepoint_rpm_resume
|
||||
__traceiter_rpm_return_int
|
||||
__tracepoint_rpm_return_int
|
||||
__kfifo_len_r
|
||||
__traceiter_android_vh_killed_process
|
||||
__tracepoint_android_vh_killed_process
|
||||
__traceiter_android_vh_rwsem_write_wait_finish
|
||||
__tracepoint_android_vh_rwsem_write_wait_finish
|
||||
__tracepoint_android_rvh_cpuinfo_c_show
|
||||
__traceiter_android_rvh_cpuinfo_c_show
|
||||
__tracepoint_android_vh_dc_send_copy
|
||||
__traceiter_android_vh_dc_send_copy
|
||||
__tracepoint_android_vh_dc_receive
|
||||
__traceiter_android_vh_dc_receive
|
||||
__traceiter_android_vh_inet_create
|
||||
__tracepoint_android_vh_inet_create
|
||||
__traceiter_android_vh_uplink_send_msg
|
||||
__tracepoint_android_vh_uplink_send_msg
|
||||
__traceiter_android_vh_sock_create
|
||||
__tracepoint_android_vh_sock_create
|
||||
__traceiter_android_vh_modify_scan_control
|
||||
__traceiter_android_vh_should_continue_reclaim
|
||||
__tracepoint_android_vh_process_madvise_begin
|
||||
__traceiter_android_vh_process_madvise_begin
|
||||
__tracepoint_android_vh_process_madvise_iter
|
||||
__traceiter_android_vh_process_madvise_iter
|
||||
__traceiter_android_vh_file_is_tiny_bypass
|
||||
__tracepoint_android_vh_modify_scan_control
|
||||
__tracepoint_android_vh_should_continue_reclaim
|
||||
__tracepoint_android_vh_file_is_tiny_bypass
|
||||
__tracepoint_android_vh_shrink_slab_bypass
|
||||
__traceiter_android_vh_shrink_slab_bypass
|
||||
__tracepoint_android_vh_do_shrink_slab
|
||||
__traceiter_android_vh_do_shrink_slab
|
||||
__tracepoint_android_vh_shrink_slab_bypass
|
||||
__traceiter_android_vh_shrink_slab_bypass
|
||||
__tracepoint_android_vh_slab_alloc_node
|
||||
__traceiter_android_vh_slab_alloc_node
|
||||
__tracepoint_android_vh_slab_free
|
||||
__traceiter_android_vh_slab_free
|
||||
__traceiter_android_vh_should_fault_around
|
||||
__tracepoint_android_vh_should_fault_around
|
||||
__traceiter_android_vh_mglru_should_abort_scan
|
||||
__tracepoint_android_vh_mglru_should_abort_scan
|
||||
__traceiter_android_vh_mglru_should_abort_scan_order
|
||||
__tracepoint_android_vh_mglru_should_abort_scan_order
|
||||
__traceiter_android_vh_tcp_connect
|
||||
__tracepoint_android_vh_tcp_connect
|
||||
__traceiter_android_vh_tcp_write_timeout_estab_retrans
|
||||
__tracepoint_android_vh_tcp_write_timeout_estab_retrans
|
||||
__traceiter_android_vh_inet_csk_clone_lock
|
||||
__tracepoint_android_vh_inet_csk_clone_lock
|
||||
__traceiter_android_vh_tcp_clean_rtx_queue
|
||||
__tracepoint_android_vh_tcp_clean_rtx_queue
|
||||
__traceiter_android_vh_tcp_rcv_synack
|
||||
__tracepoint_android_vh_tcp_rcv_synack
|
||||
__traceiter_android_vh_udp_unicast_rcv_skb
|
||||
__tracepoint_android_vh_udp_unicast_rcv_skb
|
||||
__traceiter_android_vh_udp6_unicast_rcv_skb
|
||||
__tracepoint_android_vh_udp6_unicast_rcv_skb
|
||||
__traceiter_android_vh_tcp_rcv_established_fast_path
|
||||
__tracepoint_android_vh_tcp_rcv_established_fast_path
|
||||
__traceiter_android_vh_tcp_rcv_established_slow_path
|
||||
__tracepoint_android_vh_tcp_rcv_established_slow_path
|
||||
__tracepoint_android_vh_si_mem_available_adjust
|
||||
__traceiter_android_vh_si_mem_available_adjust
|
||||
__tracepoint_android_vh_si_meminfo_adjust
|
||||
__traceiter_android_vh_si_meminfo_adjust
|
||||
__traceiter_android_vh_rwsem_write_finished
|
||||
__tracepoint_android_vh_rwsem_write_finished
|
||||
__traceiter_android_vh_tcp_v4_connect
|
||||
__tracepoint_android_vh_tcp_v4_connect
|
||||
__traceiter_android_vh_tcp_v6_connect
|
||||
__tracepoint_android_vh_tcp_v6_connect
|
||||
__traceiter_android_vh_udp_v4_connect
|
||||
__tracepoint_android_vh_udp_v4_connect
|
||||
__traceiter_android_vh_udp_v6_connect
|
||||
__tracepoint_android_vh_udp_v6_connect
|
||||
__traceiter_android_rvh_dma_buf_stats_teardown
|
||||
__tracepoint_android_rvh_dma_buf_stats_teardown
|
||||
__traceiter_android_rvh_hw_protection_shutdown
|
||||
__tracepoint_android_rvh_hw_protection_shutdown
|
||||
__traceiter_android_rvh_bpf_int_jit_compile_ro
|
||||
__tracepoint_android_rvh_bpf_int_jit_compile_ro
|
||||
__traceiter_android_vh_tcp_sock_error
|
||||
__tracepoint_android_vh_tcp_sock_error
|
||||
__traceiter_android_vh_tcp_select_window
|
||||
__tracepoint_android_vh_tcp_select_window
|
||||
__traceiter_android_vh_tcp_fastsyn
|
||||
__tracepoint_android_vh_tcp_fastsyn
|
||||
__traceiter_android_vh_tcp_state_change
|
||||
__tracepoint_android_vh_tcp_state_change
|
||||
__traceiter_android_vh_tcp_update_rtt
|
||||
__tracepoint_android_vh_tcp_update_rtt
|
||||
__traceiter_android_vh_sk_alloc
|
||||
__tracepoint_android_vh_sk_alloc
|
||||
__traceiter_android_vh_sk_free
|
||||
__tracepoint_android_vh_sk_free
|
||||
__traceiter_android_vh_sk_clone_lock
|
||||
__tracepoint_android_vh_sk_clone_lock
|
||||
__traceiter_android_rvh_f2fs_down_read
|
||||
__tracepoint_android_rvh_f2fs_down_read
|
||||
__traceiter_android_vh_f2fs_improve_priority
|
||||
__tracepoint_android_vh_f2fs_improve_priority
|
||||
__traceiter_android_vh_f2fs_restore_priority
|
||||
__tracepoint_android_vh_f2fs_restore_priority
|
||||
__traceiter_android_vh_cma_alloc_retry
|
||||
__tracepoint_android_vh_cma_alloc_retry
|
||||
__tracepoint_android_vh_should_memcg_bypass
|
||||
__traceiter_android_vh_should_memcg_bypass
|
||||
__traceiter_android_rvh_ogki_vfree_bypass
|
||||
__traceiter_android_rvh_ogki_vmalloc_node_bypass
|
||||
__traceiter_android_vh_ogki_async_psi_bypass
|
||||
__traceiter_android_vh_ogki_f2fs_dsm
|
||||
__traceiter_android_vh_ogki_f2fs_dsm_get
|
||||
__tracepoint_android_vh_ogki_f2fs_create
|
||||
__traceiter_android_vh_ogki_f2fs_create
|
||||
__tracepoint_android_vh_ogki_f2fs_submit_write_page
|
||||
__traceiter_android_vh_ogki_f2fs_submit_write_page
|
||||
__traceiter_android_vh_ogki_check_vip_status
|
||||
__traceiter_android_vh_ogki_cma_alloc_retry
|
||||
__traceiter_android_vh_ogki_ufs_dsm
|
||||
__tracepoint_android_rvh_ogki_vfree_bypass
|
||||
__tracepoint_android_rvh_ogki_vmalloc_node_bypass
|
||||
__tracepoint_android_vh_ogki_async_psi_bypass
|
||||
__tracepoint_android_vh_ogki_f2fs_dsm
|
||||
__tracepoint_android_vh_ogki_f2fs_dsm_get
|
||||
__tracepoint_android_vh_ogki_check_vip_status
|
||||
__tracepoint_android_vh_ogki_cma_alloc_retry
|
||||
__tracepoint_android_vh_ogki_ufs_dsm
|
||||
__tracepoint_scsi_dispatch_cmd_start
|
||||
__traceiter_scsi_dispatch_cmd_start
|
||||
__traceiter_android_vh_ogki_tcp_srtt_estimator
|
||||
__tracepoint_android_vh_ogki_tcp_srtt_estimator
|
||||
__traceiter_android_vh_ogki_tcp_rcv_estab_fastpath
|
||||
__tracepoint_android_vh_ogki_tcp_rcv_estab_fastpath
|
||||
__traceiter_android_vh_ogki_tcp_rcv_estab_slowpath
|
||||
__tracepoint_android_vh_ogki_tcp_rcv_estab_slowpath
|
||||
__traceiter_android_vh_ogki_tcp_rcv_rtt_update
|
||||
__tracepoint_android_vh_ogki_tcp_rcv_rtt_update
|
||||
__traceiter_android_vh_ogki_tcp_retransmit_timer
|
||||
__tracepoint_android_vh_ogki_tcp_retransmit_timer
|
||||
__traceiter_android_vh_ogki_udp_unicast_rcv_skb
|
||||
__tracepoint_android_vh_ogki_udp_unicast_rcv_skb
|
||||
__traceiter_android_vh_ogki_udp6_unicast_rcv_skb
|
||||
__tracepoint_android_vh_ogki_udp6_unicast_rcv_skb
|
||||
__tracepoint_android_rvh_ogki_task_util
|
||||
__traceiter_android_rvh_ogki_task_util
|
||||
__tracepoint_android_rvh_ogki_uclamp_task_util
|
||||
__traceiter_android_rvh_ogki_uclamp_task_util
|
||||
__tracepoint_android_rvh_ogki_get_task_tags
|
||||
__traceiter_android_rvh_ogki_get_task_tags
|
||||
__tracepoint_android_rvh_ogki_get_task_rsum
|
||||
__traceiter_android_rvh_ogki_get_task_rsum
|
||||
__tracepoint_android_rvh_ogki_check_task_tags
|
||||
__traceiter_android_rvh_ogki_check_task_tags
|
||||
__tracepoint_android_vh_ogki_audit_log_cfi
|
||||
__tracepoint_android_rvh_ogki_audit_log_usercopy
|
||||
__tracepoint_android_rvh_ogki_audit_log_module_sign
|
||||
__tracepoint_android_vh_ogki_audit_log_setid
|
||||
__traceiter_android_vh_ogki_audit_log_cfi
|
||||
__traceiter_android_rvh_ogki_audit_log_usercopy
|
||||
__traceiter_android_rvh_ogki_audit_log_module_sign
|
||||
__traceiter_android_vh_ogki_audit_log_setid
|
||||
__traceiter_android_vh_ogki_get_log_usertype
|
||||
__tracepoint_android_vh_ogki_get_log_usertype
|
||||
__traceiter_android_rvh_ogki_hievent_create
|
||||
__tracepoint_android_rvh_ogki_hievent_create
|
||||
__traceiter_android_rvh_ogki_hievent_put_string
|
||||
__tracepoint_android_rvh_ogki_hievent_put_string
|
||||
__traceiter_android_rvh_ogki_hievent_put_integral
|
||||
__tracepoint_android_rvh_ogki_hievent_put_integral
|
||||
__traceiter_android_rvh_ogki_hievent_report
|
||||
__tracepoint_android_rvh_ogki_hievent_report
|
||||
__traceiter_android_rvh_ogki_hievent_destroy
|
||||
__tracepoint_android_rvh_ogki_hievent_destroy
|
||||
__traceiter_android_vh_ogki_hievent_to_jank
|
||||
__tracepoint_android_vh_ogki_hievent_to_jank
|
||||
__tracepoint_android_vh_ogki_set_wifi_state_connect
|
||||
__traceiter_android_vh_ogki_set_wifi_state_connect
|
||||
__tracepoint_android_vh_ogki_set_wifi_state_disconnect
|
||||
__traceiter_android_vh_ogki_set_wifi_state_disconnect
|
||||
__traceiter_android_vh_ogki_kmem_cache_create_usercopy
|
||||
__tracepoint_android_vh_ogki_kmem_cache_create_usercopy
|
||||
__traceiter_android_vh_wq_queue_work
|
||||
__traceiter_android_vh_wq_wake_idle_worker
|
||||
__tracepoint_android_vh_wq_queue_work
|
||||
__tracepoint_android_vh_wq_wake_idle_worker
|
||||
__traceiter_android_vh_mutex_unlock_slowpath_bf_wakeq
|
||||
__tracepoint_android_vh_mutex_unlock_slowpath_bf_wakeq
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,38 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
# required by drivers
|
||||
kunit_hooks
|
||||
kunit_running
|
||||
|
||||
# required by tests
|
||||
__kunit_abort
|
||||
__kunit_activate_static_stub
|
||||
kunit_add_action
|
||||
kunit_add_action_or_reset
|
||||
__kunit_add_resource
|
||||
kunit_assert_prologue
|
||||
kunit_binary_assert_format
|
||||
kunit_binary_ptr_assert_format
|
||||
kunit_binary_str_assert_format
|
||||
kunit_cleanup
|
||||
kunit_deactivate_static_stub
|
||||
kunit_destroy_resource
|
||||
__kunit_do_failed_assertion
|
||||
kunit_fail_assert_format
|
||||
kunit_init_test
|
||||
kunit_kfree
|
||||
kunit_kmalloc_array
|
||||
kunit_log_append
|
||||
kunit_mem_assert_format
|
||||
kunit_ptr_not_err_assert_format
|
||||
kunit_release_action
|
||||
kunit_remove_action
|
||||
kunit_remove_resource
|
||||
kunit_run_tests
|
||||
kunit_suite_has_succeeded
|
||||
kunit_suite_num_test_cases
|
||||
kunit_test_case_num
|
||||
__kunit_test_suites_exit
|
||||
__kunit_test_suites_init
|
||||
kunit_try_catch_run
|
||||
kunit_try_catch_throw
|
||||
kunit_unary_assert_format
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -1,181 +0,0 @@
|
|||
[abi_symbol_list]
|
||||
# commonly used symbols
|
||||
module_layout
|
||||
__put_task_struct
|
||||
|
||||
# required by ntfs3.ko
|
||||
balance_dirty_pages_ratelimited
|
||||
__bh_read
|
||||
bh_uptodate_or_lock
|
||||
bio_add_page
|
||||
bio_alloc_bioset
|
||||
bio_chain
|
||||
bio_put
|
||||
blkdev_issue_discard
|
||||
blkdev_issue_zeroout
|
||||
blk_finish_plug
|
||||
blk_start_plug
|
||||
__blockdev_direct_IO
|
||||
block_dirty_folio
|
||||
block_invalidate_folio
|
||||
block_truncate_page
|
||||
block_write_begin
|
||||
block_write_end
|
||||
__bread_gfp
|
||||
__brelse
|
||||
buffer_migrate_folio
|
||||
clean_bdev_aliases
|
||||
clear_inode
|
||||
clear_nlink
|
||||
copy_page_from_iter_atomic
|
||||
create_empty_buffers
|
||||
current_time
|
||||
current_umask
|
||||
dentry_path_raw
|
||||
d_find_alias
|
||||
d_instantiate
|
||||
discard_new_inode
|
||||
d_make_root
|
||||
d_obtain_alias
|
||||
down_write_trylock
|
||||
dput
|
||||
drop_nlink
|
||||
d_splice_alias
|
||||
errseq_set
|
||||
fault_in_iov_iter_readable
|
||||
fiemap_fill_next_extent
|
||||
fiemap_prep
|
||||
filemap_fdatawait_range
|
||||
filemap_fdatawrite
|
||||
filemap_fdatawrite_range
|
||||
__filemap_set_wb_err
|
||||
filemap_splice_read
|
||||
filemap_write_and_wait_range
|
||||
file_modified
|
||||
file_remove_privs
|
||||
file_update_time
|
||||
finish_no_open
|
||||
finish_open
|
||||
flush_dcache_page
|
||||
__folio_lock
|
||||
__folio_put
|
||||
folio_set_bh
|
||||
folio_unlock
|
||||
fs_bio_set
|
||||
fscrypt_file_open
|
||||
fs_param_is_string
|
||||
fs_param_is_u32
|
||||
__fs_parse
|
||||
fs_umode_to_dtype
|
||||
generic_block_bmap
|
||||
generic_fh_to_dentry
|
||||
generic_fh_to_parent
|
||||
generic_file_fsync
|
||||
generic_file_llseek
|
||||
generic_file_mmap
|
||||
generic_file_open
|
||||
generic_file_read_iter
|
||||
__generic_file_write_iter
|
||||
generic_fillattr
|
||||
generic_read_dir
|
||||
generic_write_checks
|
||||
generic_write_end
|
||||
__getblk_gfp
|
||||
get_fs_type
|
||||
get_inode_acl
|
||||
get_tree_bdev
|
||||
grab_cache_page_write_begin
|
||||
hex_asc
|
||||
iget5_locked
|
||||
iget_failed
|
||||
ihold
|
||||
ilookup
|
||||
inc_nlink
|
||||
__init_rwsem
|
||||
init_special_inode
|
||||
init_user_ns
|
||||
inode_dio_wait
|
||||
inode_get_bytes
|
||||
inode_init_once
|
||||
inode_init_owner
|
||||
inode_newsize_ok
|
||||
inode_nohighmem
|
||||
inode_set_bytes
|
||||
inode_set_ctime_current
|
||||
insert_inode_locked
|
||||
invalidate_bdev
|
||||
invalidate_inode_buffers
|
||||
iov_iter_zero
|
||||
iput
|
||||
is_bad_inode
|
||||
iterate_supers_type
|
||||
iter_file_splice_write
|
||||
kfree_link
|
||||
kill_block_super
|
||||
kmem_cache_alloc_lru
|
||||
load_nls
|
||||
load_nls_default
|
||||
__lock_buffer
|
||||
lockref_get
|
||||
logfc
|
||||
make_bad_inode
|
||||
mark_buffer_dirty
|
||||
__mark_inode_dirty
|
||||
mpage_readahead
|
||||
mpage_read_folio
|
||||
mpage_writepages
|
||||
names_cachep
|
||||
new_inode
|
||||
overflowgid
|
||||
overflowuid
|
||||
pagecache_get_page
|
||||
page_pinner_inited
|
||||
__page_pinner_put_page
|
||||
posix_acl_chmod
|
||||
posix_acl_create
|
||||
posix_acl_from_xattr
|
||||
posix_acl_to_xattr
|
||||
posix_acl_update_mode
|
||||
proc_create_data
|
||||
proc_mkdir
|
||||
rb_first
|
||||
rb_last
|
||||
rb_prev
|
||||
read_cache_page
|
||||
register_filesystem
|
||||
remove_proc_entry
|
||||
sb_set_blocksize
|
||||
setattr_copy
|
||||
setattr_prepare
|
||||
set_cached_acl
|
||||
set_nlink
|
||||
set_page_dirty
|
||||
simple_rename_timestamp
|
||||
submit_bio
|
||||
submit_bio_wait
|
||||
sync_blockdev
|
||||
sync_blockdev_nowait
|
||||
sync_dirty_buffer
|
||||
sync_filesystem
|
||||
sync_inode_metadata
|
||||
sync_mapping_buffers
|
||||
truncate_inode_pages_final
|
||||
truncate_pagecache
|
||||
truncate_setsize
|
||||
unload_nls
|
||||
unlock_buffer
|
||||
unlock_new_inode
|
||||
unlock_page
|
||||
unregister_filesystem
|
||||
utf16s_to_utf8s
|
||||
utf8_to_utf32
|
||||
vfs_fsync_range
|
||||
vm_zone_stat
|
||||
__wait_on_buffer
|
||||
write_cache_pages
|
||||
write_inode_now
|
||||
|
||||
# required by thermal_core_skip_irq.ko
|
||||
__traceiter_android_vh_thermal_pm_notify_suspend
|
||||
__tracepoint_android_vh_thermal_pm_notify_suspend
|
||||
tracepoint_probe_register
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user