forked from zephyrproject-rtos/zephyr
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathKconfig.vm
185 lines (150 loc) · 6.66 KB
/
Kconfig.vm
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
# Copyright (c) 2021 Intel Corporation
#
# SPDX-License-Identifier: Apache-2.0
menu "Virtual Memory Support"
config KERNEL_VM_SUPPORT
bool
help
Hidden option to enable virtual memory Kconfigs.
if KERNEL_VM_SUPPORT
DT_CHOSEN_Z_SRAM := zephyr,sram
config KERNEL_VM_BASE
hex "Virtual address space base address"
default $(dt_chosen_reg_addr_hex,$(DT_CHOSEN_Z_SRAM))
help
Define the base of the kernel's address space.
By default, this is the same as the DT_CHOSEN_Z_SRAM physical base SRAM
address from DTS, in which case RAM will be identity-mapped. Some
architectures may require RAM to be mapped in this way; they may have
just one RAM region and doing this makes linking much simpler, as
at least when the kernel boots all virtual RAM addresses are the same
as their physical address (demand paging at runtime may later modify
this for non-pinned page frames).
Otherwise, if RAM isn't identity-mapped:
1. It is the architecture's responsibility to transition the
instruction pointer to virtual addresses at early boot before
entering the kernel at z_cstart().
2. The underlying architecture may impose constraints on the bounds of
the kernel's address space, such as not overlapping physical RAM
regions if RAM is not identity-mapped, or the virtual and physical
base addresses being aligned to some common value (which allows
double-linking of paging structures to make the instruction pointer
transition simpler).
Zephyr does not implement a split address space and if multiple
page tables are in use, they all have the same virtual-to-physical
mappings (with potentially different permissions).
config KERNEL_VM_OFFSET
hex "Kernel offset within address space"
default 0
help
Offset that the kernel image begins within its address space,
if this is not the same offset from the beginning of RAM.
Some care may need to be taken in selecting this value. In certain
build-time cases, or when a physical address cannot be looked up
in page tables, the equation:
virt = phys + ((KERNEL_VM_BASE + KERNEL_VM_OFFSET) -
(SRAM_BASE_ADDRESS + SRAM_OFFSET))
Will be used to convert between physical and virtual addresses for
memory that is mapped at boot.
This uncommon and is only necessary if the beginning of VM and
physical memory have dissimilar alignment.
config KERNEL_VM_SIZE
hex "Size of kernel address space in bytes"
default 0x800000
help
Size of the kernel's address space. Constraining this helps control
how much total memory can be used for page tables.
The difference between KERNEL_VM_BASE and KERNEL_VM_SIZE indicates the
size of the virtual region for runtime memory mappings. This is needed
for mapping driver MMIO regions, as well as special RAM mapping use-cases
such as VSDO pages, memory mapped thread stacks, and anonymous memory
mappings. The kernel itself will be mapped in here as well at boot.
Systems with very large amounts of memory (such as 512M or more)
will want to use a 64-bit build of Zephyr, there are no plans to
implement a notion of "high" memory in Zephyr to work around physical
RAM size larger than the defined bounds of the virtual address space.
endif # KERNEL_VM_SUPPORT
menuconfig MMU
bool "Enable MMU features"
depends on CPU_HAS_MMU
select KERNEL_VM_SUPPORT
help
This option is enabled when the CPU's memory management unit is active
and the arch_mem_map() API is available.
if MMU
config MMU_PAGE_SIZE
hex "Size of smallest granularity MMU page"
default 0x1000
help
Size of memory pages. Varies per MMU but 4K is common. For MMUs that
support multiple page sizes, put the smallest one here.
menuconfig DEMAND_PAGING
bool "Enable demand paging [EXPERIMENTAL]"
depends on ARCH_HAS_DEMAND_PAGING
help
Enable demand paging. Requires architecture support in how the kernel
is linked and the implementation of an eviction algorithm and a
backing store for evicted pages.
if DEMAND_PAGING
config DEMAND_PAGING_ALLOW_IRQ
bool "Allow interrupts during page-ins/outs"
help
Allow interrupts to be serviced while pages are being evicted or
retrieved from the backing store. This is much better for system
latency, but any code running in interrupt context that page faults
will cause a kernel panic. Such code must work with exclusively pinned
code and data pages.
The scheduler is still disabled during this operation.
If this option is disabled, the page fault servicing logic
runs with interrupts disabled for the entire operation. However,
ISRs may also page fault.
config DEMAND_PAGING_PAGE_FRAMES_RESERVE
int "Number of page frames reserved for paging"
default 32 if !LINKER_GENERIC_SECTIONS_PRESENT_AT_BOOT
default 0
help
This sets the number of page frames that will be reserved for
paging that do not count towards free memory. This is to
ensure that there are some page frames available for paging
code and data. Otherwise, it would be possible to exhaust
all page frames via anonymous memory mappings.
config DEMAND_PAGING_STATS
bool "Gather Demand Paging Statistics"
help
This enables gathering various statistics related to demand paging,
e.g. number of pagefaults. This is useful for tuning eviction
algorithms and optimizing backing store.
Should say N in production system as this is not without cost.
config DEMAND_PAGING_STATS_USING_TIMING_FUNCTIONS
bool "Use Timing Functions to Gather Demand Paging Statistics"
select TIMING_FUNCTIONS_NEED_AT_BOOT
help
Use timing functions to gather various demand paging statistics.
config DEMAND_PAGING_THREAD_STATS
bool "Gather per Thread Demand Paging Statistics"
depends on DEMAND_PAGING_STATS
help
This enables gathering per thread statistics related to demand
paging.
Should say N in production system as this is not without cost.
config DEMAND_PAGING_TIMING_HISTOGRAM
bool "Gather Demand Paging Execution Timing Histogram"
depends on DEMAND_PAGING_STATS
help
This gathers the histogram of execution time on page eviction
selection, and backing store page in and page out.
Should say N in production system as this is not without cost.
config DEMAND_PAGING_TIMING_HISTOGRAM_NUM_BINS
int "Number of bins (buckets) in Demand Paging Timing Histogrm"
depends on DEMAND_PAGING_TIMING_HISTOGRAM
default 10
help
Defines the number of bins (buckets) in the histogram used for
gathering execution timing information for demand paging.
This requires k_mem_paging_eviction_histogram_bounds[] and
k_mem_paging_backing_store_histogram_bounds[] to define
the upper bounds for each bin. See kernel/statistics.c for
information.
endif # DEMAND_PAGING
endif # MMU
endmenu # Virtual Memory Support