2019-05-19 15:07:45 +03:00
# SPDX-License-Identifier: GPL-2.0-only
2017-07-11 04:08:08 +03:00
#
# For a description of the syntax of this configuration file,
2019-06-12 20:52:48 +03:00
# see Documentation/kbuild/kconfig-language.rst.
2017-07-11 04:08:08 +03:00
#
2018-04-27 09:38:23 +03:00
config 64BIT
bool
config 32BIT
bool
2017-07-11 04:08:08 +03:00
config RISCV
def_bool y
2023-05-15 08:49:13 +03:00
select ACPI_GENERIC_GSI if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
2023-04-01 12:15:31 +03:00
select ARCH_DMA_DEFAULT_COHERENT
2021-08-10 16:51:05 +03:00
select ARCH_ENABLE_HUGEPAGE_MIGRATION if HUGETLB_PAGE && MIGRATION
2021-09-27 06:03:25 +03:00
select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
2022-12-19 20:28:37 +03:00
select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
2019-06-13 10:09:03 +03:00
select ARCH_HAS_BINFMT_FLAT
2022-02-24 09:04:11 +03:00
select ARCH_HAS_CURRENT_STACK_POINTER
2020-06-04 23:55:14 +03:00
select ARCH_HAS_DEBUG_VIRTUAL if MMU
2022-12-19 20:28:37 +03:00
select ARCH_HAS_DEBUG_VM_PGTABLE
2020-06-04 02:03:55 +03:00
select ARCH_HAS_DEBUG_WX
2021-02-25 10:03:03 +03:00
select ARCH_HAS_FORTIFY_SOURCE
2020-06-04 23:55:14 +03:00
select ARCH_HAS_GCOV_PROFILE_ALL
select ARCH_HAS_GIGANTIC_PAGE
2020-06-26 15:40:56 +03:00
select ARCH_HAS_KCOV
2020-06-04 23:55:14 +03:00
select ARCH_HAS_MMIOWB
2022-11-14 12:05:35 +03:00
select ARCH_HAS_PMEM_API
2020-06-04 23:55:14 +03:00
select ARCH_HAS_PTE_SPECIAL
2021-07-08 04:07:54 +03:00
select ARCH_HAS_SET_DIRECT_MAP if MMU
select ARCH_HAS_SET_MEMORY if MMU
2021-04-13 09:35:14 +03:00
select ARCH_HAS_STRICT_KERNEL_RWX if MMU && !XIP_KERNEL
select ARCH_HAS_STRICT_MODULE_RWX if MMU && !XIP_KERNEL
2021-03-07 05:24:46 +03:00
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
2021-08-04 19:30:59 +03:00
select ARCH_HAS_UBSAN_SANITIZE_ALL
2023-04-08 02:11:03 +03:00
select ARCH_HAS_VDSO_DATA
2020-06-23 08:36:59 +03:00
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
2021-08-04 19:29:08 +03:00
select ARCH_STACKWALK
select ARCH_SUPPORTS_ATOMIC_RMW
select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
2021-05-05 04:38:13 +03:00
select ARCH_SUPPORTS_HUGETLBFS if MMU
2022-06-24 11:52:36 +03:00
select ARCH_SUPPORTS_PAGE_TABLE_CHECK if MMU
2021-05-07 12:47:15 +03:00
select ARCH_USE_MEMTEST
2022-03-17 02:11:33 +03:00
select ARCH_USE_QUEUED_RWLOCKS
2020-06-04 23:55:14 +03:00
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
2017-07-11 04:08:08 +03:00
select ARCH_WANT_FRAME_POINTERS
2023-02-09 16:16:46 +03:00
select ARCH_WANT_GENERAL_HUGETLB if !RISCV_ISA_SVNAPOT
2020-06-04 23:55:14 +03:00
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
2023-01-19 18:54:17 +03:00
select ARCH_WANT_LD_ORPHAN_WARN if !XIP_KERNEL
2023-04-29 12:27:33 +03:00
select ARCH_WANT_OPTIMIZE_VMEMMAP
2022-08-29 17:57:42 +03:00
select ARCH_WANTS_THP_SWAP if HAVE_ARCH_TRANSPARENT_HUGEPAGE
2021-04-17 04:10:09 +03:00
select BINFMT_FLAT_NO_DATA_START_OFFSET if !MMU
2021-08-26 17:10:29 +03:00
select BUILDTIME_TABLE_SORT if MMU
2020-09-14 19:56:30 +03:00
select CLINT_TIMER if !MMU
2022-12-19 20:28:37 +03:00
select CLONE_BACKWARDS
2017-07-11 04:08:08 +03:00
select COMMON_CLK
2023-03-30 09:43:21 +03:00
select CPU_PM if CPU_IDLE || HIBERNATION
2020-06-04 23:55:14 +03:00
select EDAC_SUPPORT
2022-07-15 20:51:56 +03:00
select GENERIC_ARCH_TOPOLOGY
2020-06-04 23:55:14 +03:00
select GENERIC_ATOMIC64 if !64BIT
2021-03-07 05:24:46 +03:00
select GENERIC_CLOCKEVENTS_BROADCAST if SMP
2020-09-18 01:37:11 +03:00
select GENERIC_EARLY_IOREMAP
2023-02-22 06:30:18 +03:00
select GENERIC_ENTRY
2020-06-09 17:14:48 +03:00
select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
2021-07-08 04:59:48 +03:00
select GENERIC_IDLE_POLL_SETUP
2021-09-08 05:55:58 +03:00
select GENERIC_IOREMAP if MMU
2023-03-28 06:52:19 +03:00
select GENERIC_IRQ_IPI if SMP
select GENERIC_IRQ_IPI_MUX if SMP
2020-06-04 23:55:14 +03:00
select GENERIC_IRQ_MULTI_HANDLER
2017-07-11 04:08:08 +03:00
select GENERIC_IRQ_SHOW
2021-07-08 04:59:49 +03:00
select GENERIC_IRQ_SHOW_LEVEL
2020-07-09 21:51:17 +03:00
select GENERIC_LIB_DEVMEM_IS_ALLOWED
2017-07-11 04:08:08 +03:00
select GENERIC_PCI_IOMAP
2020-06-04 23:55:14 +03:00
select GENERIC_PTDUMP if MMU
2018-12-04 13:29:51 +03:00
select GENERIC_SCHED_CLOCK
2020-06-04 23:55:14 +03:00
select GENERIC_SMP_IDLE_THREAD
2020-06-09 17:14:48 +03:00
select GENERIC_TIME_VSYSCALL if MMU && 64BIT
2021-09-01 06:20:25 +03:00
select GENERIC_VDSO_TIME_NS if HAVE_GENERIC_VDSO
2022-07-29 14:11:17 +03:00
select HARDIRQS_SW_RESEND
2023-03-23 19:33:52 +03:00
select HAS_IOPORT if MMU
2018-10-29 13:48:53 +03:00
select HAVE_ARCH_AUDITSYSCALL
2022-10-12 15:00:38 +03:00
select HAVE_ARCH_HUGE_VMALLOC if HAVE_ARCH_HUGE_VMAP
2022-10-12 15:00:37 +03:00
select HAVE_ARCH_HUGE_VMAP if MMU && 64BIT && !XIP_KERNEL
2021-05-10 19:28:38 +03:00
select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE if !XIP_KERNEL
2020-06-04 23:55:14 +03:00
select HAVE_ARCH_KASAN if MMU && 64BIT
2021-01-16 08:58:35 +03:00
select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
2021-06-15 06:07:34 +03:00
select HAVE_ARCH_KFENCE if MMU && 64BIT
2021-05-10 19:28:38 +03:00
select HAVE_ARCH_KGDB if !XIP_KERNEL
2020-06-04 23:55:14 +03:00
select HAVE_ARCH_KGDB_QXFER_PKT
select HAVE_ARCH_MMAP_RND_BITS if MMU
2022-04-05 10:13:14 +03:00
select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
2019-10-05 03:12:22 +03:00
select HAVE_ARCH_SECCOMP_FILTER
2022-12-19 20:28:37 +03:00
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
2020-06-04 23:55:14 +03:00
select HAVE_ARCH_TRACEHOOK
2021-07-09 20:36:29 +03:00
select HAVE_ARCH_TRANSPARENT_HUGEPAGE if 64BIT && MMU
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 06:28:55 +03:00
select HAVE_ARCH_VMAP_STACK if MMU && 64BIT
2019-08-19 08:54:20 +03:00
select HAVE_ASM_MODVERSIONS
2022-06-08 17:40:24 +03:00
select HAVE_CONTEXT_TRACKING_USER
2020-06-27 13:50:50 +03:00
select HAVE_DEBUG_KMEMLEAK
2019-10-28 15:10:41 +03:00
select HAVE_DMA_CONTIGUOUS if MMU
2020-06-04 23:55:14 +03:00
select HAVE_EBPF_JIT if MMU
2022-12-19 20:28:37 +03:00
select HAVE_FUNCTION_ARG_ACCESS_API
2020-12-17 19:01:45 +03:00
select HAVE_FUNCTION_ERROR_INJECTION
2020-06-26 15:40:56 +03:00
select HAVE_GCC_PLUGINS
2020-06-09 17:14:48 +03:00
select HAVE_GENERIC_VDSO if MMU && 64BIT
2020-10-28 07:28:42 +03:00
select HAVE_IRQ_TIME_ACCOUNTING
2021-05-10 19:28:38 +03:00
select HAVE_KPROBES if !XIP_KERNEL
select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL
select HAVE_KRETPROBES if !XIP_KERNEL
2022-10-25 18:18:32 +03:00
select HAVE_RETHOOK if !XIP_KERNEL
2021-04-16 19:37:22 +03:00
select HAVE_MOVE_PMD
select HAVE_MOVE_PUD
2020-06-04 23:55:14 +03:00
select HAVE_PCI
2018-04-20 02:27:49 +03:00
select HAVE_PERF_EVENTS
2019-09-05 06:46:35 +03:00
select HAVE_PERF_REGS
select HAVE_PERF_USER_STACK_DUMP
2022-10-02 07:49:31 +03:00
select HAVE_POSIX_CPU_TIMERS_TASK_WORK
2020-12-17 19:01:37 +03:00
select HAVE_REGS_AND_STACK_ACCESS_API
2022-12-19 20:28:37 +03:00
select HAVE_RSEQ
2020-07-10 19:19:57 +03:00
select HAVE_STACKPROTECTOR
2018-12-06 18:26:35 +03:00
select HAVE_SYSCALL_TRACEPOINTS
2017-07-11 04:08:08 +03:00
select IRQ_DOMAIN
2021-07-08 04:59:47 +03:00
select IRQ_FORCED_THREADING
2023-02-03 10:52:32 +03:00
select KASAN_VMALLOC if KASAN
2017-07-11 04:08:08 +03:00
select MODULES_USE_ELF_RELA if MODULES
RISC-V: Support MODULE_SECTIONS mechanism on RV32
This patch supports dynamic generate got and plt sections mechanism on
rv32. It contains the modification as follows:
- Always enable MODULE_SECTIONS (both rv64 and rv32)
- Change the fixed size type.
This patch had been tested by following modules:
btrfs 6795991 0 - Live 0xa544b000
test_static_keys 17304 0 - Live 0xa28be000
zstd_compress 1198986 1 btrfs, Live 0xa2a25000
zstd_decompress 608112 1 btrfs, Live 0xa24e7000
lzo 8787 0 - Live 0xa2049000
xor 27461 1 btrfs, Live 0xa2041000
zram 78849 0 - Live 0xa2276000
netdevsim 55909 0 - Live 0xa202d000
tun 211534 0 - Live 0xa21b5000
fuse 566049 0 - Live 0xa25fb000
nfs_layout_flexfiles 192597 0 - Live 0xa229b000
ramoops 74895 0 - Live 0xa2019000
xfs 3973221 0 - Live 0xa507f000
libcrc32c 3053 2 btrfs,xfs, Live 0xa34af000
lzo_compress 17302 2 btrfs,lzo, Live 0xa347d000
lzo_decompress 7178 2 btrfs,lzo, Live 0xa3451000
raid6_pq 142086 1 btrfs, Live 0xa33a4000
reed_solomon 31022 1 ramoops, Live 0xa31eb000
test_bitmap 3734 0 - Live 0xa31af000
test_bpf 1588736 0 - Live 0xa2c11000
test_kmod 41161 0 - Live 0xa29f8000
test_module 1356 0 - Live 0xa299e000
test_printf 6024 0 [permanent], Live 0xa2971000
test_static_key_base 5797 1 test_static_keys, Live 0xa2931000
test_user_copy 4382 0 - Live 0xa28c9000
xxhash 70501 2 zstd_compress,zstd_decompress, Live 0xa2055000
Signed-off-by: Zong Li <zong@andestech.com>
Signed-off-by: Palmer Dabbelt <palmer@sifive.com>
2018-12-07 12:02:16 +03:00
select MODULE_SECTIONS if MODULES
2020-06-04 23:55:14 +03:00
select OF
select OF_EARLY_FLATTREE
select OF_IRQ
2018-11-15 22:05:33 +03:00
select PCI_DOMAINS_GENERIC if PCI
2018-11-15 22:05:32 +03: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 13:05:39 +03:00
select RISCV_ALTERNATIVE if !XIP_KERNEL
2020-06-01 12:15:43 +03:00
select RISCV_INTC
2020-08-17 15:42:50 +03:00
select RISCV_TIMER if RISCV_SBI
2022-11-18 13:43:01 +03:00
select SIFIVE_PLIC
2020-06-04 23:55:14 +03:00
select SPARSE_IRQ
select SYSCTL_EXCEPTION_TRACE
select THREAD_INFO_IN_TASK
2021-07-31 08:22:32 +03:00
select TRACE_IRQFLAGS_SUPPORT
2020-09-07 08:58:22 +03:00
select UACCESS_MEMCPY if !MMU
2021-07-01 04:52:20 +03:00
select ZONE_DMA32 if 64BIT
2023-04-04 23:34:21 +03:00
select HAVE_DYNAMIC_FTRACE if !XIP_KERNEL && MMU && (CLANG_SUPPORTS_DYNAMIC_FTRACE || GCC_SUPPORTS_DYNAMIC_FTRACE)
2022-11-15 23:08:32 +03:00
select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD if !XIP_KERNEL
select HAVE_FUNCTION_GRAPH_TRACER
2023-01-12 12:05:57 +03:00
select HAVE_FUNCTION_TRACER if !XIP_KERNEL && !PREEMPTION
2019-09-24 01:39:21 +03:00
2023-04-04 23:34:21 +03:00
config CLANG_SUPPORTS_DYNAMIC_FTRACE
def_bool CC_IS_CLANG
# https://github.com/llvm/llvm-project/commit/6ab8927931851bb42b2c93a00801dc499d7d9b1e
depends on CLANG_VERSION >= 130000
# 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)
2019-09-24 01:39:21 +03:00
config ARCH_MMAP_RND_BITS_MIN
default 18 if 64BIT
default 8
2022-04-05 10:13:14 +03:00
config ARCH_MMAP_RND_COMPAT_BITS_MIN
default 8
2019-09-24 01:39:21 +03: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 04:08:08 +03:00
2022-04-05 10:13:14 +03:00
config ARCH_MMAP_RND_COMPAT_BITS_MAX
default 17
2019-10-28 15:10:32 +03:00
# set if we run in machine mode, cleared if we run in supervisor mode
config RISCV_M_MODE
bool
2019-10-28 15:10:41 +03:00
default !MMU
2019-10-28 15:10:32 +03:00
2019-10-28 15:10:33 +03: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 04:08:08 +03:00
config MMU
2019-10-28 15:10:41 +03: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 04:08:08 +03:00
config PAGE_OFFSET
hex
2023-03-01 03:26:56 +03:00
default 0xC0000000 if 32BIT && MMU
default 0x80000000 if !MMU
2022-01-27 05:48:43 +03:00
default 0xff60000000000000 if 64BIT
2017-07-11 04:08:08 +03:00
2021-10-29 07:59:27 +03:00
config KASAN_SHADOW_OFFSET
hex
depends on KASAN_GENERIC
2021-12-06 13:46:45 +03:00
default 0xdfffffff00000000 if 64BIT
2021-10-29 07:59:27 +03:00
default 0xffffffff if 32BIT
2019-08-29 00:40:54 +03:00
config ARCH_FLATMEM_ENABLE
2020-11-19 03:38:29 +03:00
def_bool !NUMA
2019-08-29 00:40:54 +03:00
config ARCH_SPARSEMEM_ENABLE
def_bool y
2020-02-12 13:34:24 +03:00
depends on MMU
2021-03-29 06:13:07 +03:00
select SPARSEMEM_STATIC if 32BIT && SPARSEMEM
2021-03-15 15:03:07 +03:00
select SPARSEMEM_VMEMMAP_ENABLE if 64BIT
2019-08-29 00:40:54 +03:00
config ARCH_SELECT_MEMORY_MODEL
def_bool ARCH_SPARSEMEM_ENABLE
2020-12-17 19:01:44 +03:00
config ARCH_SUPPORTS_UPROBES
def_bool y
2017-07-11 04:08:08 +03: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 18:27:01 +03:00
config FIX_EARLYCON_MEM
2019-12-17 14:15:16 +03:00
def_bool MMU
2019-01-07 18:27:01 +03:00
2017-07-11 04:08:08 +03:00
config PGTABLE_LEVELS
int
2022-01-27 05:48:43 +03:00
default 5 if 64BIT
2017-07-11 04:08:08 +03:00
default 2
2020-06-27 16:57:08 +03:00
config LOCKDEP_SUPPORT
def_bool y
2022-07-07 02:15:35 +03:00
config RISCV_DMA_NONCOHERENT
bool
select ARCH_HAS_DMA_PREP_COHERENT
select ARCH_HAS_SETUP_DMA_OPS
2022-12-19 20:28:37 +03:00
select ARCH_HAS_SYNC_DMA_FOR_CPU
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
2022-07-07 02:15:35 +03:00
select DMA_DIRECT_REMAP
2022-10-02 07:48:07 +03: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 14:07:20 +03:00
config AS_HAS_OPTION_ARCH
# https://reviews.llvm.org/D123515
def_bool y
depends on $(as-instr, .option arch$(comma) +m)
depends on !$(as-instr, .option arch$(comma) -i)
2019-06-17 22:29:48 +03:00
source "arch/riscv/Kconfig.socs"
2023-02-24 18:45:57 +03:00
source "arch/riscv/Kconfig.errata"
2019-06-17 22:29:48 +03:00
2017-07-11 04:08:08 +03:00
menu "Platform type"
2022-05-21 22:33:57 +03: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 04:08:08 +03:00
choice
prompt "Base ISA"
default ARCH_RV64I
help
2019-01-08 22:45:57 +03:00
This selects the base ISA that this kernel will target and must match
2017-07-11 04:08:08 +03:00
the target platform.
config ARCH_RV32I
bool "RV32I"
2022-05-21 22:33:57 +03:00
depends on NONPORTABLE
2017-07-11 04:08:08 +03:00
select 32BIT
2018-04-11 10:50:17 +03:00
select GENERIC_LIB_ASHLDI3
select GENERIC_LIB_ASHRDI3
select GENERIC_LIB_LSHRDI3
2018-06-25 11:49:38 +03:00
select GENERIC_LIB_UCMPDI2
2017-07-11 04:08:08 +03:00
config ARCH_RV64I
bool "RV64I"
select 64BIT
2021-09-11 02:40:42 +03:00
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128
2019-10-28 15:10:41 +03:00
select SWIOTLB if MMU
2017-07-11 04:08:08 +03: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 11:50:41 +03:00
config MODULE_SECTIONS
bool
select HAVE_MOD_ARCH_SPECIFIC
2017-07-11 04:08:08 +03: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 14:03:36 +03: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 04:08:08 +03:00
config NR_CPUS
2022-04-20 14:24:08 +03:00
int "Maximum number of CPUs (2-512)"
2017-07-11 04:08:08 +03:00
depends on SMP
2022-11-26 09:15:56 +03: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 14:24:08 +03:00
default "32" if 32BIT
default "64" if 64BIT
2017-07-11 04:08:08 +03:00
2020-03-18 04:11:44 +03: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 04:08:08 +03:00
choice
prompt "CPU Tuning"
default TUNE_GENERIC
config TUNE_GENERIC
bool "generic"
endchoice
2020-11-19 03:38:29 +03:00
# Common NUMA Features
config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
2021-03-30 16:25:31 +03:00
depends on SMP && MMU
2022-12-19 20:28:37 +03:00
select ARCH_SUPPORTS_NUMA_BALANCING
2020-11-19 03:38:29 +03:00
select GENERIC_ARCH_NUMA
2022-12-19 20:28:37 +03:00
select NEED_PER_CPU_EMBED_FIRST_CHUNK
2020-11-19 03:38:29 +03: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 05:07:41 +03:00
select USE_PERCPU_NUMA_NODE_ID
2020-11-19 03:38:29 +03: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 05:43:01 +03:00
depends on NUMA
2020-11-19 03:38:29 +03:00
help
Specify the maximum number of NUMA Nodes available on the target
system. Increases memory reserved to accommodate various tables.
2022-05-11 22:29:10 +03:00
config RISCV_ALTERNATIVE
bool
depends on !XIP_KERNEL
help
This Kconfig allows the kernel to automatically patch the
2023-02-24 18:45:59 +03: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 22:29:10 +03:00
2022-05-11 22:29:21 +03:00
config RISCV_ALTERNATIVE_EARLY
bool
depends on RISCV_ALTERNATIVE
help
Allows early patching of the kernel for special errata
2017-07-11 04:08:08 +03:00
config RISCV_ISA_C
bool "Emit compressed instructions when building Linux"
default y
help
2022-05-20 15:02:30 +03: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 04:08:08 +03:00
2022-05-20 15:02:30 +03:00
If you don't know what to do here, say Y.
2017-07-11 04:08:08 +03:00
2023-02-09 16:16:45 +03:00
config RISCV_ISA_SVNAPOT
2023-04-05 13:21:10 +03:00
bool "Svnapot extension support for supervisor mode NAPOT pages"
2023-02-09 16:16:45 +03:00
depends on 64BIT && MMU
2023-03-24 15:12:41 +03:00
depends on RISCV_ALTERNATIVE
2023-02-09 16:16:45 +03:00
default y
help
2023-04-05 13:21:10 +03:00
Allow kernel to detect the Svnapot ISA-extension dynamically at boot
2023-02-09 16:16:45 +03:00
time and enable its usage.
2023-04-05 13:21:10 +03:00
The Svnapot extension is used to mark contiguous PTEs as a range
2023-02-09 16:16:45 +03: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 13:21:10 +03:00
the Svnapot extension, it may be better to say N here.
2023-02-09 16:16:45 +03:00
If you don't know what to do here, say Y.
2022-05-11 22:29:18 +03:00
config RISCV_ISA_SVPBMT
2023-04-05 13:21:10 +03:00
bool "Svpbmt extension support for supervisor mode page-based memory types"
2022-05-11 22:29:18 +03: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 13:05:39 +03:00
depends on RISCV_ALTERNATIVE
2022-05-11 22:29:18 +03:00
default y
help
2023-04-05 13:21:10 +03:00
Adds support to dynamically detect the presence of the Svpbmt
2022-05-26 23:56:43 +03: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 22:29:18 +03:00
2023-04-05 13:21:10 +03:00
The Svpbmt extension is only available on 64-bit cpus.
2022-05-11 22:29:18 +03:00
If you don't know what to do here, say Y.
2023-06-05 14:07:21 +03:00
config TOOLCHAIN_HAS_V
bool
default y
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64iv)
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32iv)
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.
2023-01-14 00:23:01 +03:00
config TOOLCHAIN_HAS_ZBB
2022-07-07 02:15:35 +03:00
bool
2022-10-06 20:35:20 +03:00
default y
2023-01-14 00:23:01 +03: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 14:07:20 +03:00
depends on AS_HAS_OPTION_ARCH
2023-01-14 00:23:01 +03: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 13:05:39 +03:00
depends on MMU
depends on RISCV_ALTERNATIVE
2023-01-14 00:23:01 +03: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-07 02:15:35 +03: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 13:05:39 +03:00
depends on MMU
depends on RISCV_ALTERNATIVE
2022-07-07 02:15:35 +03:00
default y
2022-12-19 20:28:37 +03:00
select RISCV_DMA_NONCOHERENT
2022-07-07 02:15:35 +03: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 19:26:29 +03:00
config RISCV_ISA_ZICBOZ
bool "Zicboz extension support for faster zeroing of memory"
2023-03-24 15:12:41 +03:00
depends on MMU
depends on RISCV_ALTERNATIVE
2023-02-24 19:26:29 +03:00
default y
help
2023-04-05 13:21:10 +03:00
Enable the use of the Zicboz extension (cbo.zero instruction)
2023-02-24 19:26:29 +03:00
when available.
The Zicboz extension is used for faster zeroing of memory.
If you don't know what to do here, say Y.
2022-10-06 20:35:21 +03:00
config TOOLCHAIN_HAS_ZIHINTPAUSE
bool
default y
depends on !64BIT || $(cc-option,-mabi=lp64 -march=rv64ima_zihintpause)
depends on !32BIT || $(cc-option,-mabi=ilp32 -march=rv32ima_zihintpause)
depends on LLD_VERSION >= 150000 || LD_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-14 02:00:23 +03:00
config TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
def_bool y
# https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=aed44286efa8ae8717a77d94b51ac3614e2ca6dc
depends on AS_IS_GNU && AS_VERSION >= 23800
help
Newer binutils versions default to ISA spec version 20191213 which
moves some instructions from the I extension to the Zicsr and Zifencei
extensions.
config TOOLCHAIN_NEEDS_OLD_ISA_SPEC
def_bool y
depends on TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI
# https://github.com/llvm/llvm-project/commit/22e199e6afb1263c943c0c0d4498694e15bf8a16
depends on CC_IS_CLANG && CLANG_VERSION < 170000
help
Certain versions of clang do not support zicsr and zifencei via -march
but newer versions of binutils require it for the reasons noted in the
help text of CONFIG_TOOLCHAIN_NEEDS_EXPLICIT_ZICSR_ZIFENCEI. This
option causes an older ISA spec compatible with these older versions
of clang to be passed to GAS, which has the same result as passing zicsr
and zifencei to -march.
2018-10-09 05:18:33 +03: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.
2022-05-20 15:02:30 +03:00
endmenu # "Platform type"
2017-07-11 04:08:08 +03:00
2018-09-20 01:48:15 +03:00
menu "Kernel features"
2017-07-11 04:08:08 +03:00
source "kernel/Kconfig.hz"
2020-03-18 04:11:37 +03: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 03:55:36 +03:00
2022-01-20 12:09:17 +03:00
config RISCV_BOOT_SPINWAIT
bool "Spinwait booting method"
depends on SMP
2022-04-21 20:03:55 +03:00
default y if RISCV_SBI_V01 || RISCV_M_MODE
2022-01-20 12:09:17 +03: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 20:03:55 +03: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.
2021-04-19 03:55:36 +03:00
config KEXEC
bool "Kexec system call"
depends on MMU
2022-12-19 20:28:37 +03:00
select HOTPLUG_CPU if SMP
select KEXEC_CORE
2021-04-19 03:55:36 +03:00
help
kexec is a system call that implements the ability to shutdown your
current kernel, and to start another kernel. It is like a reboot
but it is independent of the system firmware. And like a reboot
you can start any kernel with it, not just Linux.
The name comes from the similarity to the exec system call.
2022-04-08 13:09:11 +03:00
config KEXEC_FILE
bool "kexec file based systmem call"
2022-12-19 20:28:37 +03:00
depends on 64BIT && MMU
select HAVE_IMA_KEXEC if IMA
2022-04-08 13:09:11 +03:00
select KEXEC_CORE
select KEXEC_ELF
help
This is new version of kexec system call. This system call is
file based and takes file descriptors as system call argument
for kernel and initramfs as opposed to list of segments as
accepted by previous system call.
If you don't know what to do here, say Y.
2022-04-08 13:09:13 +03:00
config ARCH_HAS_KEXEC_PURGATORY
def_bool KEXEC_FILE
depends on CRYPTO=y
depends on CRYPTO_SHA256=y
2021-04-19 03:55:39 +03:00
config CRASH_DUMP
bool "Build kdump crash kernel"
help
Generate crash dump after being started by kexec. This should
be normally only set in special crash dump kernels which are
loaded in the main kernel with kexec-tools into a specially
reserved region and then later executed after a crash by
kdump/kexec.
For more details see Documentation/admin-guide/kdump/kdump.rst
2021-04-19 03:55:36 +03:00
2022-04-05 10:13:14 +03: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-03-29 07:53:26 +03:00
config RELOCATABLE
bool "Build a relocatable kernel"
depends on MMU && 64BIT && !XIP_KERNEL
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.
2022-05-20 15:02:30 +03:00
endmenu # "Kernel features"
2017-07-11 04:08:08 +03:00
2018-09-20 01:48:15 +03:00
menu "Boot options"
2018-11-18 03:06:56 +03:00
config CMDLINE
string "Built-in kernel command line"
2018-09-20 01:48:15 +03:00
help
2018-11-18 03:06:56 +03: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-20 01:48:15 +03:00
2018-11-18 03:06:56 +03: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-20 01:48:15 +03:00
2018-11-18 03:06:56 +03:00
choice
prompt "Built-in command line usage" if CMDLINE != ""
default CMDLINE_FALLBACK
help
Choose how the kernel will handle the provided built-in command
line.
2018-09-20 01:48:15 +03:00
2018-11-18 03:06:56 +03:00
config CMDLINE_FALLBACK
bool "Use bootloader kernel arguments if available"
2018-09-20 01:48:15 +03:00
help
2018-11-18 03:06:56 +03: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-20 01:48:15 +03:00
config CMDLINE_FORCE
2018-11-18 03:06:56 +03:00
bool "Always use the default kernel command string"
2018-09-20 01:48:15 +03:00
help
2018-11-18 03:06:56 +03: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-20 01:48:15 +03:00
2018-11-18 03:06:56 +03:00
endchoice
2018-09-20 01:48:15 +03:00
2020-09-18 01:37:14 +03:00
config EFI_STUB
bool
config EFI
bool "UEFI runtime support"
2021-04-13 09:35:14 +03:00
depends on OF && !XIP_KERNEL
2022-12-19 20:28:37 +03:00
depends on MMU
default y
2023-05-15 08:49:13 +03:00
select ARCH_SUPPORTS_ACPI if 64BIT
2020-09-18 01:37:14 +03:00
select EFI_GENERIC_STUB
2022-12-19 20:28:37 +03:00
select EFI_PARAMS_FROM_FDT
2020-09-18 01:37:15 +03:00
select EFI_RUNTIME_WRAPPERS
2022-12-19 20:28:37 +03:00
select EFI_STUB
select LIBFDT
2020-09-18 01:37:14 +03:00
select RISCV_ISA_C
2022-12-19 20:28:37 +03:00
select UCS2_STRING
2020-09-18 01:37:14 +03: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.
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 19:29:18 +03: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 23:55:00 +03: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 19:29:18 +03:00
depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS
2021-07-21 10:59:36 +03:00
config PHYS_RAM_BASE_FIXED
bool "Explicitly specified physical RAM address"
2022-05-21 22:33:57 +03:00
depends on NONPORTABLE
2021-07-21 10:59:36 +03:00
default n
2021-04-13 09:35:14 +03:00
config PHYS_RAM_BASE
hex "Platform Physical RAM address"
2021-07-21 10:59:36 +03:00
depends on PHYS_RAM_BASE_FIXED
2021-04-13 09:35:14 +03: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 22:33:57 +03:00
depends on MMU && SPARSEMEM && NONPORTABLE
2021-04-13 09:35:14 +03: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 10:59:36 +03:00
select PHYS_RAM_BASE_FIXED
2021-04-13 09:35:14 +03: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.
2022-05-20 15:02:30 +03:00
endmenu # "Boot options"
2018-09-20 01:48:15 +03:00
2020-04-14 07:43:24 +03:00
config BUILTIN_DTB
2021-04-13 09:35:14 +03:00
bool
2022-05-21 22:33:57 +03:00
depends on OF && NONPORTABLE
2021-04-13 09:35:14 +03:00
default y if XIP_KERNEL
2020-04-14 07:43:24 +03:00
2022-05-21 22:33:57 +03:00
config PORTABLE
bool
default !NONPORTABLE
select EFI
select MMU
2022-12-19 20:28:37 +03:00
select OF
2022-05-21 22:33:57 +03:00
2017-07-11 04:08:08 +03:00
menu "Power management options"
2018-12-11 14:01:04 +03:00
source "kernel/power/Kconfig"
2017-07-11 04:08:08 +03:00
2023-03-30 09:43:21 +03:00
config ARCH_HIBERNATION_POSSIBLE
def_bool y
config ARCH_HIBERNATION_HEADER
def_bool HIBERNATION
2022-05-20 15:02:30 +03:00
endmenu # "Power management options"
2020-09-18 01:37:14 +03:00
2022-02-10 08:49:40 +03:00
menu "CPU Power Management"
source "drivers/cpuidle/Kconfig"
2022-11-15 13:51:33 +03:00
source "drivers/cpufreq/Kconfig"
2022-05-20 15:02:30 +03:00
endmenu # "CPU Power Management"
2022-02-10 08:49:40 +03:00
2021-09-27 14:40:01 +03:00
source "arch/riscv/kvm/Kconfig"
2023-05-15 08:49:13 +03:00
source "drivers/acpi/Kconfig"