diff --git a/arch/Kconfig b/arch/Kconfig index 1c907c9ec1f..f3cdf9f12c6 100644 --- a/arch/Kconfig +++ b/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 diff --git a/kernel/Kconfig b/kernel/Kconfig index 3fbf1e8497f..6e040d045c1 100644 --- a/kernel/Kconfig +++ b/kernel/Kconfig @@ -919,3 +919,5 @@ config THREAD_LOCAL_STORAGE This option enables thread local storage (TLS) support in kernel. endmenu + +rsource "Kconfig.vm" diff --git a/kernel/Kconfig.vm b/kernel/Kconfig.vm new file mode 100644 index 00000000000..3eacba0822d --- /dev/null +++ b/kernel/Kconfig.vm @@ -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