kernel: move CONFIG_MMU into kernel Kconfig
This moves CONFIG_MMU and its children from arch/Kconfig into kernel/Kconfig. These are used to enable kernel support of MMU so they should be under kernel/. Signed-off-by: Daniel Leung <daniel.leung@intel.com>
This commit is contained in:
Daniel Leung
Anas Nashif
parent
88cfd3343d
commit
2e5501a3fe
166
arch/Kconfig
166
arch/Kconfig
@ -596,172 +596,6 @@ config ARCH_MAPS_ALL_RAM
|
||||
this mapping at all; non-kernel pages will be considered free (unless marked
|
||||
as reserved) and Z_PAGE_FRAME_MAPPED will not be set.
|
||||
|
||||
menuconfig MMU
|
||||
bool "Enable MMU features"
|
||||
depends on CPU_HAS_MMU
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
menuconfig MPU
|
||||
bool "Enable MPU features"
|
||||
depends on CPU_HAS_MPU
|
||||
|
||||
@ -919,3 +919,5 @@ config THREAD_LOCAL_STORAGE
|
||||
This option enables thread local storage (TLS) support in kernel.
|
||||
|
||||
endmenu
|
||||
|
||||
rsource "Kconfig.vm"
|
||||
|
||||
175
kernel/Kconfig.vm
Normal file
175
kernel/Kconfig.vm
Normal file
@ -0,0 +1,175 @@
|
||||
# Copyright (c) 2021 Intel Corporation
|
||||
#
|
||||
# SPDX-License-Identifier: Apache-2.0
|
||||
|
||||
menu "Virtual Memory Support"
|
||||
|
||||
menuconfig MMU
|
||||
bool "Enable MMU features"
|
||||
depends on CPU_HAS_MMU
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
Loading…
Reference in New Issue
Block a user