2019-05-19 12:07:45 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0-only
|
2017-07-11 01:08:08 +00:00
|
|
|
#
|
|
|
|
# For a description of the syntax of this configuration file,
|
2019-06-12 17:52:48 +00:00
|
|
|
# see Documentation/kbuild/kconfig-language.rst.
|
2017-07-11 01:08:08 +00:00
|
|
|
#
|
|
|
|
|
2018-04-27 06:38:23 +00:00
|
|
|
config 64BIT
|
|
|
|
bool
|
|
|
|
|
|
|
|
config 32BIT
|
|
|
|
bool
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
config RISCV
|
|
|
|
def_bool y
|
2023-05-15 05:49:13 +00:00
|
|
|
select ACPI_GENERIC_GSI if ACPI
|
2024-08-12 00:59:21 +00:00
|
|
|
select ACPI_MCFG if (ACPI && PCI)
|
2024-06-17 13:14:25 +00:00
|
|
|
select ACPI_PPTT if ACPI
|
2023-05-15 05:49:13 +00:00
|
|
|
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
|
2024-05-02 07:37:51 +00:00
|
|
|
select ACPI_SPCR_TABLE if ACPI
|
2023-04-01 09:15:31 +00:00
|
|
|
select ARCH_DMA_DEFAULT_COHERENT
|
2021-08-10 13:51:05 +00:00
|
|
|
select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
|
2024-06-05 11:40:51 +00:00
|
|
|
select ARCH_ENABLE_MEMORY_HOTPLUG if SPARSEMEM_VMEMMAP
|
|
|
|
select ARCH_ENABLE_MEMORY_HOTREMOVE if MEMORY_HOTPLUG
|
2021-09-27 03:03:25 +00:00
|
|
|
select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
|
2022-12-19 17:28:37 +00:00
|
|
|
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
|
2019-06-13 07:09:03 +00:00
|
|
|
select ARCH_HAS_BINFMT_FLAT
|
2022-02-24 06:04:11 +00:00
|
|
|
select ARCH_HAS_CURRENT_STACK_POINTER
|
2020-06-04 20:55:14 +00:00
|
|
|
select ARCH_HAS_DEBUG_VIRTUAL if MMU
|
2022-12-19 17:28:37 +00:00
|
|
|
select ARCH_HAS_DEBUG_VM_PGTABLE
|
2020-06-03 23:03:55 +00:00
|
|
|
select ARCH_HAS_DEBUG_WX
|
riscv: select ARCH_HAS_FAST_MULTIPLIER
Currently, riscv linux requires at least IMA, so all platforms have a
multiplier. And I assume the 'mul' efficiency is comparable or better
than a sequence of five or so register-dependent arithmetic
instructions. Select ARCH_HAS_FAST_MULTIPLIER to get slightly nicer
codegen. Refer to commit f9b4192923fa ("[PATCH] bitops: hweight()
speedup") for more details.
In a simple benchmark test calling hweight64() in a loop, it got:
about 14% performance improvement on JH7110, tested on Milkv Mars.
about 23% performance improvement on TH1520 and SG2042, tested on
Sipeed LPI4A and SG2042 platform.
a slight performance drop on CV1800B, tested on milkv duo. Among all
riscv platforms in my hands, this is the only one which sees a slight
performance drop. It means the 'mul' isn't quick enough. However, the
situation exists on x86 too, for example, P4 doesn't have fast
integer multiplies as said in the above commit, x86 also selects
ARCH_HAS_FAST_MULTIPLIER. So let's select ARCH_HAS_FAST_MULTIPLIER
which can benefit almost riscv platforms.
Samuel also provided some performance numbers:
On Unmatched: 20% speedup for __sw_hweight32 and 30% speedup for
__sw_hweight64.
On D1: 8% speedup for __sw_hweight32 and 8% slowdown for
__sw_hweight64.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Samuel Holland <samuel.holland@sifive.com>
Tested-by: Samuel Holland <samuel.holland@sifive.com>
Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Link: https://lore.kernel.org/r/20240325105823.1483-1-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-03-25 10:58:23 +00:00
|
|
|
select ARCH_HAS_FAST_MULTIPLIER
|
2021-02-25 07:03:03 +00:00
|
|
|
select ARCH_HAS_FORTIFY_SOURCE
|
2020-06-04 20:55:14 +00:00
|
|
|
select ARCH_HAS_GCOV_PROFILE_ALL
|
|
|
|
select ARCH_HAS_GIGANTIC_PAGE
|
2020-06-26 12:40:56 +00:00
|
|
|
select ARCH_HAS_KCOV
|
2024-03-29 07:18:26 +00:00
|
|
|
select ARCH_HAS_KERNEL_FPU_SUPPORT if 64BIT && FPU
|
2024-01-31 14:49:33 +00:00
|
|
|
select ARCH_HAS_MEMBARRIER_CALLBACKS
|
2024-01-31 14:49:36 +00:00
|
|
|
select ARCH_HAS_MEMBARRIER_SYNC_CORE
|
2020-06-04 20:55:14 +00:00
|
|
|
select ARCH_HAS_MMIOWB
|
2023-05-04 07:29:10 +00:00
|
|
|
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
|
2022-11-14 09:05:35 +00:00
|
|
|
select ARCH_HAS_PMEM_API
|
2024-10-21 15:08:42 +00:00
|
|
|
select ARCH_HAS_PREEMPT_LAZY
|
2024-01-31 14:49:36 +00:00
|
|
|
select ARCH_HAS_PREPARE_SYNC_CORE_CMD
|
2024-06-05 11:40:53 +00:00
|
|
|
select ARCH_HAS_PTE_DEVMAP if 64BIT && MMU
|
2020-06-04 20:55:14 +00:00
|
|
|
select ARCH_HAS_PTE_SPECIAL
|
2021-07-08 01:07:54 +00:00
|
|
|
select ARCH_HAS_SET_DIRECT_MAP if MMU
|
|
|
|
select ARCH_HAS_SET_MEMORY if MMU
|
2021-04-13 06:35:14 +00:00
|
|
|
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
|
|
|
|
select ARCH_HAS_STRICT_MODULE_RWX if MMU && !XIP_KERNEL
|
2024-01-31 14:49:36 +00:00
|
|
|
select ARCH_HAS_SYNC_CORE_BEFORE_USERMODE
|
2023-07-10 18:35:46 +00:00
|
|
|
select ARCH_HAS_SYSCALL_WRAPPER
|
2021-03-07 02:24:46 +00:00
|
|
|
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
|
2024-01-28 18:45:29 +00:00
|
|
|
select ARCH_HAS_UBSAN
|
2024-10-10 07:01:30 +00:00
|
|
|
select ARCH_HAS_VDSO_TIME_DATA
|
2023-10-18 12:40:04 +00:00
|
|
|
select ARCH_KEEP_MEMBLOCK if ACPI
|
2024-06-05 11:40:51 +00:00
|
|
|
select ARCH_MHP_MEMMAP_ON_MEMORY_ENABLE if 64BIT && MMU
|
2020-06-23 05:36:59 +00:00
|
|
|
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
|
|
|
|
select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
|
2021-08-04 16:29:08 +00:00
|
|
|
select ARCH_STACKWALK
|
|
|
|
select ARCH_SUPPORTS_ATOMIC_RMW
|
2023-07-10 18:35:51 +00:00
|
|
|
select ARCH_SUPPORTS_CFI_CLANG
|
2021-08-04 16:29:08 +00:00
|
|
|
select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
|
2021-05-05 01:38:13 +00:00
|
|
|
select ARCH_SUPPORTS_HUGETLBFS if MMU
|
2023-10-17 22:21:04 +00:00
|
|
|
# LLD >= 14: https://github.com/llvm/llvm-project/issues/50505
|
|
|
|
select ARCH_SUPPORTS_LTO_CLANG if LLD_VERSION >= 140000
|
|
|
|
select ARCH_SUPPORTS_LTO_CLANG_THIN if LLD_VERSION >= 140000
|
2022-06-24 08:52:36 +00:00
|
|
|
select ARCH_SUPPORTS_PAGE_TABLE_CHECK if MMU
|
2023-05-23 16:59:42 +00:00
|
|
|
select ARCH_SUPPORTS_PER_VMA_LOCK if MMU
|
2024-09-06 10:59:06 +00:00
|
|
|
select ARCH_SUPPORTS_RT
|
2023-09-27 22:48:02 +00:00
|
|
|
select ARCH_SUPPORTS_SHADOW_CALL_STACK if HAVE_SHADOW_CALL_STACK
|
2024-03-25 11:10:37 +00:00
|
|
|
select ARCH_USE_CMPXCHG_LOCKREF if 64BIT
|
2021-05-07 09:47:15 +00:00
|
|
|
select ARCH_USE_MEMTEST
|
2022-03-16 23:11:33 +00:00
|
|
|
select ARCH_USE_QUEUED_RWLOCKS
|
2024-07-09 16:05:22 +00:00
|
|
|
select ARCH_USE_SYM_ANNOTATIONS
|
2023-07-10 18:35:49 +00:00
|
|
|
select ARCH_USES_CFI_TRAPS if CFI_CLANG
|
2024-03-27 04:49:47 +00:00
|
|
|
select ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH if MMU
|
2020-06-04 20:55:14 +00:00
|
|
|
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
|
2017-07-11 01:08:08 +00:00
|
|
|
select ARCH_WANT_FRAME_POINTERS
|
2023-02-09 13:16:46 +00:00
|
|
|
select ARCH_WANT_GENERAL_HUGETLB if !RISCV_ISA_SVNAPOT
|
2020-06-04 20:55:14 +00:00
|
|
|
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
|
2023-01-19 15:54:17 +00:00
|
|
|
select ARCH_WANT_LD_ORPHAN_WARN if !XIP_KERNEL
|
2024-06-05 11:40:54 +00:00
|
|
|
select ARCH_WANT_OPTIMIZE_DAX_VMEMMAP
|
2023-07-24 19:07:53 +00:00
|
|
|
select ARCH_WANT_OPTIMIZE_HUGETLB_VMEMMAP
|
2023-11-23 14:22:23 +00:00
|
|
|
select ARCH_WANTS_NO_INSTR
|
2022-08-29 14:57:42 +00:00
|
|
|
select ARCH_WANTS_THP_SWAP if HAVE_ARCH_TRANSPARENT_HUGEPAGE
|
2021-04-17 01:10:09 +00:00
|
|
|
select BINFMT_FLAT_NO_DATA_START_OFFSET if !MMU
|
2021-08-26 14:10:29 +00:00
|
|
|
select BUILDTIME_TABLE_SORT if MMU
|
2024-02-27 00:34:49 +00:00
|
|
|
select CLINT_TIMER if RISCV_M_MODE
|
2022-12-19 17:28:37 +00:00
|
|
|
select CLONE_BACKWARDS
|
2017-07-11 01:08:08 +00:00
|
|
|
select COMMON_CLK
|
2023-12-06 11:08:09 +00:00
|
|
|
select CPU_PM if CPU_IDLE || HIBERNATION || SUSPEND
|
2020-06-04 20:55:14 +00:00
|
|
|
select EDAC_SUPPORT
|
2023-08-23 08:28:45 +00:00
|
|
|
select FRAME_POINTER if PERF_EVENTS || (FUNCTION_TRACER && !DYNAMIC_FTRACE)
|
2023-11-30 12:15:28 +00:00
|
|
|
select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY if DYNAMIC_FTRACE
|
2022-07-15 17:51:56 +00:00
|
|
|
select GENERIC_ARCH_TOPOLOGY
|
2020-06-04 20:55:14 +00:00
|
|
|
select GENERIC_ATOMIC64 if !64BIT
|
2021-03-07 02:24:46 +00:00
|
|
|
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
|
2023-11-21 13:45:32 +00:00
|
|
|
select GENERIC_CPU_DEVICES
|
2024-07-03 02:27:32 +00:00
|
|
|
select GENERIC_CPU_VULNERABILITIES
|
2020-09-17 22:37:11 +00:00
|
|
|
select GENERIC_EARLY_IOREMAP
|
2023-02-22 03:30:18 +00:00
|
|
|
select GENERIC_ENTRY
|
2020-06-09 14:14:48 +00:00
|
|
|
select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
|
2021-07-08 01:59:48 +00:00
|
|
|
select GENERIC_IDLE_POLL_SETUP
|
2021-09-08 02:55:58 +00:00
|
|
|
select GENERIC_IOREMAP if MMU
|
2023-03-28 03:52:19 +00:00
|
|
|
select GENERIC_IRQ_IPI if SMP
|
|
|
|
select GENERIC_IRQ_IPI_MUX if SMP
|
2020-06-04 20:55:14 +00:00
|
|
|
select GENERIC_IRQ_MULTI_HANDLER
|
2017-07-11 01:08:08 +00:00
|
|
|
select GENERIC_IRQ_SHOW
|
2021-07-08 01:59:49 +00:00
|
|
|
select GENERIC_IRQ_SHOW_LEVEL
|
2020-07-09 18:51:17 +00:00
|
|
|
select GENERIC_LIB_DEVMEM_IS_ALLOWED
|
2017-07-11 01:08:08 +00:00
|
|
|
select GENERIC_PCI_IOMAP
|
2020-06-04 20:55:14 +00:00
|
|
|
select GENERIC_PTDUMP if MMU
|
2018-12-04 10:29:51 +00:00
|
|
|
select GENERIC_SCHED_CLOCK
|
2020-06-04 20:55:14 +00:00
|
|
|
select GENERIC_SMP_IDLE_THREAD
|
2020-06-09 14:14:48 +00:00
|
|
|
select GENERIC_TIME_VSYSCALL if MMU && 64BIT
|
2021-09-01 03:20:25 +00:00
|
|
|
select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO
|
2022-07-29 11:11:17 +00:00
|
|
|
select HARDIRQS_SW_RESEND
|
2023-03-23 16:33:52 +00:00
|
|
|
select HAS_IOPORT if MMU
|
2018-10-29 10:48:53 +00:00
|
|
|
select HAVE_ARCH_AUDITSYSCALL
|
2022-10-12 12:00:38 +00:00
|
|
|
select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
|
2024-05-26 11:01:04 +00:00
|
|
|
select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT
|
2021-05-10 16:28:38 +00:00
|
|
|
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
|
|
|
|
select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
|
2020-06-04 20:55:14 +00:00
|
|
|
select HAVE_ARCH_KASAN if MMU && 64BIT
|
2021-01-16 05:58:35 +00:00
|
|
|
select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
|
2021-06-15 03:07:34 +00:00
|
|
|
select HAVE_ARCH_KFENCE if MMU && 64BIT
|
2021-05-10 16:28:38 +00:00
|
|
|
select HAVE_ARCH_KGDB if !XIP_KERNEL
|
2020-06-04 20:55:14 +00:00
|
|
|
select HAVE_ARCH_KGDB_QXFER_PKT
|
|
|
|
select HAVE_ARCH_MMAP_RND_BITS if MMU
|
2022-04-05 07:13:14 +00:00
|
|
|
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
|
2023-11-09 13:37:51 +00:00
|
|
|
select HAVE_ARCH_RANDOMIZE_KSTACK_OFFSET
|
2019-10-05 00:12:22 +00:00
|
|
|
select HAVE_ARCH_SECCOMP_FILTER
|
2024-06-23 23:53:16 +00:00
|
|
|
select HAVE_ARCH_STACKLEAK
|
2022-12-19 17:28:37 +00:00
|
|
|
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
|
2020-06-04 20:55:14 +00:00
|
|
|
select HAVE_ARCH_TRACEHOOK
|
2021-07-09 17:36:29 +00:00
|
|
|
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU
|
2023-06-24 06:03:20 +00:00
|
|
|
select HAVE_ARCH_USERFAULTFD_MINOR if 64BIT && USERFAULTFD
|
riscv: add VMAP_STACK overflow detection
This patch adds stack overflow detection to riscv, usable when
CONFIG_VMAP_STACK=y.
Overflow is detected in kernel exception entry(kernel/entry.S), if the
kernel stack is overflow and been detected, the overflow handler is
invoked on a per-cpu overflow stack. This approach preserves GPRs and
the original exception information.
The overflow detect is performed before any attempt is made to access
the stack and the principle of stack overflow detection: kernel stacks
are aligned to double their size, enabling overflow to be detected with
a single bit test. For example, a 16K stack is aligned to 32K, ensuring
that bit 14 of the SP must be zero. On an overflow (or underflow), this
bit is flipped. Thus, overflow (of less than the size of the stack) can
be detected by testing whether this bit is set.
This gives us a useful error message on stack overflow, as can be
trigger with the LKDTM overflow test:
[ 388.053267] lkdtm: Performing direct entry EXHAUST_STACK
[ 388.053663] lkdtm: Calling function with 1024 frame size to depth 32 ...
[ 388.054016] lkdtm: loop 32/32 ...
[ 388.054186] lkdtm: loop 31/32 ...
[ 388.054491] lkdtm: loop 30/32 ...
[ 388.054672] lkdtm: loop 29/32 ...
[ 388.054859] lkdtm: loop 28/32 ...
[ 388.055010] lkdtm: loop 27/32 ...
[ 388.055163] lkdtm: loop 26/32 ...
[ 388.055309] lkdtm: loop 25/32 ...
[ 388.055481] lkdtm: loop 24/32 ...
[ 388.055653] lkdtm: loop 23/32 ...
[ 388.055837] lkdtm: loop 22/32 ...
[ 388.056015] lkdtm: loop 21/32 ...
[ 388.056188] lkdtm: loop 20/32 ...
[ 388.058145] Insufficient stack space to handle exception!
[ 388.058153] Task stack: [0xffffffd014260000..0xffffffd014264000]
[ 388.058160] Overflow stack: [0xffffffe1f8d2c220..0xffffffe1f8d2d220]
[ 388.058168] CPU: 0 PID: 89 Comm: bash Not tainted 5.12.0-rc8-dirty #90
[ 388.058175] Hardware name: riscv-virtio,qemu (DT)
[ 388.058187] epc : number+0x32/0x2c0
[ 388.058247] ra : vsnprintf+0x2ae/0x3f0
[ 388.058255] epc : ffffffe0002d38f6 ra : ffffffe0002d814e sp : ffffffd01425ffc0
[ 388.058263] gp : ffffffe0012e4010 tp : ffffffe08014da00 t0 : ffffffd0142606e8
[ 388.058271] t1 : 0000000000000000 t2 : 0000000000000000 s0 : ffffffd014260070
[ 388.058303] s1 : ffffffd014260158 a0 : ffffffd01426015e a1 : ffffffd014260158
[ 388.058311] a2 : 0000000000000013 a3 : ffff0a01ffffff10 a4 : ffffffe000c398e0
[ 388.058319] a5 : 511b02ec65f3e300 a6 : 0000000000a1749a a7 : 0000000000000000
[ 388.058327] s2 : ffffffff000000ff s3 : 00000000ffff0a01 s4 : ffffffe0012e50a8
[ 388.058335] s5 : 0000000000ffff0a s6 : ffffffe0012e50a8 s7 : ffffffe000da1cc0
[ 388.058343] s8 : ffffffffffffffff s9 : ffffffd0142602b0 s10: ffffffd0142602a8
[ 388.058351] s11: ffffffd01426015e t3 : 00000000000f0000 t4 : ffffffffffffffff
[ 388.058359] t5 : 000000000000002f t6 : ffffffd014260158
[ 388.058366] status: 0000000000000100 badaddr: ffffffd01425fff8 cause: 000000000000000f
[ 388.058374] Kernel panic - not syncing: Kernel stack overflow
[ 388.058381] CPU: 0 PID: 89 Comm: bash Not tainted 5.12.0-rc8-dirty #90
[ 388.058387] Hardware name: riscv-virtio,qemu (DT)
[ 388.058393] Call Trace:
[ 388.058400] [<ffffffe000004944>] walk_stackframe+0x0/0xce
[ 388.058406] [<ffffffe0006f0b28>] dump_backtrace+0x38/0x46
[ 388.058412] [<ffffffe0006f0b46>] show_stack+0x10/0x18
[ 388.058418] [<ffffffe0006f3690>] dump_stack+0x74/0x8e
[ 388.058424] [<ffffffe0006f0d52>] panic+0xfc/0x2b2
[ 388.058430] [<ffffffe0006f0acc>] print_trace_address+0x0/0x24
[ 388.058436] [<ffffffe0002d814e>] vsnprintf+0x2ae/0x3f0
[ 388.058956] SMP: stopping secondary CPUs
Signed-off-by: Tong Tiangen <tongtiangen@huawei.com>
Reviewed-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2021-06-21 03:28:55 +00:00
|
|
|
select HAVE_ARCH_VMAP_STACK if MMU && 64BIT
|
2019-08-19 05:54:20 +00:00
|
|
|
select HAVE_ASM_MODVERSIONS
|
2022-06-08 14:40:24 +00:00
|
|
|
select HAVE_CONTEXT_TRACKING_USER
|
2020-06-27 10:50:50 +00:00
|
|
|
select HAVE_DEBUG_KMEMLEAK
|
2019-10-28 12:10:41 +00:00
|
|
|
select HAVE_DMA_CONTIGUOUS if MMU
|
2023-05-23 16:54:59 +00:00
|
|
|
select HAVE_DYNAMIC_FTRACE if !XIP_KERNEL && MMU && (CLANG_SUPPORTS_DYNAMIC_FTRACE || GCC_SUPPORTS_DYNAMIC_FTRACE)
|
2023-11-30 12:15:30 +00:00
|
|
|
select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
|
2024-04-05 14:24:53 +00:00
|
|
|
select HAVE_DYNAMIC_FTRACE_WITH_ARGS if HAVE_DYNAMIC_FTRACE
|
2023-05-23 16:54:59 +00:00
|
|
|
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
|
|
|
|
select HAVE_FUNCTION_GRAPH_TRACER
|
2023-07-07 17:07:19 +00:00
|
|
|
select HAVE_FUNCTION_GRAPH_RETVAL if HAVE_FUNCTION_GRAPH_TRACER
|
2023-05-23 16:54:59 +00:00
|
|
|
select HAVE_FUNCTION_TRACER if !XIP_KERNEL && !PREEMPTION
|
2020-06-04 20:55:14 +00:00
|
|
|
select HAVE_EBPF_JIT if MMU
|
2024-04-02 12:55:15 +00:00
|
|
|
select HAVE_GUP_FAST if MMU
|
2022-12-19 17:28:37 +00:00
|
|
|
select HAVE_FUNCTION_ARG_ACCESS_API
|
2020-12-17 16:01:45 +00:00
|
|
|
select HAVE_FUNCTION_ERROR_INJECTION
|
2020-06-26 12:40:56 +00:00
|
|
|
select HAVE_GCC_PLUGINS
|
2020-06-09 14:14:48 +00:00
|
|
|
select HAVE_GENERIC_VDSO if MMU && 64BIT
|
2020-10-28 04:28:42 +00:00
|
|
|
select HAVE_IRQ_TIME_ACCOUNTING
|
2024-05-04 19:34:38 +00:00
|
|
|
select HAVE_KERNEL_BZIP2 if !XIP_KERNEL && !EFI_ZBOOT
|
|
|
|
select HAVE_KERNEL_GZIP if !XIP_KERNEL && !EFI_ZBOOT
|
|
|
|
select HAVE_KERNEL_LZ4 if !XIP_KERNEL && !EFI_ZBOOT
|
|
|
|
select HAVE_KERNEL_LZMA if !XIP_KERNEL && !EFI_ZBOOT
|
|
|
|
select HAVE_KERNEL_LZO if !XIP_KERNEL && !EFI_ZBOOT
|
|
|
|
select HAVE_KERNEL_UNCOMPRESSED if !XIP_KERNEL && !EFI_ZBOOT
|
|
|
|
select HAVE_KERNEL_ZSTD if !XIP_KERNEL && !EFI_ZBOOT
|
2024-07-21 13:36:31 +00:00
|
|
|
select HAVE_KERNEL_XZ if !XIP_KERNEL && !EFI_ZBOOT
|
2021-05-10 16:28:38 +00:00
|
|
|
select HAVE_KPROBES if !XIP_KERNEL
|
|
|
|
select HAVE_KRETPROBES if !XIP_KERNEL
|
2023-06-23 17:06:17 +00:00
|
|
|
# https://github.com/ClangBuiltLinux/linux/issues/1881
|
|
|
|
select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if !LD_IS_LLD
|
2021-04-16 16:37:22 +00:00
|
|
|
select HAVE_MOVE_PMD
|
|
|
|
select HAVE_MOVE_PUD
|
2024-02-26 16:14:13 +00:00
|
|
|
select HAVE_PAGE_SIZE_4KB
|
2020-06-04 20:55:14 +00:00
|
|
|
select HAVE_PCI
|
2018-04-19 23:27:49 +00:00
|
|
|
select HAVE_PERF_EVENTS
|
2019-09-05 03:46:35 +00:00
|
|
|
select HAVE_PERF_REGS
|
|
|
|
select HAVE_PERF_USER_STACK_DUMP
|
2022-10-02 04:49:31 +00:00
|
|
|
select HAVE_POSIX_CPU_TIMERS_TASK_WORK
|
riscv: support PREEMPT_DYNAMIC with static keys
Currently, each architecture can support PREEMPT_DYNAMIC through
either static calls or static keys. To support PREEMPT_DYNAMIC on
riscv, we face three choices:
1. only add static calls support to riscv
As Mark pointed out in commit 99cf983cc8bc ("sched/preempt: Add
PREEMPT_DYNAMIC using static keys"), static keys "...should have
slightly lower overhead than non-inline static calls, as this
effectively inlines each trampoline into the start of its callee. This
may avoid redundant work, and may integrate better with CFI schemes."
So even we add static calls(without inline static calls) to riscv,
static keys is still a better choice.
2. add static calls and inline static calls to riscv
Per my understanding, inline static calls requires objtool support
which is not easy.
3. use static keys
While riscv doesn't have static calls support, it supports static keys
perfectly. So this patch selects HAVE_PREEMPT_DYNAMIC_KEY to enable
support for PREEMPT_DYNAMIC on riscv, so that the preemption model can
be chosen at boot time. It also patches asm-generic/preempt.h, mainly
to add __preempt_schedule() and __preempt_schedule_notrace() macros
for PREEMPT_DYNAMIC case. Other architectures which use generic
preempt.h can also benefit from this patch by simply selecting
HAVE_PREEMPT_DYNAMIC_KEY to enable PREEMPT_DYNAMIC if they supports
static keys.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230716164925.1858-1-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-16 16:49:25 +00:00
|
|
|
select HAVE_PREEMPT_DYNAMIC_KEY if !XIP_KERNEL
|
2020-12-17 16:01:37 +00:00
|
|
|
select HAVE_REGS_AND_STACK_ACCESS_API
|
2023-05-23 16:54:59 +00:00
|
|
|
select HAVE_RETHOOK if !XIP_KERNEL
|
2022-12-19 17:28:37 +00:00
|
|
|
select HAVE_RSEQ
|
2024-10-01 11:28:13 +00:00
|
|
|
select HAVE_RUST if RUSTC_SUPPORTS_RISCV && CC_IS_CLANG
|
2023-11-30 12:15:31 +00:00
|
|
|
select HAVE_SAMPLE_FTRACE_DIRECT
|
|
|
|
select HAVE_SAMPLE_FTRACE_DIRECT_MULTI
|
2020-07-10 16:19:57 +00:00
|
|
|
select HAVE_STACKPROTECTOR
|
2018-12-06 15:26:35 +00:00
|
|
|
select HAVE_SYSCALL_TRACEPOINTS
|
2023-05-12 21:07:40 +00:00
|
|
|
select HOTPLUG_CORE_SYNC_DEAD if HOTPLUG_CPU
|
2017-07-11 01:08:08 +00:00
|
|
|
select IRQ_DOMAIN
|
2021-07-08 01:59:47 +00:00
|
|
|
select IRQ_FORCED_THREADING
|
2023-02-03 07:52:32 +00:00
|
|
|
select KASAN_VMALLOC if KASAN
|
2023-06-22 18:18:18 +00:00
|
|
|
select LOCK_MM_AND_FIND_VMA
|
2023-12-19 17:50:45 +00:00
|
|
|
select MMU_GATHER_RCU_TABLE_FREE if SMP && MMU
|
2017-07-11 01:08:08 +00:00
|
|
|
select MODULES_USE_ELF_RELA if MODULES
|
2020-06-04 20:55:14 +00:00
|
|
|
select OF
|
|
|
|
select OF_EARLY_FLATTREE
|
|
|
|
select OF_IRQ
|
2018-11-15 19:05:33 +00:00
|
|
|
select PCI_DOMAINS_GENERIC if PCI
|
2024-08-12 00:59:21 +00:00
|
|
|
select PCI_ECAM if (ACPI && PCI)
|
2018-11-15 19:05:32 +00:00
|
|
|
select PCI_MSI if PCI
|
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 10:05:39 +00:00
|
|
|
select RISCV_ALTERNATIVE if !XIP_KERNEL
|
2024-03-07 14:03:06 +00:00
|
|
|
select RISCV_APLIC
|
|
|
|
select RISCV_IMSIC
|
2020-06-01 09:15:43 +00:00
|
|
|
select RISCV_INTC
|
2020-08-17 12:42:50 +00:00
|
|
|
select RISCV_TIMER if RISCV_SBI
|
2022-11-18 10:43:01 +00:00
|
|
|
select SIFIVE_PLIC
|
2020-06-04 20:55:14 +00:00
|
|
|
select SPARSE_IRQ
|
|
|
|
select SYSCTL_EXCEPTION_TRACE
|
|
|
|
select THREAD_INFO_IN_TASK
|
2021-07-31 05:22:32 +00:00
|
|
|
select TRACE_IRQFLAGS_SUPPORT
|
2020-09-07 05:58:22 +00:00
|
|
|
select UACCESS_MEMCPY if !MMU
|
2024-07-08 03:28:47 +00:00
|
|
|
select USER_STACKTRACE_SUPPORT
|
2021-07-01 01:52:20 +00:00
|
|
|
select ZONE_DMA32 if 64BIT
|
2019-09-23 22:39:21 +00:00
|
|
|
|
2024-08-29 08:22:45 +00:00
|
|
|
config RUSTC_SUPPORTS_RISCV
|
|
|
|
def_bool y
|
|
|
|
depends on 64BIT
|
|
|
|
# Shadow call stack requires rustc version 1.82+ due to use of the
|
|
|
|
# -Zsanitizer=shadow-call-stack flag.
|
|
|
|
depends on !SHADOW_CALL_STACK || RUSTC_VERSION >= 108200
|
|
|
|
|
2023-04-04 20:34:21 +00:00
|
|
|
config CLANG_SUPPORTS_DYNAMIC_FTRACE
|
|
|
|
def_bool CC_IS_CLANG
|
|
|
|
# https://github.com/ClangBuiltLinux/linux/issues/1817
|
|
|
|
depends on AS_IS_GNU || (AS_IS_LLVM && (LD_IS_LLD || LD_VERSION >= 23600))
|
|
|
|
|
|
|
|
config GCC_SUPPORTS_DYNAMIC_FTRACE
|
|
|
|
def_bool CC_IS_GCC
|
|
|
|
depends on $(cc-option,-fpatchable-function-entry=8)
|
|
|
|
|
2023-09-27 22:48:02 +00:00
|
|
|
config HAVE_SHADOW_CALL_STACK
|
|
|
|
def_bool $(cc-option,-fsanitize=shadow-call-stack)
|
|
|
|
# https://github.com/riscv-non-isa/riscv-elf-psabi-doc/commit/a484e843e6eeb51f0cb7b8819e50da6d2444d769
|
|
|
|
depends on $(ld-option,--no-relax-gp)
|
|
|
|
|
2023-12-05 23:53:50 +00:00
|
|
|
config RISCV_USE_LINKER_RELAXATION
|
|
|
|
def_bool y
|
|
|
|
# https://github.com/llvm/llvm-project/commit/6611d58f5bbcbec77262d392e2923e1d680f6985
|
|
|
|
depends on !LD_IS_LLD || LLD_VERSION >= 150000
|
|
|
|
|
2023-12-05 23:53:51 +00:00
|
|
|
# https://github.com/llvm/llvm-project/commit/bbc0f99f3bc96f1db16f649fc21dd18e5b0918f6
|
|
|
|
config ARCH_HAS_BROKEN_DWARF5
|
|
|
|
def_bool y
|
|
|
|
depends on RISCV_USE_LINKER_RELAXATION
|
|
|
|
# https://github.com/llvm/llvm-project/commit/1df5ea29b43690b6622db2cad7b745607ca4de6a
|
|
|
|
depends on AS_IS_LLVM && AS_VERSION < 180000
|
|
|
|
# https://github.com/llvm/llvm-project/commit/7ffabb61a5569444b5ac9322e22e5471cc5e4a77
|
|
|
|
depends on LD_IS_LLD && LLD_VERSION < 180000
|
|
|
|
|
2019-09-23 22:39:21 +00:00
|
|
|
config ARCH_MMAP_RND_BITS_MIN
|
|
|
|
default 18 if 64BIT
|
|
|
|
default 8
|
|
|
|
|
2022-04-05 07:13:14 +00:00
|
|
|
config ARCH_MMAP_RND_COMPAT_BITS_MIN
|
|
|
|
default 8
|
|
|
|
|
2019-09-23 22:39:21 +00:00
|
|
|
# max bits determined by the following formula:
|
|
|
|
# VA_BITS - PAGE_SHIFT - 3
|
|
|
|
config ARCH_MMAP_RND_BITS_MAX
|
|
|
|
default 24 if 64BIT # SV39 based
|
|
|
|
default 17
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2022-04-05 07:13:14 +00:00
|
|
|
config ARCH_MMAP_RND_COMPAT_BITS_MAX
|
|
|
|
default 17
|
|
|
|
|
2019-10-28 12:10:32 +00:00
|
|
|
# set if we run in machine mode, cleared if we run in supervisor mode
|
|
|
|
config RISCV_M_MODE
|
2024-02-27 00:34:49 +00:00
|
|
|
bool "Build a kernel that runs in machine mode"
|
|
|
|
depends on !MMU
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Select this option if you want to run the kernel in M-mode,
|
|
|
|
without the assistance of any other firmware.
|
2019-10-28 12:10:32 +00:00
|
|
|
|
2019-10-28 12:10:33 +00:00
|
|
|
# set if we are running in S-mode and can use SBI calls
|
|
|
|
config RISCV_SBI
|
|
|
|
bool
|
|
|
|
depends on !RISCV_M_MODE
|
|
|
|
default y
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
config MMU
|
2019-10-28 12:10:41 +00:00
|
|
|
bool "MMU-based Paged Memory Management Support"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Select if you want MMU-based virtualised addressing space
|
|
|
|
support by paged memory management. If unsure, say 'Y'.
|
2017-07-11 01:08:08 +00:00
|
|
|
|
|
|
|
config PAGE_OFFSET
|
|
|
|
hex
|
2024-02-27 00:34:49 +00:00
|
|
|
default 0x80000000 if !MMU && RISCV_M_MODE
|
|
|
|
default 0x80200000 if !MMU
|
|
|
|
default 0xc0000000 if 32BIT
|
2022-01-27 02:48:43 +00:00
|
|
|
default 0xff60000000000000 if 64BIT
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2021-10-29 04:59:27 +00:00
|
|
|
config KASAN_SHADOW_OFFSET
|
|
|
|
hex
|
|
|
|
depends on KASAN_GENERIC
|
2021-12-06 10:46:45 +00:00
|
|
|
default 0xdfffffff00000000 if 64BIT
|
2021-10-29 04:59:27 +00:00
|
|
|
default 0xffffffff if 32BIT
|
|
|
|
|
2019-08-28 21:40:54 +00:00
|
|
|
config ARCH_FLATMEM_ENABLE
|
2020-11-19 00:38:29 +00:00
|
|
|
def_bool !NUMA
|
2019-08-28 21:40:54 +00:00
|
|
|
|
|
|
|
config ARCH_SPARSEMEM_ENABLE
|
|
|
|
def_bool y
|
2020-02-12 10:34:24 +00:00
|
|
|
depends on MMU
|
2021-03-29 03:13:07 +00:00
|
|
|
select SPARSEMEM_STATIC if 32BIT && SPARSEMEM
|
2021-03-15 12:03:07 +00:00
|
|
|
select SPARSEMEM_VMEMMAP_ENABLE if 64BIT
|
2019-08-28 21:40:54 +00:00
|
|
|
|
|
|
|
config ARCH_SELECT_MEMORY_MODEL
|
|
|
|
def_bool ARCH_SPARSEMEM_ENABLE
|
|
|
|
|
2020-12-17 16:01:44 +00:00
|
|
|
config ARCH_SUPPORTS_UPROBES
|
|
|
|
def_bool y
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
config STACKTRACE_SUPPORT
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
config GENERIC_BUG
|
|
|
|
def_bool y
|
|
|
|
depends on BUG
|
|
|
|
select GENERIC_BUG_RELATIVE_POINTERS if 64BIT
|
|
|
|
|
|
|
|
config GENERIC_BUG_RELATIVE_POINTERS
|
|
|
|
bool
|
|
|
|
|
|
|
|
config GENERIC_CALIBRATE_DELAY
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
config GENERIC_CSUM
|
|
|
|
def_bool y
|
|
|
|
|
|
|
|
config GENERIC_HWEIGHT
|
|
|
|
def_bool y
|
|
|
|
|
2019-01-07 15:27:01 +00:00
|
|
|
config FIX_EARLYCON_MEM
|
2019-12-17 11:15:16 +00:00
|
|
|
def_bool MMU
|
2019-01-07 15:27:01 +00:00
|
|
|
|
2024-07-05 17:02:10 +00:00
|
|
|
config ILLEGAL_POINTER_VALUE
|
|
|
|
hex
|
|
|
|
default 0 if 32BIT
|
|
|
|
default 0xdead000000000000 if 64BIT
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
config PGTABLE_LEVELS
|
|
|
|
int
|
2022-01-27 02:48:43 +00:00
|
|
|
default 5 if 64BIT
|
2017-07-11 01:08:08 +00:00
|
|
|
default 2
|
|
|
|
|
2020-06-27 13:57:08 +00:00
|
|
|
config LOCKDEP_SUPPORT
|
|
|
|
def_bool y
|
|
|
|
|
2022-07-06 23:15:35 +00:00
|
|
|
config RISCV_DMA_NONCOHERENT
|
|
|
|
bool
|
|
|
|
select ARCH_HAS_DMA_PREP_COHERENT
|
|
|
|
select ARCH_HAS_SETUP_DMA_OPS
|
2022-12-19 17:28:37 +00:00
|
|
|
select ARCH_HAS_SYNC_DMA_FOR_CPU
|
|
|
|
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
|
riscv: enable DMA_BOUNCE_UNALIGNED_KMALLOC for !dma_coherent
With the DMA bouncing of unaligned kmalloc() buffers now in place,
enable it for riscv when RISCV_DMA_NONCOHERENT=y to allow the
kmalloc-{8,16,32,96} caches. Since RV32 doesn't enable SWIOTLB
yet, and I didn't see any dma noncoherent RV32 platforms in the
mainline, so skip RV32 now by only enabling
DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB is available. Once we see
such requirement on RV32, we can enable it then.
NOTE: we didn't force to create the swiotlb buffer even when the
end of RAM is within the 32-bit physical address range. That's to
say:
For RV64 with > 4GB memory, the feature is enabled.
For RV64 with <= 4GB memory, the feature isn't enabled by default. We
rely on users to pass "swiotlb=mmnn,force" where mmnn is the Number of
I/O TLB slabs, see kernel-parameters.txt for details.
Tested on Sipeed Lichee Pi 4A with 8GB DDR and Sipeed M1S BL808 Dock
board.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230718152214.2907-3-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-07-18 15:22:14 +00:00
|
|
|
select DMA_BOUNCE_UNALIGNED_KMALLOC if SWIOTLB
|
2022-07-06 23:15:35 +00:00
|
|
|
|
2023-08-18 13:57:20 +00:00
|
|
|
config RISCV_NONSTANDARD_CACHE_OPS
|
|
|
|
bool
|
|
|
|
help
|
|
|
|
This enables function pointer support for non-standard noncoherent
|
|
|
|
systems to handle cache management.
|
|
|
|
|
2022-10-02 04:48:07 +00:00
|
|
|
config AS_HAS_INSN
|
|
|
|
def_bool $(as-instr,.insn r 51$(comma) 0$(comma) 0$(comma) t0$(comma) t0$(comma) zero)
|
|
|
|
|
2023-06-05 11:07:20 +00:00
|
|
|
config AS_HAS_OPTION_ARCH
|
2024-01-09 22:16:30 +00:00
|
|
|
# https://github.com/llvm/llvm-project/commit/9e8ed3403c191ab9c4903e8eeb8f732ff8a43cb4
|
2023-06-05 11:07:20 +00:00
|
|
|
def_bool y
|
|
|
|
depends on $(as-instr, .option arch$(comma) +m)
|
|
|
|
|
2019-06-17 19:29:48 +00:00
|
|
|
source "arch/riscv/Kconfig.socs"
|
2023-02-24 15:45:57 +00:00
|
|
|
source "arch/riscv/Kconfig.errata"
|
2019-06-17 19:29:48 +00:00
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
menu "Platform type"
|
|
|
|
|
2022-05-21 19:33:57 +00:00
|
|
|
config NONPORTABLE
|
|
|
|
bool "Allow configurations that result in non-portable kernels"
|
|
|
|
help
|
|
|
|
RISC-V kernel binaries are compatible between all known systems
|
|
|
|
whenever possible, but there are some use cases that can only be
|
|
|
|
satisfied by configurations that result in kernel binaries that are
|
|
|
|
not portable between systems.
|
|
|
|
|
|
|
|
Selecting N does not guarantee kernels will be portable to all known
|
|
|
|
systems. Selecting any of the options guarded by NONPORTABLE will
|
|
|
|
result in kernel binaries that are unlikely to be portable between
|
|
|
|
systems.
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
choice
|
|
|
|
prompt "Base ISA"
|
|
|
|
default ARCH_RV64I
|
|
|
|
help
|
2019-01-08 19:45:57 +00:00
|
|
|
This selects the base ISA that this kernel will target and must match
|
2017-07-11 01:08:08 +00:00
|
|
|
the target platform.
|
|
|
|
|
|
|
|
config ARCH_RV32I
|
|
|
|
bool "RV32I"
|
2022-05-21 19:33:57 +00:00
|
|
|
depends on NONPORTABLE
|
2017-07-11 01:08:08 +00:00
|
|
|
select 32BIT
|
2018-04-11 07:50:17 +00:00
|
|
|
select GENERIC_LIB_ASHLDI3
|
|
|
|
select GENERIC_LIB_ASHRDI3
|
|
|
|
select GENERIC_LIB_LSHRDI3
|
2018-06-25 08:49:38 +00:00
|
|
|
select GENERIC_LIB_UCMPDI2
|
2017-07-11 01:08:08 +00:00
|
|
|
|
|
|
|
config ARCH_RV64I
|
|
|
|
bool "RV64I"
|
|
|
|
select 64BIT
|
2021-09-10 23:40:42 +00:00
|
|
|
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
|
2019-10-28 12:10:41 +00:00
|
|
|
select SWIOTLB if MMU
|
2017-07-11 01:08:08 +00:00
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
|
|
|
# We must be able to map all physical memory into the kernel, but the compiler
|
|
|
|
# is still a bit more efficient when generating code if it's setup in a manner
|
|
|
|
# such that it can only map 2GiB of memory.
|
|
|
|
choice
|
|
|
|
prompt "Kernel Code Model"
|
|
|
|
default CMODEL_MEDLOW if 32BIT
|
|
|
|
default CMODEL_MEDANY if 64BIT
|
|
|
|
|
|
|
|
config CMODEL_MEDLOW
|
|
|
|
bool "medium low code model"
|
|
|
|
config CMODEL_MEDANY
|
|
|
|
bool "medium any code model"
|
|
|
|
endchoice
|
|
|
|
|
2018-03-15 08:50:41 +00:00
|
|
|
config MODULE_SECTIONS
|
|
|
|
bool
|
|
|
|
select HAVE_MOD_ARCH_SPECIFIC
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
config SMP
|
|
|
|
bool "Symmetric Multi-Processing"
|
|
|
|
help
|
|
|
|
This enables support for systems with more than one CPU. If
|
|
|
|
you say N here, the kernel will run on single and
|
|
|
|
multiprocessor machines, but will use only one CPU of a
|
|
|
|
multiprocessor machine. If you say Y here, the kernel will run
|
|
|
|
on many, but not all, single processor machines. On a single
|
|
|
|
processor machine, the kernel will run faster if you say N
|
|
|
|
here.
|
|
|
|
|
|
|
|
If you don't know what to do here, say N.
|
|
|
|
|
2023-03-10 11:03:36 +00:00
|
|
|
config SCHED_MC
|
|
|
|
bool "Multi-core scheduler support"
|
|
|
|
depends on SMP
|
|
|
|
help
|
|
|
|
Multi-core scheduler support improves the CPU scheduler's decision
|
|
|
|
making when dealing with multi-core CPU chips at a cost of slightly
|
|
|
|
increased overhead in some places. If unsure say N here.
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
config NR_CPUS
|
2022-04-20 11:24:08 +00:00
|
|
|
int "Maximum number of CPUs (2-512)"
|
2017-07-11 01:08:08 +00:00
|
|
|
depends on SMP
|
2022-11-26 06:15:56 +00:00
|
|
|
range 2 512 if !RISCV_SBI_V01
|
|
|
|
range 2 32 if RISCV_SBI_V01 && 32BIT
|
|
|
|
range 2 64 if RISCV_SBI_V01 && 64BIT
|
2022-04-20 11:24:08 +00:00
|
|
|
default "32" if 32BIT
|
|
|
|
default "64" if 64BIT
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2020-03-18 01:11:44 +00:00
|
|
|
config HOTPLUG_CPU
|
|
|
|
bool "Support for hot-pluggable CPUs"
|
|
|
|
depends on SMP
|
|
|
|
select GENERIC_IRQ_MIGRATION
|
|
|
|
help
|
|
|
|
|
|
|
|
Say Y here to experiment with turning CPUs off and on. CPUs
|
|
|
|
can be controlled through /sys/devices/system/cpu.
|
|
|
|
|
|
|
|
Say N if you want to disable CPU hotplug.
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
choice
|
|
|
|
prompt "CPU Tuning"
|
|
|
|
default TUNE_GENERIC
|
|
|
|
|
|
|
|
config TUNE_GENERIC
|
|
|
|
bool "generic"
|
|
|
|
|
|
|
|
endchoice
|
|
|
|
|
2020-11-19 00:38:29 +00:00
|
|
|
# Common NUMA Features
|
|
|
|
config NUMA
|
|
|
|
bool "NUMA Memory Allocation and Scheduler Support"
|
2021-03-30 13:25:31 +00:00
|
|
|
depends on SMP && MMU
|
2022-12-19 17:28:37 +00:00
|
|
|
select ARCH_SUPPORTS_NUMA_BALANCING
|
2020-11-19 00:38:29 +00:00
|
|
|
select GENERIC_ARCH_NUMA
|
2023-12-12 21:34:57 +00:00
|
|
|
select HAVE_SETUP_PER_CPU_AREA
|
2022-12-19 17:28:37 +00:00
|
|
|
select NEED_PER_CPU_EMBED_FIRST_CHUNK
|
2023-12-12 21:34:57 +00:00
|
|
|
select NEED_PER_CPU_PAGE_FIRST_CHUNK
|
2020-11-19 00:38:29 +00:00
|
|
|
select OF_NUMA
|
mm: percpu: generalize percpu related config
Patch series "mm: percpu: Cleanup percpu first chunk function".
When supporting page mapping percpu first chunk allocator on arm64, we
found there are lots of duplicated codes in percpu embed/page first chunk
allocator. This patchset is aimed to cleanup them and should no function
change.
The currently supported status about 'embed' and 'page' in Archs shows
below,
embed: NEED_PER_CPU_PAGE_FIRST_CHUNK
page: NEED_PER_CPU_EMBED_FIRST_CHUNK
embed page
------------------------
arm64 Y Y
mips Y N
powerpc Y Y
riscv Y N
sparc Y Y
x86 Y Y
------------------------
There are two interfaces about percpu first chunk allocator,
extern int __init pcpu_embed_first_chunk(size_t reserved_size, size_t dyn_size,
size_t atom_size,
pcpu_fc_cpu_distance_fn_t cpu_distance_fn,
- pcpu_fc_alloc_fn_t alloc_fn,
- pcpu_fc_free_fn_t free_fn);
+ pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
extern int __init pcpu_page_first_chunk(size_t reserved_size,
- pcpu_fc_alloc_fn_t alloc_fn,
- pcpu_fc_free_fn_t free_fn,
- pcpu_fc_populate_pte_fn_t populate_pte_fn);
+ pcpu_fc_cpu_to_node_fn_t cpu_to_nd_fn);
The pcpu_fc_alloc_fn_t/pcpu_fc_free_fn_t is killed, we provide generic
pcpu_fc_alloc() and pcpu_fc_free() function, which are called in the
pcpu_embed/page_first_chunk().
1) For pcpu_embed_first_chunk(), pcpu_fc_cpu_to_node_fn_t is needed to be
provided when archs supported NUMA.
2) For pcpu_page_first_chunk(), the pcpu_fc_populate_pte_fn_t is killed too,
a generic pcpu_populate_pte() which marked '__weak' is provided, if you
need a different function to populate pte on the arch(like x86), please
provide its own implementation.
[1] https://github.com/kevin78/linux.git percpu-cleanup
This patch (of 4):
The HAVE_SETUP_PER_CPU_AREA/NEED_PER_CPU_EMBED_FIRST_CHUNK/
NEED_PER_CPU_PAGE_FIRST_CHUNK/USE_PERCPU_NUMA_NODE_ID configs, which have
duplicate definitions on platforms that subscribe it.
Move them into mm, drop these redundant definitions and instead just
select it on applicable platforms.
Link: https://lkml.kernel.org/r/20211216112359.103822-1-wangkefeng.wang@huawei.com
Link: https://lkml.kernel.org/r/20211216112359.103822-2-wangkefeng.wang@huawei.com
Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Acked-by: Catalin Marinas <catalin.marinas@arm.com> [arm64]
Cc: Will Deacon <will@kernel.org>
Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Dennis Zhou <dennis@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2022-01-20 02:07:41 +00:00
|
|
|
select USE_PERCPU_NUMA_NODE_ID
|
2020-11-19 00:38:29 +00:00
|
|
|
help
|
|
|
|
Enable NUMA (Non-Uniform Memory Access) support.
|
|
|
|
|
|
|
|
The kernel will try to allocate memory used by a CPU on the
|
|
|
|
local memory of the CPU and add some more NUMA awareness to the kernel.
|
|
|
|
|
|
|
|
config NODES_SHIFT
|
|
|
|
int "Maximum NUMA Nodes (as a power of 2)"
|
|
|
|
range 1 10
|
|
|
|
default "2"
|
2021-06-29 02:43:01 +00:00
|
|
|
depends on NUMA
|
2020-11-19 00:38:29 +00:00
|
|
|
help
|
|
|
|
Specify the maximum number of NUMA Nodes available on the target
|
|
|
|
system. Increases memory reserved to accommodate various tables.
|
|
|
|
|
2022-05-11 19:29:10 +00:00
|
|
|
config RISCV_ALTERNATIVE
|
|
|
|
bool
|
|
|
|
depends on !XIP_KERNEL
|
|
|
|
help
|
|
|
|
This Kconfig allows the kernel to automatically patch the
|
2023-02-24 15:45:59 +00:00
|
|
|
erratum or cpufeature required by the execution platform at run
|
|
|
|
time. The code patching overhead is minimal, as it's only done
|
|
|
|
once at boot and once on each module load.
|
2022-05-11 19:29:10 +00:00
|
|
|
|
2022-05-11 19:29:21 +00:00
|
|
|
config RISCV_ALTERNATIVE_EARLY
|
|
|
|
bool
|
|
|
|
depends on RISCV_ALTERNATIVE
|
|
|
|
help
|
|
|
|
Allows early patching of the kernel for special errata
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
config RISCV_ISA_C
|
|
|
|
bool "Emit compressed instructions when building Linux"
|
|
|
|
default y
|
|
|
|
help
|
2022-05-20 12:02:30 +00:00
|
|
|
Adds "C" to the ISA subsets that the toolchain is allowed to emit
|
|
|
|
when building Linux, which results in compressed instructions in the
|
|
|
|
Linux binary.
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2022-05-20 12:02:30 +00:00
|
|
|
If you don't know what to do here, say Y.
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2023-02-09 13:16:45 +00:00
|
|
|
config RISCV_ISA_SVNAPOT
|
2023-04-05 10:21:10 +00:00
|
|
|
bool "Svnapot extension support for supervisor mode NAPOT pages"
|
2023-02-09 13:16:45 +00:00
|
|
|
depends on 64BIT && MMU
|
2023-03-24 12:12:41 +00:00
|
|
|
depends on RISCV_ALTERNATIVE
|
2023-02-09 13:16:45 +00:00
|
|
|
default y
|
|
|
|
help
|
2023-04-05 10:21:10 +00:00
|
|
|
Allow kernel to detect the Svnapot ISA-extension dynamically at boot
|
2023-02-09 13:16:45 +00:00
|
|
|
time and enable its usage.
|
|
|
|
|
2023-04-05 10:21:10 +00:00
|
|
|
The Svnapot extension is used to mark contiguous PTEs as a range
|
2023-02-09 13:16:45 +00:00
|
|
|
of contiguous virtual-to-physical translations for a naturally
|
|
|
|
aligned power-of-2 (NAPOT) granularity larger than the base 4KB page
|
|
|
|
size. When HUGETLBFS is also selected this option unconditionally
|
|
|
|
allocates some memory for each NAPOT page size supported by the kernel.
|
|
|
|
When optimizing for low memory consumption and for platforms without
|
2023-04-05 10:21:10 +00:00
|
|
|
the Svnapot extension, it may be better to say N here.
|
2023-02-09 13:16:45 +00:00
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2022-05-11 19:29:18 +00:00
|
|
|
config RISCV_ISA_SVPBMT
|
2023-04-05 10:21:10 +00:00
|
|
|
bool "Svpbmt extension support for supervisor mode page-based memory types"
|
2022-05-11 19:29:18 +00:00
|
|
|
depends on 64BIT && MMU
|
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 10:05:39 +00:00
|
|
|
depends on RISCV_ALTERNATIVE
|
2022-05-11 19:29:18 +00:00
|
|
|
default y
|
|
|
|
help
|
2023-04-05 10:21:10 +00:00
|
|
|
Adds support to dynamically detect the presence of the Svpbmt
|
2022-05-26 20:56:43 +00:00
|
|
|
ISA-extension (Supervisor-mode: page-based memory types) and
|
|
|
|
enable its usage.
|
|
|
|
|
|
|
|
The memory type for a page contains a combination of attributes
|
|
|
|
that indicate the cacheability, idempotency, and ordering
|
|
|
|
properties for access to that page.
|
2022-05-11 19:29:18 +00:00
|
|
|
|
2023-04-05 10:21:10 +00:00
|
|
|
The Svpbmt extension is only available on 64-bit cpus.
|
2022-05-11 19:29:18 +00:00
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2023-06-05 11:07:21 +00:00
|
|
|
config TOOLCHAIN_HAS_V
|
|
|
|
bool
|
|
|
|
default y
|
2024-08-19 00:11:31 +00:00
|
|
|
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64imv)
|
|
|
|
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32imv)
|
2023-06-05 11:07:21 +00:00
|
|
|
depends on LLD_VERSION >= 140000 || LD_VERSION >= 23800
|
|
|
|
depends on AS_HAS_OPTION_ARCH
|
|
|
|
|
|
|
|
config RISCV_ISA_V
|
|
|
|
bool "VECTOR extension support"
|
|
|
|
depends on TOOLCHAIN_HAS_V
|
|
|
|
depends on FPU
|
|
|
|
select DYNAMIC_SIGFRAME
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Say N here if you want to disable all vector related procedure
|
|
|
|
in the kernel.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
|
|
|
config RISCV_ISA_V_DEFAULT_ENABLE
|
|
|
|
bool "Enable userspace Vector by default"
|
|
|
|
depends on RISCV_ISA_V
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Say Y here if you want to enable Vector in userspace by default.
|
|
|
|
Otherwise, userspace has to make explicit prctl() call to enable
|
|
|
|
Vector, or enable it via the sysctl interface.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2024-01-15 05:59:24 +00:00
|
|
|
config RISCV_ISA_V_UCOPY_THRESHOLD
|
|
|
|
int "Threshold size for vectorized user copies"
|
|
|
|
depends on RISCV_ISA_V
|
|
|
|
default 768
|
|
|
|
help
|
|
|
|
Prefer using vectorized copy_to_user()/copy_from_user() when the
|
|
|
|
workload size exceeds this value.
|
|
|
|
|
2024-01-15 05:59:29 +00:00
|
|
|
config RISCV_ISA_V_PREEMPTIVE
|
|
|
|
bool "Run kernel-mode Vector with kernel preemption"
|
|
|
|
depends on PREEMPTION
|
|
|
|
depends on RISCV_ISA_V
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Usually, in-kernel SIMD routines are run with preemption disabled.
|
|
|
|
Functions which envoke long running SIMD thus must yield core's
|
|
|
|
vector unit to prevent blocking other tasks for too long.
|
|
|
|
|
|
|
|
This config allows kernel to run SIMD without explicitly disable
|
|
|
|
preemption. Enabling this config will result in higher memory
|
|
|
|
consumption due to the allocation of per-task's kernel Vector context.
|
|
|
|
|
2024-04-26 10:08:23 +00:00
|
|
|
config RISCV_ISA_ZAWRS
|
|
|
|
bool "Zawrs extension support for more efficient busy waiting"
|
|
|
|
depends on RISCV_ALTERNATIVE
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
The Zawrs extension defines instructions to be used in polling loops
|
|
|
|
which allow a hart to enter a low-power state or to trap to the
|
|
|
|
hypervisor while waiting on a store to a memory location. Enable the
|
|
|
|
use of these instructions in the kernel when the Zawrs extension is
|
|
|
|
detected at boot.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2023-01-13 21:23:01 +00:00
|
|
|
config TOOLCHAIN_HAS_ZBB
|
2022-07-06 23:15:35 +00:00
|
|
|
bool
|
2022-10-06 17:35:20 +00:00
|
|
|
default y
|
2023-01-13 21:23:01 +00:00
|
|
|
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbb)
|
|
|
|
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbb)
|
|
|
|
depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
|
2023-06-05 11:07:20 +00:00
|
|
|
depends on AS_HAS_OPTION_ARCH
|
2023-01-13 21:23:01 +00:00
|
|
|
|
2024-01-22 00:19:13 +00:00
|
|
|
# This symbol indicates that the toolchain supports all v1.0 vector crypto
|
|
|
|
# extensions, including Zvk*, Zvbb, and Zvbc. LLVM added all of these at once.
|
|
|
|
# binutils added all except Zvkb, then added Zvkb. So we just check for Zvkb.
|
|
|
|
config TOOLCHAIN_HAS_VECTOR_CRYPTO
|
2024-01-27 09:00:54 +00:00
|
|
|
def_bool $(as-instr, .option arch$(comma) +v$(comma) +zvkb)
|
2024-01-22 00:19:13 +00:00
|
|
|
depends on AS_HAS_OPTION_ARCH
|
|
|
|
|
2024-05-16 09:04:30 +00:00
|
|
|
config RISCV_ISA_ZBA
|
|
|
|
bool "Zba extension support for bit manipulation instructions"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Add support for enabling optimisations in the kernel when the Zba
|
|
|
|
extension is detected at boot.
|
|
|
|
|
|
|
|
The Zba extension provides instructions to accelerate the generation
|
|
|
|
of addresses that index into arrays of basic data types.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2023-01-13 21:23:01 +00:00
|
|
|
config RISCV_ISA_ZBB
|
|
|
|
bool "Zbb extension support for bit manipulation instructions"
|
|
|
|
depends on TOOLCHAIN_HAS_ZBB
|
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 10:05:39 +00:00
|
|
|
depends on RISCV_ALTERNATIVE
|
2023-01-13 21:23:01 +00:00
|
|
|
default y
|
|
|
|
help
|
|
|
|
Adds support to dynamically detect the presence of the ZBB
|
|
|
|
extension (basic bit manipulation) and enable its usage.
|
|
|
|
|
|
|
|
The Zbb extension provides instructions to accelerate a number
|
|
|
|
of bit-specific operations (count bit population, sign extending,
|
|
|
|
bitrotation, etc).
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
2022-07-06 23:15:35 +00:00
|
|
|
|
riscv: Optimize crc32 with Zbc extension
As suggested by the B-ext spec, the Zbc (carry-less multiplication)
instructions can be used to accelerate CRC calculations. Currently, the
crc32 is the most widely used crc function inside kernel, so this patch
focuses on the optimization of just the crc32 APIs.
Compared with the current table-lookup based optimization, Zbc based
optimization can also achieve large stride during CRC calculation loop,
meantime, it avoids the memory access latency of the table-lookup based
implementation and it reduces memory footprint.
If Zbc feature is not supported in a runtime environment, then the
table-lookup based implementation would serve as fallback via alternative
mechanism.
By inspecting the vmlinux built by gcc v12.2.0 with default optimization
level (-O2), we can see below instruction count change for each 8-byte
stride in the CRC32 loop:
rv64: crc32_be (54->31), crc32_le (54->13), __crc32c_le (54->13)
rv32: crc32_be (50->32), crc32_le (50->16), __crc32c_le (50->16)
The compile target CPU is little endian, extra effort is needed for byte
swapping for the crc32_be API, thus, the instruction count change is not
as significant as that in the *_le cases.
This patch is tested on QEMU VM with the kernel CRC32 selftest for both
rv64 and rv32. Running the CRC32 selftest on a real hardware (SpacemiT K1)
with Zbc extension shows 65% and 125% performance improvement respectively
on crc32_test() and crc32c_test().
Signed-off-by: Xiao Wang <xiao.w.wang@intel.com>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Link: https://lore.kernel.org/r/20240621054707.1847548-1-xiao.w.wang@intel.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2024-06-21 05:47:07 +00:00
|
|
|
config TOOLCHAIN_HAS_ZBC
|
|
|
|
bool
|
|
|
|
default y
|
|
|
|
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zbc)
|
|
|
|
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zbc)
|
|
|
|
depends on LLD_VERSION >= 150000 || LD_VERSION >= 23900
|
|
|
|
depends on AS_HAS_OPTION_ARCH
|
|
|
|
|
|
|
|
config RISCV_ISA_ZBC
|
|
|
|
bool "Zbc extension support for carry-less multiplication instructions"
|
|
|
|
depends on TOOLCHAIN_HAS_ZBC
|
|
|
|
depends on MMU
|
|
|
|
depends on RISCV_ALTERNATIVE
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Adds support to dynamically detect the presence of the Zbc
|
|
|
|
extension (carry-less multiplication) and enable its usage.
|
|
|
|
|
|
|
|
The Zbc extension could accelerate CRC (cyclic redundancy check)
|
|
|
|
calculations.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2022-07-06 23:15:35 +00:00
|
|
|
config RISCV_ISA_ZICBOM
|
|
|
|
bool "Zicbom extension support for non-coherent DMA operation"
|
RISC-V: always select RISCV_ALTERNATIVE for non-xip kernels
When moving switch_to's has_fpu() over to using
riscv_has_extension_likely() rather than static branches, the FPU code
gained a dependency on the alternatives framework.
That dependency has now been removed, as riscv_has_extension_ikely() now
contains a fallback path, using __riscv_isa_extension_available(), but
if CONFIG_RISCV_ALTERNATIVE isn't selected when CONFIG_FPU is, has_fpu()
checks will not benefit from the "fast path" that the alternatives
framework provides.
We want to ensure that alternatives are available whenever
riscv_has_extension_[un]likely() is used, rather than silently falling
back to the slow path, but rather than rely on selecting
RISCV_ALTERNATIVE in the myriad of locations that may use
riscv_has_extension_[un]likely(), select it (almost) always instead by
adding it to the main RISCV config entry.
xip kernels cannot make use of the alternatives framework, so it is not
enabled for those configurations, although this is the status quo.
All current sites that select RISCV_ALTERNATIVE are converted to
dependencies on the option instead. The explicit dependencies on
!XIP_KERNEL can be dropped, as RISCV_ALTERNATIVE is not user selectable.
Fixes: 702e64550b12 ("riscv: fpu: switch has_fpu() to riscv_has_extension_likely()")
Link: https://lore.kernel.org/all/ZBruFRwt3rUVngPu@zx2c4.com/
Reported-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Reviewed-by: Andrew Jones <ajones@ventanamicro.com>
Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com>
Link: https://lore.kernel.org/r/20230324100538.3514663-3-conor.dooley@microchip.com
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-24 10:05:39 +00:00
|
|
|
depends on MMU
|
|
|
|
depends on RISCV_ALTERNATIVE
|
2022-07-06 23:15:35 +00:00
|
|
|
default y
|
2022-12-19 17:28:37 +00:00
|
|
|
select RISCV_DMA_NONCOHERENT
|
2023-10-18 05:26:53 +00:00
|
|
|
select DMA_DIRECT_REMAP
|
2022-07-06 23:15:35 +00:00
|
|
|
help
|
|
|
|
Adds support to dynamically detect the presence of the ZICBOM
|
|
|
|
extension (Cache Block Management Operations) and enable its
|
|
|
|
usage.
|
|
|
|
|
|
|
|
The Zicbom extension can be used to handle for example
|
|
|
|
non-coherent DMA support on devices that need it.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2023-02-24 16:26:29 +00:00
|
|
|
config RISCV_ISA_ZICBOZ
|
|
|
|
bool "Zicboz extension support for faster zeroing of memory"
|
2023-03-24 12:12:41 +00:00
|
|
|
depends on RISCV_ALTERNATIVE
|
2023-02-24 16:26:29 +00:00
|
|
|
default y
|
|
|
|
help
|
2023-04-05 10:21:10 +00:00
|
|
|
Enable the use of the Zicboz extension (cbo.zero instruction)
|
2023-02-24 16:26:29 +00:00
|
|
|
when available.
|
|
|
|
|
|
|
|
The Zicboz extension is used for faster zeroing of memory.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-13 23:00:23 +00:00
|
|
|
config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
|
|
|
|
def_bool y
|
|
|
|
# https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
|
2023-08-09 16:56:48 +00:00
|
|
|
# https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=98416dbb0a62579d4a7a4a76bab51b5b52fec2cd
|
|
|
|
depends on AS_IS_GNU && AS_VERSION >= 23600
|
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-13 23:00:23 +00:00
|
|
|
help
|
2023-08-09 16:56:48 +00:00
|
|
|
Binutils-2.38 and GCC-12.1.0 bumped the default ISA spec to the newer
|
|
|
|
20191213 version, which moves some instructions from the I extension to
|
|
|
|
the Zicsr and Zifencei extensions. This requires explicitly specifying
|
|
|
|
Zicsr and Zifencei when binutils >= 2.38 or GCC >= 12.1.0. Zicsr
|
|
|
|
and Zifencei are supported in binutils from version 2.36 onwards.
|
|
|
|
To make life easier, and avoid forcing toolchains that default to a
|
|
|
|
newer ISA spec to version 2.2, relax the check to binutils >= 2.36.
|
2023-08-24 19:08:52 +00:00
|
|
|
For clang < 17 or GCC < 11.3.0, for which this is not possible or need
|
|
|
|
special treatment, this is dealt with in TOOLCHAIN_NEEDS_OLD_ISA_SPEC.
|
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-13 23:00:23 +00:00
|
|
|
|
|
|
|
config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
|
|
|
|
def_bool y
|
|
|
|
depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
|
|
|
|
# https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
|
2023-08-24 19:08:52 +00:00
|
|
|
# https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=d29f5d6ab513c52fd872f532c492e35ae9fd6671
|
|
|
|
depends on (CC_IS_CLANG && CLANG_VERSION < 170000) || (CC_IS_GCC && GCC_VERSION < 110300)
|
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-13 23:00:23 +00:00
|
|
|
help
|
2023-08-09 16:56:48 +00:00
|
|
|
Certain versions of clang and GCC do not support zicsr and zifencei via
|
|
|
|
-march. This option causes an older ISA spec compatible with these older
|
|
|
|
versions of clang and GCC to be passed to GAS, which has the same result
|
|
|
|
as passing zicsr and zifencei to -march.
|
riscv: Handle zicsr/zifencei issues between clang and binutils
There are two related issues that appear in certain combinations with
clang and GNU binutils.
The first occurs when a version of clang that supports zicsr or zifencei
via '-march=' [1] (i.e, >= 17.x) is used in combination with a version
of GNU binutils that do not recognize zicsr and zifencei in the
'-march=' value (i.e., < 2.36):
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/file.o
riscv64-linux-gnu-ld: -march=rv64i2p0_m2p0_a2p0_c2p0_zicsr2p0_zifencei2p0: Invalid or unknown z ISA extension: 'zifencei'
riscv64-linux-gnu-ld: failed to merge target specific data of file fs/efivarfs/super.o
The second occurs when a version of clang that does not support zicsr or
zifencei via '-march=' (i.e., <= 16.x) is used in combination with a
version of GNU as that defaults to a newer ISA base spec, which requires
specifying zicsr and zifencei in the '-march=' value explicitly (i.e, >=
2.38):
../arch/riscv/kernel/kexec_relocate.S: Assembler messages:
../arch/riscv/kernel/kexec_relocate.S:147: Error: unrecognized opcode `fence.i', extension `zifencei' required
clang-12: error: assembler command failed with exit code 1 (use -v to see invocation)
This is the same issue addressed by commit 6df2a016c0c8 ("riscv: fix
build with binutils 2.38") (see [2] for additional information) but
older versions of clang miss out on it because the cc-option check
fails:
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
clang-12: error: invalid arch name 'rv64imac_zicsr_zifencei', unsupported standard user-level extension 'zicsr'
To resolve the first issue, only attempt to add zicsr and zifencei to
the march string when using the GNU assembler 2.38 or newer, which is
when the default ISA spec was updated, requiring these extensions to be
specified explicitly. LLVM implements an older version of the base
specification for all currently released versions, so these instructions
are available as part of the 'i' extension. If LLVM's implementation is
updated in the future, a CONFIG_AS_IS_LLVM condition can be added to
CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI.
To resolve the second issue, use version 2.2 of the base ISA spec when
using an older version of clang that does not support zicsr or zifencei
via '-march=', as that is the spec version most compatible with the one
clang/LLVM implements and avoids the need to specify zicsr and zifencei
explicitly due to still being a part of 'i'.
[1]: https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
[2]: https://lore.kernel.org/ZAxT7T9Xy1Fo3d5W@aurel32.net/
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1808
Co-developed-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Link: https://lore.kernel.org/r/20230313-riscv-zicsr-zifencei-fiasco-v1-1-dd1b7840a551@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-03-13 23:00:23 +00:00
|
|
|
|
2018-10-09 02:18:33 +00:00
|
|
|
config FPU
|
|
|
|
bool "FPU support"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Say N here if you want to disable all floating-point related procedure
|
|
|
|
in the kernel.
|
|
|
|
|
|
|
|
If you don't know what to do here, say Y.
|
|
|
|
|
2023-06-14 01:30:16 +00:00
|
|
|
config IRQ_STACKS
|
2023-06-14 01:30:17 +00:00
|
|
|
bool "Independent irq & softirq stacks" if EXPERT
|
2023-06-14 01:30:16 +00:00
|
|
|
default y
|
|
|
|
select HAVE_IRQ_EXIT_ON_IRQ_STACK
|
2023-06-14 01:30:17 +00:00
|
|
|
select HAVE_SOFTIRQ_ON_OWN_STACK
|
2023-06-14 01:30:16 +00:00
|
|
|
help
|
2023-06-14 01:30:17 +00:00
|
|
|
Add independent irq & softirq stacks for percpu to prevent kernel stack
|
|
|
|
overflows. We may save some memory footprint by disabling IRQ_STACKS.
|
2023-06-14 01:30:16 +00:00
|
|
|
|
2023-06-14 01:30:18 +00:00
|
|
|
config THREAD_SIZE_ORDER
|
|
|
|
int "Kernel stack size (in power-of-two numbers of page size)" if VMAP_STACK && EXPERT
|
|
|
|
range 0 4
|
2024-09-17 15:03:28 +00:00
|
|
|
default 1 if 32BIT
|
2023-06-14 01:30:18 +00:00
|
|
|
default 2
|
|
|
|
help
|
|
|
|
Specify the Pages of thread stack size (from 4KB to 64KB), which also
|
|
|
|
affects irq stack size, which is equal to thread stack size.
|
|
|
|
|
2023-10-04 15:13:59 +00:00
|
|
|
config RISCV_MISALIGNED
|
2024-03-08 18:25:58 +00:00
|
|
|
bool
|
2023-10-04 15:14:02 +00:00
|
|
|
select SYSCTL_ARCH_UNALIGN_ALLOW
|
2023-10-04 15:13:59 +00:00
|
|
|
help
|
2024-03-08 18:25:58 +00:00
|
|
|
Embed support for emulating misaligned loads and stores.
|
|
|
|
|
|
|
|
choice
|
|
|
|
prompt "Unaligned Accesses Support"
|
|
|
|
default RISCV_PROBE_UNALIGNED_ACCESS
|
|
|
|
help
|
|
|
|
This determines the level of support for unaligned accesses. This
|
|
|
|
information is used by the kernel to perform optimizations. It is also
|
|
|
|
exposed to user space via the hwprobe syscall. The hardware will be
|
|
|
|
probed at boot by default.
|
|
|
|
|
|
|
|
config RISCV_PROBE_UNALIGNED_ACCESS
|
|
|
|
bool "Probe for hardware unaligned access support"
|
|
|
|
select RISCV_MISALIGNED
|
|
|
|
help
|
|
|
|
During boot, the kernel will run a series of tests to determine the
|
|
|
|
speed of unaligned accesses. This probing will dynamically determine
|
|
|
|
the speed of unaligned accesses on the underlying system. If unaligned
|
|
|
|
memory accesses trap into the kernel as they are not supported by the
|
|
|
|
system, the kernel will emulate the unaligned accesses to preserve the
|
|
|
|
UABI.
|
|
|
|
|
|
|
|
config RISCV_EMULATED_UNALIGNED_ACCESS
|
|
|
|
bool "Emulate unaligned access where system support is missing"
|
|
|
|
select RISCV_MISALIGNED
|
|
|
|
help
|
|
|
|
If unaligned memory accesses trap into the kernel as they are not
|
|
|
|
supported by the system, the kernel will emulate the unaligned
|
|
|
|
accesses to preserve the UABI. When the underlying system does support
|
|
|
|
unaligned accesses, the unaligned accesses are assumed to be slow.
|
|
|
|
|
|
|
|
config RISCV_SLOW_UNALIGNED_ACCESS
|
|
|
|
bool "Assume the system supports slow unaligned memory accesses"
|
|
|
|
depends on NONPORTABLE
|
|
|
|
help
|
|
|
|
Assume that the system supports slow unaligned memory accesses. The
|
|
|
|
kernel and userspace programs may not be able to run at all on systems
|
|
|
|
that do not support unaligned memory accesses.
|
2023-10-04 15:13:59 +00:00
|
|
|
|
riscv: introduce RISCV_EFFICIENT_UNALIGNED_ACCESS
Some riscv implementations such as T-HEAD's C906, C908, C910 and C920
support efficient unaligned access, for performance reason we want
to enable HAVE_EFFICIENT_UNALIGNED_ACCESS on these platforms. To
avoid performance regressions on other non efficient unaligned access
platforms, HAVE_EFFICIENT_UNALIGNED_ACCESS can't be globally selected.
To solve this problem, runtime code patching based on the detected
speed is a good solution. But that's not easy, it involves lots of
work to modify vairous subsystems such as net, mm, lib and so on.
This can be done step by step.
So let's take an easier solution: add support to efficient unaligned
access and hide the support under NONPORTABLE.
Now let's introduce RISCV_EFFICIENT_UNALIGNED_ACCESS which depends on
NONPORTABLE, if users know during config time that the kernel will be
only run on those efficient unaligned access hw platforms, they can
enable it. Obviously, generic unified kernel Image shouldn't enable it.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20231225044207.3821-2-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-25 04:42:06 +00:00
|
|
|
config RISCV_EFFICIENT_UNALIGNED_ACCESS
|
2024-03-08 18:25:58 +00:00
|
|
|
bool "Assume the system supports fast unaligned memory accesses"
|
riscv: introduce RISCV_EFFICIENT_UNALIGNED_ACCESS
Some riscv implementations such as T-HEAD's C906, C908, C910 and C920
support efficient unaligned access, for performance reason we want
to enable HAVE_EFFICIENT_UNALIGNED_ACCESS on these platforms. To
avoid performance regressions on other non efficient unaligned access
platforms, HAVE_EFFICIENT_UNALIGNED_ACCESS can't be globally selected.
To solve this problem, runtime code patching based on the detected
speed is a good solution. But that's not easy, it involves lots of
work to modify vairous subsystems such as net, mm, lib and so on.
This can be done step by step.
So let's take an easier solution: add support to efficient unaligned
access and hide the support under NONPORTABLE.
Now let's introduce RISCV_EFFICIENT_UNALIGNED_ACCESS which depends on
NONPORTABLE, if users know during config time that the kernel will be
only run on those efficient unaligned access hw platforms, they can
enable it. Obviously, generic unified kernel Image shouldn't enable it.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20231225044207.3821-2-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-25 04:42:06 +00:00
|
|
|
depends on NONPORTABLE
|
2023-12-25 04:42:07 +00:00
|
|
|
select DCACHE_WORD_ACCESS if MMU
|
riscv: introduce RISCV_EFFICIENT_UNALIGNED_ACCESS
Some riscv implementations such as T-HEAD's C906, C908, C910 and C920
support efficient unaligned access, for performance reason we want
to enable HAVE_EFFICIENT_UNALIGNED_ACCESS on these platforms. To
avoid performance regressions on other non efficient unaligned access
platforms, HAVE_EFFICIENT_UNALIGNED_ACCESS can't be globally selected.
To solve this problem, runtime code patching based on the detected
speed is a good solution. But that's not easy, it involves lots of
work to modify vairous subsystems such as net, mm, lib and so on.
This can be done step by step.
So let's take an easier solution: add support to efficient unaligned
access and hide the support under NONPORTABLE.
Now let's introduce RISCV_EFFICIENT_UNALIGNED_ACCESS which depends on
NONPORTABLE, if users know during config time that the kernel will be
only run on those efficient unaligned access hw platforms, they can
enable it. Obviously, generic unified kernel Image shouldn't enable it.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20231225044207.3821-2-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-25 04:42:06 +00:00
|
|
|
select HAVE_EFFICIENT_UNALIGNED_ACCESS
|
|
|
|
help
|
2024-03-08 18:25:58 +00:00
|
|
|
Assume that the system supports fast unaligned memory accesses. When
|
|
|
|
enabled, this option improves the performance of the kernel on such
|
|
|
|
systems. However, the kernel and userspace programs will run much more
|
|
|
|
slowly, or will not be able to run at all, on systems that do not
|
|
|
|
support efficient unaligned memory accesses.
|
riscv: introduce RISCV_EFFICIENT_UNALIGNED_ACCESS
Some riscv implementations such as T-HEAD's C906, C908, C910 and C920
support efficient unaligned access, for performance reason we want
to enable HAVE_EFFICIENT_UNALIGNED_ACCESS on these platforms. To
avoid performance regressions on other non efficient unaligned access
platforms, HAVE_EFFICIENT_UNALIGNED_ACCESS can't be globally selected.
To solve this problem, runtime code patching based on the detected
speed is a good solution. But that's not easy, it involves lots of
work to modify vairous subsystems such as net, mm, lib and so on.
This can be done step by step.
So let's take an easier solution: add support to efficient unaligned
access and hide the support under NONPORTABLE.
Now let's introduce RISCV_EFFICIENT_UNALIGNED_ACCESS which depends on
NONPORTABLE, if users know during config time that the kernel will be
only run on those efficient unaligned access hw platforms, they can
enable it. Obviously, generic unified kernel Image shouldn't enable it.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20231225044207.3821-2-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-25 04:42:06 +00:00
|
|
|
|
2024-03-08 18:25:58 +00:00
|
|
|
endchoice
|
riscv: introduce RISCV_EFFICIENT_UNALIGNED_ACCESS
Some riscv implementations such as T-HEAD's C906, C908, C910 and C920
support efficient unaligned access, for performance reason we want
to enable HAVE_EFFICIENT_UNALIGNED_ACCESS on these platforms. To
avoid performance regressions on other non efficient unaligned access
platforms, HAVE_EFFICIENT_UNALIGNED_ACCESS can't be globally selected.
To solve this problem, runtime code patching based on the detected
speed is a good solution. But that's not easy, it involves lots of
work to modify vairous subsystems such as net, mm, lib and so on.
This can be done step by step.
So let's take an easier solution: add support to efficient unaligned
access and hide the support under NONPORTABLE.
Now let's introduce RISCV_EFFICIENT_UNALIGNED_ACCESS which depends on
NONPORTABLE, if users know during config time that the kernel will be
only run on those efficient unaligned access hw platforms, they can
enable it. Obviously, generic unified kernel Image shouldn't enable it.
Signed-off-by: Jisheng Zhang <jszhang@kernel.org>
Reviewed-by: Charlie Jenkins <charlie@rivosinc.com>
Reviewed-by: Eric Biggers <ebiggers@google.com>
Link: https://lore.kernel.org/r/20231225044207.3821-2-jszhang@kernel.org
Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com>
2023-12-25 04:42:06 +00:00
|
|
|
|
2024-07-19 16:15:18 +00:00
|
|
|
source "arch/riscv/Kconfig.vendor"
|
|
|
|
|
2022-05-20 12:02:30 +00:00
|
|
|
endmenu # "Platform type"
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2018-09-19 22:48:15 +00:00
|
|
|
menu "Kernel features"
|
2017-07-11 01:08:08 +00:00
|
|
|
|
|
|
|
source "kernel/Kconfig.hz"
|
|
|
|
|
2020-03-18 01:11:37 +00:00
|
|
|
config RISCV_SBI_V01
|
|
|
|
bool "SBI v0.1 support"
|
|
|
|
depends on RISCV_SBI
|
|
|
|
help
|
|
|
|
This config allows kernel to use SBI v0.1 APIs. This will be
|
|
|
|
deprecated in future once legacy M-mode software are no longer in use.
|
2021-04-19 00:55:36 +00:00
|
|
|
|
2022-01-20 09:09:17 +00:00
|
|
|
config RISCV_BOOT_SPINWAIT
|
|
|
|
bool "Spinwait booting method"
|
|
|
|
depends on SMP
|
2022-04-21 17:03:55 +00:00
|
|
|
default y if RISCV_SBI_V01 || RISCV_M_MODE
|
2022-01-20 09:09:17 +00:00
|
|
|
help
|
|
|
|
This enables support for booting Linux via spinwait method. In the
|
|
|
|
spinwait method, all cores randomly jump to Linux. One of the cores
|
|
|
|
gets chosen via lottery and all other keep spinning on a percpu
|
|
|
|
variable. This method cannot support CPU hotplug and sparse hartid
|
|
|
|
scheme. It should be only enabled for M-mode Linux or platforms relying
|
|
|
|
on older firmware without SBI HSM extension. All other platforms should
|
|
|
|
rely on ordered booting via SBI HSM extension which gets chosen
|
|
|
|
dynamically at runtime if the firmware supports it.
|
|
|
|
|
2022-04-21 17:03:55 +00:00
|
|
|
Since spinwait is incompatible with sparse hart IDs, it requires
|
|
|
|
NR_CPUS be large enough to contain the physical hart ID of the first
|
|
|
|
hart to enter Linux.
|
|
|
|
|
|
|
|
If unsure what to do here, say N.
|
|
|
|
|
2023-07-12 16:15:42 +00:00
|
|
|
config ARCH_SUPPORTS_KEXEC
|
2023-11-29 22:04:09 +00:00
|
|
|
def_bool y
|
2023-07-12 16:15:42 +00:00
|
|
|
|
|
|
|
config ARCH_SELECTS_KEXEC
|
|
|
|
def_bool y
|
|
|
|
depends on KEXEC
|
2022-12-19 17:28:37 +00:00
|
|
|
select HOTPLUG_CPU if SMP
|
2021-04-19 00:55:36 +00:00
|
|
|
|
2023-07-12 16:15:42 +00:00
|
|
|
config ARCH_SUPPORTS_KEXEC_FILE
|
2023-11-29 22:04:09 +00:00
|
|
|
def_bool 64BIT
|
2021-04-19 00:55:36 +00:00
|
|
|
|
2023-07-12 16:15:42 +00:00
|
|
|
config ARCH_SELECTS_KEXEC_FILE
|
|
|
|
def_bool y
|
|
|
|
depends on KEXEC_FILE
|
2022-12-19 17:28:37 +00:00
|
|
|
select HAVE_IMA_KEXEC if IMA
|
2022-04-08 10:09:11 +00:00
|
|
|
select KEXEC_ELF
|
|
|
|
|
2023-07-12 16:15:45 +00:00
|
|
|
config ARCH_SUPPORTS_KEXEC_PURGATORY
|
kexec: fix KEXEC_FILE dependencies
The cleanup for the CONFIG_KEXEC Kconfig logic accidentally changed the
'depends on CRYPTO=y' dependency to a plain 'depends on CRYPTO', which
causes a link failure when all the crypto support is in a loadable module
and kexec_file support is built-in:
x86_64-linux-ld: vmlinux.o: in function `__x64_sys_kexec_file_load':
(.text+0x32e30a): undefined reference to `crypto_alloc_shash'
x86_64-linux-ld: (.text+0x32e58e): undefined reference to `crypto_shash_update'
x86_64-linux-ld: (.text+0x32e6ee): undefined reference to `crypto_shash_final'
Both s390 and x86 have this problem, while ppc64 and riscv have the
correct dependency already. On riscv, the dependency is only used for the
purgatory, not for the kexec_file code itself, which may be a bit
surprising as it means that with CONFIG_CRYPTO=m, it is possible to enable
KEXEC_FILE but then the purgatory code is silently left out.
Move this into the common Kconfig.kexec file in a way that is correct
everywhere, using the dependency on CRYPTO_SHA256=y only when the
purgatory code is available. This requires reversing the dependency
between ARCH_SUPPORTS_KEXEC_PURGATORY and KEXEC_FILE, but the effect
remains the same, other than making riscv behave like the other ones.
On s390, there is an additional dependency on CRYPTO_SHA256_S390, which
should technically not be required but gives better performance. Remove
this dependency here, noting that it was not present in the initial
Kconfig code but was brought in without an explanation in commit
71406883fd357 ("s390/kexec_file: Add kexec_file_load system call").
[arnd@arndb.de: fix riscv build]
Link: https://lkml.kernel.org/r/67ddd260-d424-4229-a815-e3fcfb864a77@app.fastmail.com
Link: https://lkml.kernel.org/r/20231023110308.1202042-1-arnd@kernel.org
Fixes: 6af5138083005 ("x86/kexec: refactor for kernel/Kconfig.kexec")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Eric DeVolder <eric_devolder@yahoo.com>
Tested-by: Eric DeVolder <eric_devolder@yahoo.com>
Cc: Albert Ou <aou@eecs.berkeley.edu>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Conor Dooley <conor@kernel.org>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Paul Walmsley <paul.walmsley@sifive.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2023-10-23 11:01:54 +00:00
|
|
|
def_bool ARCH_SUPPORTS_KEXEC_FILE
|
2022-04-08 10:09:13 +00:00
|
|
|
|
2023-07-12 16:15:42 +00:00
|
|
|
config ARCH_SUPPORTS_CRASH_DUMP
|
|
|
|
def_bool y
|
2021-04-19 00:55:36 +00:00
|
|
|
|
2024-09-17 16:37:20 +00:00
|
|
|
config ARCH_DEFAULT_CRASH_DUMP
|
|
|
|
def_bool y
|
|
|
|
|
2023-09-14 03:31:41 +00:00
|
|
|
config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION
|
kexec: split crashkernel reservation code out from crash_core.c
Patch series "Split crash out from kexec and clean up related config
items", v3.
Motivation:
=============
Previously, LKP reported a building error. When investigating, it can't
be resolved reasonablly with the present messy kdump config items.
https://lore.kernel.org/oe-kbuild-all/202312182200.Ka7MzifQ-lkp@intel.com/
The kdump (crash dumping) related config items could causes confusions:
Firstly,
CRASH_CORE enables codes including
- crashkernel reservation;
- elfcorehdr updating;
- vmcoreinfo exporting;
- crash hotplug handling;
Now fadump of powerpc, kcore dynamic debugging and kdump all selects
CRASH_CORE, while fadump
- fadump needs crashkernel parsing, vmcoreinfo exporting, and accessing
global variable 'elfcorehdr_addr';
- kcore only needs vmcoreinfo exporting;
- kdump needs all of the current kernel/crash_core.c.
So only enabling PROC_CORE or FA_DUMP will enable CRASH_CORE, this
mislead people that we enable crash dumping, actual it's not.
Secondly,
It's not reasonable to allow KEXEC_CORE select CRASH_CORE.
Because KEXEC_CORE enables codes which allocate control pages, copy
kexec/kdump segments, and prepare for switching. These codes are
shared by both kexec reboot and kdump. We could want kexec reboot,
but disable kdump. In that case, CRASH_CORE should not be selected.
--------------------
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC=y
CONFIG_KEXEC_FILE=y
---------------------
Thirdly,
It's not reasonable to allow CRASH_DUMP select KEXEC_CORE.
That could make KEXEC_CORE, CRASH_DUMP are enabled independently from
KEXEC or KEXEC_FILE. However, w/o KEXEC or KEXEC_FILE, the KEXEC_CORE
code built in doesn't make any sense because no kernel loading or
switching will happen to utilize the KEXEC_CORE code.
---------------------
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_CRASH_DUMP=y
---------------------
In this case, what is worse, on arch sh and arm, KEXEC relies on MMU,
while CRASH_DUMP can still be enabled when !MMU, then compiling error is
seen as the lkp test robot reported in above link.
------arch/sh/Kconfig------
config ARCH_SUPPORTS_KEXEC
def_bool MMU
config ARCH_SUPPORTS_CRASH_DUMP
def_bool BROKEN_ON_SMP
---------------------------
Changes:
===========
1, split out crash_reserve.c from crash_core.c;
2, split out vmcore_infoc. from crash_core.c;
3, move crash related codes in kexec_core.c into crash_core.c;
4, remove dependency of FA_DUMP on CRASH_DUMP;
5, clean up kdump related config items;
6, wrap up crash codes in crash related ifdefs on all 8 arch-es
which support crash dumping, except of ppc;
Achievement:
===========
With above changes, I can rearrange the config item logic as below (the right
item depends on or is selected by the left item):
PROC_KCORE -----------> VMCORE_INFO
|----------> VMCORE_INFO
FA_DUMP----|
|----------> CRASH_RESERVE
---->VMCORE_INFO
/
|---->CRASH_RESERVE
KEXEC --| /|
|--> KEXEC_CORE--> CRASH_DUMP-->/-|---->PROC_VMCORE
KEXEC_FILE --| \ |
\---->CRASH_HOTPLUG
KEXEC --|
|--> KEXEC_CORE (for kexec reboot only)
KEXEC_FILE --|
Test
========
On all 8 architectures, including x86_64, arm64, s390x, sh, arm, mips,
riscv, loongarch, I did below three cases of config item setting and
building all passed. Take configs on x86_64 as exampmle here:
(1) Both CONFIG_KEXEC and KEXEC_FILE is unset, then all kexec/kdump
items are unset automatically:
# Kexec and crash features
# CONFIG_KEXEC is not set
# CONFIG_KEXEC_FILE is not set
# end of Kexec and crash features
(2) set CONFIG_KEXEC_FILE and 'make olddefconfig':
---------------
# Kexec and crash features
CONFIG_CRASH_RESERVE=y
CONFIG_VMCORE_INFO=y
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC_FILE=y
CONFIG_CRASH_DUMP=y
CONFIG_CRASH_HOTPLUG=y
CONFIG_CRASH_MAX_MEMORY_RANGES=8192
# end of Kexec and crash features
---------------
(3) unset CONFIG_CRASH_DUMP in case 2 and execute 'make olddefconfig':
------------------------
# Kexec and crash features
CONFIG_KEXEC_CORE=y
CONFIG_KEXEC_FILE=y
# end of Kexec and crash features
------------------------
Note:
For ppc, it needs investigation to make clear how to split out crash
code in arch folder. Hope Hari and Pingfan can help have a look, see if
it's doable. Now, I make it either have both kexec and crash enabled, or
disable both of them altogether.
This patch (of 14):
Both kdump and fa_dump of ppc rely on crashkernel reservation. Move the
relevant codes into separate files: crash_reserve.c,
include/linux/crash_reserve.h.
And also add config item CRASH_RESERVE to control its enabling of the
codes. And update config items which has relationship with crashkernel
reservation.
And also change ifdeffery from CONFIG_CRASH_CORE to CONFIG_CRASH_RESERVE
when those scopes are only crashkernel reservation related.
And also rename arch/XXX/include/asm/{crash_core.h => crash_reserve.h} on
arm64, x86 and risc-v because those architectures' crash_core.h is only
related to crashkernel reservation.
[akpm@linux-foundation.org: s/CRASH_RESEERVE/CRASH_RESERVE/, per Klara Modin]
Link: https://lkml.kernel.org/r/20240124051254.67105-1-bhe@redhat.com
Link: https://lkml.kernel.org/r/20240124051254.67105-2-bhe@redhat.com
Signed-off-by: Baoquan He <bhe@redhat.com>
Acked-by: Hari Bathini <hbathini@linux.ibm.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Cc: Pingfan Liu <piliu@redhat.com>
Cc: Klara Modin <klarasmodin@gmail.com>
Cc: Michael Kelley <mhklinux@outlook.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Yang Li <yang.lee@linux.alibaba.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
2024-01-24 05:12:41 +00:00
|
|
|
def_bool CRASH_RESERVE
|
2023-09-14 03:31:41 +00:00
|
|
|
|
2022-04-05 07:13:14 +00:00
|
|
|
config COMPAT
|
|
|
|
bool "Kernel support for 32-bit U-mode"
|
|
|
|
default 64BIT
|
|
|
|
depends on 64BIT && MMU
|
|
|
|
help
|
|
|
|
This option enables support for a 32-bit U-mode running under a 64-bit
|
|
|
|
kernel at S-mode. riscv32-specific components such as system calls,
|
|
|
|
the user helper functions (vdso), signal rt_frame functions and the
|
|
|
|
ptrace interface are handled appropriately by the kernel.
|
|
|
|
|
|
|
|
If you want to execute 32-bit userspace applications, say Y.
|
|
|
|
|
2023-12-20 16:00:16 +00:00
|
|
|
config PARAVIRT
|
|
|
|
bool "Enable paravirtualization code"
|
|
|
|
depends on RISCV_SBI
|
|
|
|
help
|
|
|
|
This changes the kernel so it can modify itself when it is run
|
|
|
|
under a hypervisor, potentially improving performance significantly
|
|
|
|
over full virtualization.
|
|
|
|
|
|
|
|
config PARAVIRT_TIME_ACCOUNTING
|
|
|
|
bool "Paravirtual steal time accounting"
|
|
|
|
depends on PARAVIRT
|
|
|
|
help
|
|
|
|
Select this option to enable fine granularity task steal time
|
|
|
|
accounting. Time spent executing other tasks in parallel with
|
|
|
|
the current vCPU is discounted from the vCPU power. To account for
|
|
|
|
that, there can be a small performance impact.
|
|
|
|
|
|
|
|
If in doubt, say N here.
|
|
|
|
|
2023-03-29 04:53:26 +00:00
|
|
|
config RELOCATABLE
|
|
|
|
bool "Build a relocatable kernel"
|
|
|
|
depends on MMU && 64BIT && !XIP_KERNEL
|
2024-05-11 01:57:25 +00:00
|
|
|
select MODULE_SECTIONS if MODULES
|
2023-03-29 04:53:26 +00:00
|
|
|
help
|
|
|
|
This builds a kernel as a Position Independent Executable (PIE),
|
|
|
|
which retains all relocation metadata required to relocate the
|
|
|
|
kernel binary at runtime to a different virtual address than the
|
|
|
|
address it was linked at.
|
|
|
|
Since RISCV uses the RELA relocation format, this requires a
|
|
|
|
relocation pass at runtime even if the kernel is loaded at the
|
|
|
|
same address it was linked at.
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
2023-07-22 12:38:46 +00:00
|
|
|
config RANDOMIZE_BASE
|
|
|
|
bool "Randomize the address of the kernel image"
|
|
|
|
select RELOCATABLE
|
|
|
|
depends on MMU && 64BIT && !XIP_KERNEL
|
|
|
|
help
|
|
|
|
Randomizes the virtual address at which the kernel image is
|
|
|
|
loaded, as a security feature that deters exploit attempts
|
|
|
|
relying on knowledge of the location of kernel internals.
|
|
|
|
|
|
|
|
It is the bootloader's job to provide entropy, by passing a
|
|
|
|
random u64 value in /chosen/kaslr-seed at kernel entry.
|
|
|
|
|
|
|
|
When booting via the UEFI stub, it will invoke the firmware's
|
|
|
|
EFI_RNG_PROTOCOL implementation (if available) to supply entropy
|
|
|
|
to the kernel proper. In addition, it will randomise the physical
|
|
|
|
location of the kernel Image as well.
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
2022-05-20 12:02:30 +00:00
|
|
|
endmenu # "Kernel features"
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2018-09-19 22:48:15 +00:00
|
|
|
menu "Boot options"
|
|
|
|
|
2018-11-18 00:06:56 +00:00
|
|
|
config CMDLINE
|
|
|
|
string "Built-in kernel command line"
|
2018-09-19 22:48:15 +00:00
|
|
|
help
|
2018-11-18 00:06:56 +00:00
|
|
|
For most platforms, the arguments for the kernel's command line
|
|
|
|
are provided at run-time, during boot. However, there are cases
|
|
|
|
where either no arguments are being provided or the provided
|
|
|
|
arguments are insufficient or even invalid.
|
2018-09-19 22:48:15 +00:00
|
|
|
|
2018-11-18 00:06:56 +00:00
|
|
|
When that occurs, it is possible to define a built-in command
|
|
|
|
line here and choose how the kernel should use it later on.
|
2018-09-19 22:48:15 +00:00
|
|
|
|
2018-11-18 00:06:56 +00:00
|
|
|
choice
|
treewide: change conditional prompt for choices to 'depends on'
While Documentation/kbuild/kconfig-language.rst provides a brief
explanation, there are recurring confusions regarding the usage of a
prompt followed by 'if <expr>'. This conditional controls _only_ the
prompt.
A typical usage is as follows:
menuconfig BLOCK
bool "Enable the block layer" if EXPERT
default y
When EXPERT=n, the prompt is hidden, but this config entry is still
active, and BLOCK is set to its default value 'y'. This is reasonable
because you are likely want to enable the block device support. When
EXPERT=y, the prompt is shown, allowing you to toggle BLOCK.
Please note that it is different from 'depends on EXPERT', which would
enable and disable the entire config entry.
However, this conditional prompt has never worked in a choice block.
The following two work in the same way: when EXPERT is disabled, the
choice block is entirely disabled.
[Test Code 1]
choice
prompt "choose" if EXPERT
config A
bool "A"
config B
bool "B"
endchoice
[Test Code 2]
choice
prompt "choose"
depends on EXPERT
config A
bool "A"
config B
bool "B"
endchoice
I believe the first case should hide only the prompt, producing the
default:
CONFIG_A=y
# CONFIG_B is not set
The next commit will change (fix) the behavior of the conditional prompt
in choice blocks.
I see several choice blocks wrongly using a conditional prompt, where
'depends on' makes more sense.
To preserve the current behavior, this commit converts such misuses.
I did not touch the following entry in arch/x86/Kconfig:
choice
prompt "Memory split" if EXPERT
default VMSPLIT_3G
This is truly the correct use of the conditional prompt; when EXPERT=n,
this choice block should silently select the reasonable VMSPLIT_3G,
although the resulting PAGE_OFFSET will not be affected anyway.
Presumably, the one in fs/jffs2/Kconfig is also correct, but I converted
it to 'depends on' to avoid any potential behavioral change.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-06-26 18:22:00 +00:00
|
|
|
prompt "Built-in command line usage"
|
|
|
|
depends on CMDLINE != ""
|
2018-11-18 00:06:56 +00:00
|
|
|
default CMDLINE_FALLBACK
|
|
|
|
help
|
|
|
|
Choose how the kernel will handle the provided built-in command
|
|
|
|
line.
|
2018-09-19 22:48:15 +00:00
|
|
|
|
2018-11-18 00:06:56 +00:00
|
|
|
config CMDLINE_FALLBACK
|
|
|
|
bool "Use bootloader kernel arguments if available"
|
2018-09-19 22:48:15 +00:00
|
|
|
help
|
2018-11-18 00:06:56 +00:00
|
|
|
Use the built-in command line as fallback in case we get nothing
|
|
|
|
during boot. This is the default behaviour.
|
|
|
|
|
|
|
|
config CMDLINE_EXTEND
|
|
|
|
bool "Extend bootloader kernel arguments"
|
|
|
|
help
|
|
|
|
The command-line arguments provided during boot will be
|
|
|
|
appended to the built-in command line. This is useful in
|
|
|
|
cases where the provided arguments are insufficient and
|
|
|
|
you don't want to or cannot modify them.
|
|
|
|
|
2018-09-19 22:48:15 +00:00
|
|
|
config CMDLINE_FORCE
|
2018-11-18 00:06:56 +00:00
|
|
|
bool "Always use the default kernel command string"
|
2018-09-19 22:48:15 +00:00
|
|
|
help
|
2018-11-18 00:06:56 +00:00
|
|
|
Always use the built-in command line, even if we get one during
|
|
|
|
boot. This is useful in case you need to override the provided
|
|
|
|
command line on systems where you don't have or want control
|
|
|
|
over it.
|
2018-09-19 22:48:15 +00:00
|
|
|
|
2018-11-18 00:06:56 +00:00
|
|
|
endchoice
|
2018-09-19 22:48:15 +00:00
|
|
|
|
2020-09-17 22:37:14 +00:00
|
|
|
config EFI_STUB
|
|
|
|
bool
|
|
|
|
|
|
|
|
config EFI
|
|
|
|
bool "UEFI runtime support"
|
2021-04-13 06:35:14 +00:00
|
|
|
depends on OF && !XIP_KERNEL
|
2022-12-19 17:28:37 +00:00
|
|
|
depends on MMU
|
|
|
|
default y
|
2023-05-15 05:49:13 +00:00
|
|
|
select ARCH_SUPPORTS_ACPI if 64BIT
|
2020-09-17 22:37:14 +00:00
|
|
|
select EFI_GENERIC_STUB
|
2022-12-19 17:28:37 +00:00
|
|
|
select EFI_PARAMS_FROM_FDT
|
2020-09-17 22:37:15 +00:00
|
|
|
select EFI_RUNTIME_WRAPPERS
|
2022-12-19 17:28:37 +00:00
|
|
|
select EFI_STUB
|
|
|
|
select LIBFDT
|
2020-09-17 22:37:14 +00:00
|
|
|
select RISCV_ISA_C
|
2022-12-19 17:28:37 +00:00
|
|
|
select UCS2_STRING
|
2020-09-17 22:37:14 +00:00
|
|
|
help
|
|
|
|
This option provides support for runtime services provided
|
|
|
|
by UEFI firmware (such as non-volatile variables, realtime
|
|
|
|
clock, and platform reset). A UEFI stub is also provided to
|
|
|
|
allow the kernel to be booted as an EFI application. This
|
|
|
|
is only useful on systems that have UEFI firmware.
|
|
|
|
|
2024-06-13 06:55:07 +00:00
|
|
|
config DMI
|
|
|
|
bool "Enable support for SMBIOS (DMI) tables"
|
|
|
|
depends on EFI
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
This enables SMBIOS/DMI feature for systems.
|
|
|
|
|
|
|
|
This option is only useful on systems that have UEFI firmware.
|
|
|
|
However, even with this option, the resultant kernel should
|
|
|
|
continue to boot on existing non-UEFI platforms.
|
|
|
|
|
riscv: Enable per-task stack canaries
This enables the use of per-task stack canary values if GCC has
support for emitting the stack canary reference relative to the
value of tp, which holds the task struct pointer in the riscv
kernel.
After compare arm64 and x86 implementations, seems arm64's is more
flexible and readable. The key point is how gcc get the offset of
stack_canary from gs/el0_sp.
x86: Use a fix offset from gs, not flexible.
struct fixed_percpu_data {
/*
* GCC hardcodes the stack canary as %gs:40. Since the
* irq_stack is the object at %gs:0, we reserve the bottom
* 48 bytes of the irq stack for the canary.
*/
char gs_base[40]; // :(
unsigned long stack_canary;
};
arm64: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=sysreg
-mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=xxx
riscv: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=tp
-mstack-protector-guard-offset=xxx
GCC's implementation has been merged:
commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
Author: Cooper Qu <cooper.qu@linux.alibaba.com>
Date: Mon Jul 13 16:15:08 2020 +0800
RISC-V: Add support for TLS stack protector canary access
In the end, these codes are inserted by gcc before return:
* 0xffffffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
* 0xffffffe00020b39a <+124>: xor a5,a5,a4
* 0xffffffe00020b39c <+126>: mv a0,s5
* 0xffffffe00020b39e <+128>: bnez a5,0xffffffe00020b61c <_do_fork+766>
0xffffffe00020b3a2 <+132>: ld ra,136(sp)
0xffffffe00020b3a4 <+134>: ld s0,128(sp)
0xffffffe00020b3a6 <+136>: ld s1,120(sp)
0xffffffe00020b3a8 <+138>: ld s2,112(sp)
0xffffffe00020b3aa <+140>: ld s3,104(sp)
0xffffffe00020b3ac <+142>: ld s4,96(sp)
0xffffffe00020b3ae <+144>: ld s5,88(sp)
0xffffffe00020b3b0 <+146>: ld s6,80(sp)
0xffffffe00020b3b2 <+148>: ld s7,72(sp)
0xffffffe00020b3b4 <+150>: addi sp,sp,144
0xffffffe00020b3b6 <+152>: ret
...
* 0xffffffe00020b61c <+766>: auipc ra,0x7f8
* 0xffffffe00020b620 <+770>: jalr -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail>
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Cooper Qu <cooper.qu@linux.alibaba.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-12-17 16:29:18 +00:00
|
|
|
config CC_HAVE_STACKPROTECTOR_TLS
|
|
|
|
def_bool $(cc-option,-mstack-protector-guard=tls -mstack-protector-guard-reg=tp -mstack-protector-guard-offset=0)
|
|
|
|
|
|
|
|
config STACKPROTECTOR_PER_TASK
|
|
|
|
def_bool y
|
2022-05-03 20:55:00 +00:00
|
|
|
depends on !RANDSTRUCT
|
riscv: Enable per-task stack canaries
This enables the use of per-task stack canary values if GCC has
support for emitting the stack canary reference relative to the
value of tp, which holds the task struct pointer in the riscv
kernel.
After compare arm64 and x86 implementations, seems arm64's is more
flexible and readable. The key point is how gcc get the offset of
stack_canary from gs/el0_sp.
x86: Use a fix offset from gs, not flexible.
struct fixed_percpu_data {
/*
* GCC hardcodes the stack canary as %gs:40. Since the
* irq_stack is the object at %gs:0, we reserve the bottom
* 48 bytes of the irq stack for the canary.
*/
char gs_base[40]; // :(
unsigned long stack_canary;
};
arm64: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=sysreg
-mstack-protector-guard-reg=sp_el0
-mstack-protector-guard-offset=xxx
riscv: Use -mstack-protector-guard-offset & guard-reg
gcc options:
-mstack-protector-guard=tls
-mstack-protector-guard-reg=tp
-mstack-protector-guard-offset=xxx
GCC's implementation has been merged:
commit c931e8d5a96463427040b0d11f9c4352ac22b2b0
Author: Cooper Qu <cooper.qu@linux.alibaba.com>
Date: Mon Jul 13 16:15:08 2020 +0800
RISC-V: Add support for TLS stack protector canary access
In the end, these codes are inserted by gcc before return:
* 0xffffffe00020b396 <+120>: ld a5,1008(tp) # 0x3f0
* 0xffffffe00020b39a <+124>: xor a5,a5,a4
* 0xffffffe00020b39c <+126>: mv a0,s5
* 0xffffffe00020b39e <+128>: bnez a5,0xffffffe00020b61c <_do_fork+766>
0xffffffe00020b3a2 <+132>: ld ra,136(sp)
0xffffffe00020b3a4 <+134>: ld s0,128(sp)
0xffffffe00020b3a6 <+136>: ld s1,120(sp)
0xffffffe00020b3a8 <+138>: ld s2,112(sp)
0xffffffe00020b3aa <+140>: ld s3,104(sp)
0xffffffe00020b3ac <+142>: ld s4,96(sp)
0xffffffe00020b3ae <+144>: ld s5,88(sp)
0xffffffe00020b3b0 <+146>: ld s6,80(sp)
0xffffffe00020b3b2 <+148>: ld s7,72(sp)
0xffffffe00020b3b4 <+150>: addi sp,sp,144
0xffffffe00020b3b6 <+152>: ret
...
* 0xffffffe00020b61c <+766>: auipc ra,0x7f8
* 0xffffffe00020b620 <+770>: jalr -1764(ra) # 0xffffffe000a02f38 <__stack_chk_fail>
Signed-off-by: Guo Ren <guoren@linux.alibaba.com>
Signed-off-by: Cooper Qu <cooper.qu@linux.alibaba.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Palmer Dabbelt <palmerdabbelt@google.com>
2020-12-17 16:29:18 +00:00
|
|
|
depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS
|
|
|
|
|
2021-07-21 07:59:36 +00:00
|
|
|
config PHYS_RAM_BASE_FIXED
|
|
|
|
bool "Explicitly specified physical RAM address"
|
2022-05-21 19:33:57 +00:00
|
|
|
depends on NONPORTABLE
|
2021-07-21 07:59:36 +00:00
|
|
|
default n
|
|
|
|
|
2021-04-13 06:35:14 +00:00
|
|
|
config PHYS_RAM_BASE
|
|
|
|
hex "Platform Physical RAM address"
|
2021-07-21 07:59:36 +00:00
|
|
|
depends on PHYS_RAM_BASE_FIXED
|
2021-04-13 06:35:14 +00:00
|
|
|
default "0x80000000"
|
|
|
|
help
|
|
|
|
This is the physical address of RAM in the system. It has to be
|
|
|
|
explicitly specified to run early relocations of read-write data
|
|
|
|
from flash to RAM.
|
|
|
|
|
|
|
|
config XIP_KERNEL
|
|
|
|
bool "Kernel Execute-In-Place from ROM"
|
2022-05-21 19:33:57 +00:00
|
|
|
depends on MMU && SPARSEMEM && NONPORTABLE
|
2021-04-13 06:35:14 +00:00
|
|
|
# This prevents XIP from being enabled by all{yes,mod}config, which
|
|
|
|
# fail to build since XIP doesn't support large kernels.
|
|
|
|
depends on !COMPILE_TEST
|
2021-07-21 07:59:36 +00:00
|
|
|
select PHYS_RAM_BASE_FIXED
|
2021-04-13 06:35:14 +00:00
|
|
|
help
|
|
|
|
Execute-In-Place allows the kernel to run from non-volatile storage
|
|
|
|
directly addressable by the CPU, such as NOR flash. This saves RAM
|
|
|
|
space since the text section of the kernel is not loaded from flash
|
|
|
|
to RAM. Read-write sections, such as the data section and stack,
|
|
|
|
are still copied to RAM. The XIP kernel is not compressed since
|
|
|
|
it has to run directly from flash, so it will take more space to
|
|
|
|
store it. The flash address used to link the kernel object files,
|
|
|
|
and for storing it, is configuration dependent. Therefore, if you
|
|
|
|
say Y here, you must know the proper physical address where to
|
|
|
|
store the kernel image depending on your own flash memory usage.
|
|
|
|
|
|
|
|
Also note that the make target becomes "make xipImage" rather than
|
|
|
|
"make zImage" or "make Image". The final kernel binary to put in
|
|
|
|
ROM memory will be arch/riscv/boot/xipImage.
|
|
|
|
|
|
|
|
SPARSEMEM is required because the kernel text and rodata that are
|
|
|
|
flash resident are not backed by memmap, then any attempt to get
|
|
|
|
a struct page on those regions will trigger a fault.
|
|
|
|
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
config XIP_PHYS_ADDR
|
|
|
|
hex "XIP Kernel Physical Location"
|
|
|
|
depends on XIP_KERNEL
|
|
|
|
default "0x21000000"
|
|
|
|
help
|
|
|
|
This is the physical address in your flash memory the kernel will
|
|
|
|
be linked for and stored to. This address is dependent on your
|
|
|
|
own flash usage.
|
|
|
|
|
2023-07-13 12:11:09 +00:00
|
|
|
config RISCV_ISA_FALLBACK
|
|
|
|
bool "Permit falling back to parsing riscv,isa for extension support by default"
|
|
|
|
default y
|
|
|
|
help
|
|
|
|
Parsing the "riscv,isa" devicetree property has been deprecated and
|
|
|
|
replaced by a list of explicitly defined strings. For compatibility
|
|
|
|
with existing platforms, the kernel will fall back to parsing the
|
|
|
|
"riscv,isa" property if the replacements are not found.
|
|
|
|
|
|
|
|
Selecting N here will result in a kernel that does not use the
|
|
|
|
fallback, unless the commandline "riscv_isa_fallback" parameter is
|
|
|
|
present.
|
|
|
|
|
|
|
|
Please see the dt-binding, located at
|
|
|
|
Documentation/devicetree/bindings/riscv/extensions.yaml for details
|
|
|
|
on the replacement properties, "riscv,isa-base" and
|
|
|
|
"riscv,isa-extensions".
|
|
|
|
|
2020-04-14 04:43:24 +00:00
|
|
|
config BUILTIN_DTB
|
2023-12-12 13:01:14 +00:00
|
|
|
bool "Built-in device tree"
|
2022-05-21 19:33:57 +00:00
|
|
|
depends on OF && NONPORTABLE
|
2024-02-28 08:52:54 +00:00
|
|
|
help
|
|
|
|
Build a device tree into the Linux image.
|
|
|
|
This option should be selected if no bootloader is being used.
|
|
|
|
If unsure, say N.
|
|
|
|
|
|
|
|
|
|
|
|
config BUILTIN_DTB_SOURCE
|
|
|
|
string "Built-in device tree source"
|
|
|
|
depends on BUILTIN_DTB
|
|
|
|
help
|
|
|
|
DTS file path (without suffix, relative to arch/riscv/boot/dts)
|
|
|
|
for the DTS file that will be used to produce the DTB linked into the
|
|
|
|
kernel.
|
2020-04-14 04:43:24 +00:00
|
|
|
|
2023-12-12 13:01:14 +00:00
|
|
|
endmenu # "Boot options"
|
|
|
|
|
2022-05-21 19:33:57 +00:00
|
|
|
config PORTABLE
|
|
|
|
bool
|
|
|
|
default !NONPORTABLE
|
|
|
|
select EFI
|
|
|
|
select MMU
|
2022-12-19 17:28:37 +00:00
|
|
|
select OF
|
2022-05-21 19:33:57 +00:00
|
|
|
|
2023-10-31 11:40:47 +00:00
|
|
|
config ARCH_PROC_KCORE_TEXT
|
|
|
|
def_bool y
|
|
|
|
|
2017-07-11 01:08:08 +00:00
|
|
|
menu "Power management options"
|
|
|
|
|
2018-12-11 11:01:04 +00:00
|
|
|
source "kernel/power/Kconfig"
|
2017-07-11 01:08:08 +00:00
|
|
|
|
2023-03-30 06:43:21 +00:00
|
|
|
config ARCH_HIBERNATION_POSSIBLE
|
2023-08-02 11:12:53 +00:00
|
|
|
def_bool y
|
2023-03-30 06:43:21 +00:00
|
|
|
|
|
|
|
config ARCH_HIBERNATION_HEADER
|
|
|
|
def_bool HIBERNATION
|
|
|
|
|
2023-05-29 10:15:24 +00:00
|
|
|
config ARCH_SUSPEND_POSSIBLE
|
|
|
|
def_bool y
|
|
|
|
|
2022-05-20 12:02:30 +00:00
|
|
|
endmenu # "Power management options"
|
2020-09-17 22:37:14 +00:00
|
|
|
|
2022-02-10 05:49:40 +00:00
|
|
|
menu "CPU Power Management"
|
|
|
|
|
|
|
|
source "drivers/cpuidle/Kconfig"
|
|
|
|
|
2022-11-15 10:51:33 +00:00
|
|
|
source "drivers/cpufreq/Kconfig"
|
|
|
|
|
2022-05-20 12:02:30 +00:00
|
|
|
endmenu # "CPU Power Management"
|
2022-02-10 05:49:40 +00:00
|
|
|
|
2021-09-27 11:40:01 +00:00
|
|
|
source "arch/riscv/kvm/Kconfig"
|
2023-05-15 05:49:13 +00:00
|
|
|
|
|
|
|
source "drivers/acpi/Kconfig"
|