An error occurred fetching the project authors.
- 22 Jul, 2024 1 commit
-
-
Haibo Xu authored
x86/arm64/loongarch would select ACPI_NUMA by default and riscv would do the same thing, so change it to a hidden option and the select statements except for the X86_64_ACPI_NUMA can also go away. Suggested-by:
Arnd Bergmann <arnd@arndb.de> Suggested-by:
Sunil V L <sunilvl@ventanamicro.com> Signed-off-by:
Haibo Xu <haibo1.xu@intel.com> Reviewed-by:
Sunil V L <sunilvl@ventanamicro.com> Acked-by:
Huacai Chen <chenhuacai@loongson.cn> Acked-by:
Will Deacon <will@kernel.org> Reviewed-by:
Hanjun Guo <guohanjun@huawei.com> Link: https://lore.kernel.org/r/f1f96377b8ecd6e3183f28abf5c9ac21cb9855ea.1718268003.git.haibo1.xu@intel.comSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
- 19 May, 2024 1 commit
-
-
Samuel Holland authored
LoongArch already provides kernel_fpu_begin() and kernel_fpu_end() in asm/fpu.h, so it only needs to add kernel_fpu_available() and export the CFLAGS adjustments. Link: https://lkml.kernel.org/r/20240329072441.591471-8-samuel.holland@sifive.comSigned-off-by:
Samuel Holland <samuel.holland@sifive.com> Acked-by:
WANG Xuerui <git@xen0n.name> Reviewed-by:
Christoph Hellwig <hch@lst.de> Acked-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Borislav Petkov (AMD) <bp@alien8.de> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Dave Hansen <dave.hansen@linux.intel.com> Cc: Huacai Chen <chenhuacai@kernel.org> Cc: Ingo Molnar <mingo@redhat.com> Cc: Jonathan Corbet <corbet@lwn.net> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Nathan Chancellor <nathan@kernel.org> Cc: Nicolas Schier <nicolas@fjasle.eu> Cc: Palmer Dabbelt <palmer@rivosinc.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Will Deacon <will@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
- 14 May, 2024 5 commits
-
-
Tiezhu Yang authored
In the current code, SMP is selected in Kconfig for LoongArch, the users can not unset it, this is reasonable for a multi-processor machine. But as the help info of config SMP said, if you have a system with only one CPU, say N. On a uni-processor machine, the kernel will run faster if you say N here. Loongson-2K0500 is a single-core CPU for applications like industrial control, printing terminals, and BMC (Baseboard Management Controller), there are many development boards, products and solutions on the market, so it is better and necessary to give a chance to build with !CONFIG_SMP for a uni-processor machine. First of all, do not select SMP for config LOONGARCH in Kconfig to make it possible to unset CONFIG_SMP. Then, do some changes to fix warnings and errors if CONFIG_SMP is not set. (1) Define get_ipi_irq() only if CONFIG_SMP is set to fix the warning: arch/loongarch/kernel/irq.c:90:19: warning: 'get_ipi_irq' defined but not used [-Wunused-function] (2) Add "#ifdef CONFIG_SMP" in asm/smp.h to fix the warning: ./arch/loongarch/include/asm/smp.h:49:9: warning: "raw_smp_processor_id" redefined 49 | #define raw_smp_processor_id raw_smp_processor_id | ^~~~~~~~~~~~~~~~~~~~ ./include/linux/smp.h:198:9: note: this is the location of the previous definition 198 | #define raw_smp_processor_id() 0 (3) Define machine_shutdown() as empty under !CONFIG_SMP to fix the error: arch/loongarch/kernel/machine_kexec.c: In function 'machine_shutdown': arch/loongarch/kernel/machine_kexec.c:233:25: error: implicit declaration of function 'cpu_device_up'; did you mean 'put_device'? [-Wimplicit-function-declaration] (4) Make config SCHED_SMT depends on SMP to fix many errors such as: kernel/sched/core.c: In function 'sched_core_find': kernel/sched/core.c:310:43: error: 'struct rq' has no member named 'cpu' (5) Define cpu_logical_map(cpu) as 0 under !CONFIG_SMP in asm/smp.h, then include asm/smp.h in asm/acpi.h (because acpi.h is included in linux/irq.h indirectly) to fix many build errors under drivers/irqchip such as: drivers/irqchip/irq-loongson-eiointc.c: In function 'cpu_to_eio_node': drivers/irqchip/irq-loongson-eiointc.c:59:16: error: implicit declaration of function 'cpu_logical_map' [-Wimplicit-function-declaration] (6) Do not write per_cpu_offset(0) to PERCPU_BASE_KS when resume because the per_cpu_offset(x) macro is defined as (__per_cpu_offset[x]) only under CONFIG_SMP in include/asm-generic/percpu.h. Just save the value of PERCPU_BASE_KS when suspend and restore it when resume to fix the error: arch/loongarch/power/suspend.c: In function 'loongarch_common_resume': arch/loongarch/power/suspend.c:47:21: error: implicit declaration of function 'per_cpu_offset' [-Wimplicit-function-declaration] (7) Fix huge page handling under !CONFIG_SMP in tlbex.S. When running the UnixBench tests with "-c 1" single-streamed pass, the improvement of performance is about 9 percent with this patch. By the way, it is helpful to debug and analysis the kernel issues of multi-processor system under !CONFIG_SMP. Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Huacai Chen authored
THP_SWAP has been proven to improve the swap throughput significantly on x86_64 system according to commit bd4c82c2 ("mm, THP, swap: delay splitting THP after swapped out"), on ARM64 system according to commit d0637c50 ("arm64: enable THP_SWAP for arm64") and on RISC-V system according to commit 87f81e66 ("riscv: enable THP_SWAP for RV64"). Enable THP_SWAP for LoongArch, testing the micro-benchmark which is introduced by commit d0637c50 ("arm64: enable THP_SWAP for arm64") shows below numbers on the Loongson-3A5000 board: swp out bandwidth w/o patch: 1815716 bytes/ms (mean of 10 tests) swp out bandwidth w/ patch: 3410003 bytes/ms (mean of 10 tests) Improved by 46.75%! Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Huacai Chen authored
BPF JIT has better performance and more secure than BPF interpreter, so enable it by default, as most other architectures done. Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Xi Ruoyao authored
This allows compiling a full 128-bit product of two 64-bit integers as a mul/mulh pair, instead of a nasty long sequence of 20+ instructions. However, after selecting ARCH_SUPPORTS_INT128, when optimizing for size the compiler generates calls to __ashlti3, __ashrti3, and __lshrti3 for shifting __int128 values, causing a link failure: loongarch64-unknown-linux-gnu-ld: kernel/sched/fair.o: in function `mul_u64_u32_shr': <PATH>/include/linux/math64.h:161:(.text+0x5e4): undefined reference to `__lshrti3' So provide the implementation of these functions if ARCH_SUPPORTS_INT128. Closes: https://lore.kernel.org/loongarch/CAAhV-H5EZ=7OF7CSiYyZ8_+wWuenpo=K2WT8-6mAT4CvzUC_4g@mail.gmail.com/Signed-off-by:
Xi Ruoyao <xry111@xry111.site> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Xi Ruoyao authored
LA464 and LA664 can do 32-bit/64-bit integer multiplication with a latency of 4 cycles and a throughput of 2 ops per cycle. It is comparable to the mainstream x86 and arm64 cores, so we can select ARCH_HAS_FAST_MULTIPLIER like them. It speeds up __sw_hweight32() in lib/hweight.c for about 14% on LA464 and 11% on LA664, while __sw_hweight64() for about 30% on LA464 and 33% on LA664. Signed-off-by:
Xi Ruoyao <xry111@xry111.site> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 06 May, 2024 1 commit
-
-
Bibo Mao authored
PARAVIRT config option and PV IPI is added for the guest side, function pv_ipi_init() is used to add IPI sending and IPI receiving hooks. This function firstly checks whether system runs in VM mode, and if kernel runs in VM mode, it will call function kvm_para_available() to detect the current hypervirsor type (now only KVM type detection is supported). The paravirt functions can work only if current hypervisor type is KVM, since there is only KVM supported on LoongArch now. PV IPI uses virtual IPI sender and virtual IPI receiver functions. With virtual IPI sender, IPI message is stored in memory rather than emulated HW. IPI multicast is also supported, and 128 vcpus can received IPIs at the same time like X86 KVM method. Hypercall method is used for IPI sending. With virtual IPI receiver, HW SWI0 is used rather than real IPI HW. Since VCPU has separate HW SWI0 like HW timer, there is no trap in IPI interrupt acknowledge. Since IPI message is stored in memory, there is no trap in getting IPI message. Signed-off-by:
Bibo Mao <maobibo@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 26 Apr, 2024 1 commit
-
-
David Hildenbrand authored
Nowadays, we call it "GUP-fast", the external interface includes functions like "get_user_pages_fast()", and we renamed all internal functions to reflect that as well. Let's make the config option reflect that. Link: https://lkml.kernel.org/r/20240402125516.223131-3-david@redhat.comSigned-off-by:
David Hildenbrand <david@redhat.com> Reviewed-by:
Mike Rapoport (IBM) <rppt@kernel.org> Reviewed-by:
Jason Gunthorpe <jgg@nvidia.com> Reviewed-by:
John Hubbard <jhubbard@nvidia.com> Cc: Peter Xu <peterx@redhat.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
- 24 Apr, 2024 1 commit
-
-
Baoquan He authored
In commit 85fcde40 ("kexec: split crashkernel reservation code out from crash_core.c"), crashkernel reservation code is split out from crash_core.c, and add CRASH_RESERVE to control it. And also rename each ARCH's <asm/crash_core.h> to <asm/crash_reserve.h> accordingly. But the relevant part in LoongArch is missed. Do it now. Fixes: 85fcde40 ("kexec: split crashkernel reservation code out from crash_core.c") Signed-off-by:
Baoquan He <bhe@redhat.com> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 19 Mar, 2024 2 commits
-
-
Huacai Chen authored
This allocates the VM flag needed to support the userfaultfd minor fault functionality. See commit 7677f7fd ("userfaultfd: add minor fault registration mode") for more information. Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Huacai Chen authored
LoongArch has implemented the current_stack_pointer macro, so select ARCH_HAS_CURRENT_STACK_POINTER in Kconfig. This will let it be used in non-arch places (like HARDENED_USERCOPY). Reviewed-by:
Guo Ren <guoren@kernel.org> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 11 Mar, 2024 2 commits
-
-
Jinyang He authored
The arch-specified function ftrace_regs_set_instruction_pointer() has been implemented in arch/loongarch/include/asm/ftrace.h, so here only implement arch_stack_walk_reliable() function. Here are the test logs: [root@linux fedora]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.8.0-rc2 root=/dev/sda3 [root@linux fedora]# modprobe livepatch-sample [root@linux fedora]# cat /proc/cmdline this has been live patched [root@linux fedora]# echo 0 > /sys/kernel/livepatch/livepatch_sample/enabled [root@linux fedora]# rmmod livepatch_sample [root@linux fedora]# cat /proc/cmdline BOOT_IMAGE=/vmlinuz-6.8.0-rc2 root=/dev/sda3 [root@linux fedora]# dmesg -t | tail -5 livepatch: enabling patch 'livepatch_sample' livepatch: 'livepatch_sample': starting patching transition livepatch: 'livepatch_sample': patching complete livepatch: 'livepatch_sample': starting unpatching transition livepatch: 'livepatch_sample': unpatching complete Signed-off-by:
Jinyang He <hejinyang@loongson.cn> Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Tiezhu Yang authored
The kernel CONFIG_UNWINDER_ORC option enables the ORC unwinder, which is similar in concept to a DWARF unwinder. The difference is that the format of the ORC data is much simpler than DWARF, which in turn allows the ORC unwinder to be much simpler and faster. The ORC data consists of unwind tables which are generated by objtool. After analyzing all the code paths of a .o file, it determines information about the stack state at each instruction address in the file and outputs that information to the .orc_unwind and .orc_unwind_ip sections. The per-object ORC sections are combined at link time and are sorted and post-processed at boot time. The unwinder uses the resulting data to correlate instruction addresses with their stack states at run time. Most of the logic are similar with x86, in order to get ra info before ra is saved into stack, add ra_reg and ra_offset into orc_entry. At the same time, modify some arch-specific code to silence the objtool warnings. Co-developed-by:
Jinyang He <hejinyang@loongson.cn> Signed-off-by:
Jinyang He <hejinyang@loongson.cn> Co-developed-by:
Youling Tang <tangyouling@loongson.cn> Signed-off-by:
Youling Tang <tangyouling@loongson.cn> Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 06 Mar, 2024 1 commit
-
-
Arnd Bergmann authored
These four architectures define the same Kconfig symbols for configuring the page size. Move the logic into a common place where it can be shared with all other architectures. Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Signed-off-by:
Arnd Bergmann <arnd@arndb.de>
-
- 08 Feb, 2024 1 commit
-
-
Paolo Bonzini authored
It has no users anymore. Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com>
-
- 06 Feb, 2024 2 commits
-
-
Masahiro Yamada authored
LoongArch missed the refactoring made by commit 282a181b ("seccomp: Move config option SECCOMP to arch/Kconfig") because LoongArch was not mainlined at that time. The 'depends on PROC_FS' statement is stale as described in that commit. Select HAVE_ARCH_SECCOMP, and remove the duplicated config entry. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Masahiro Yamada authored
ARCH_ENABLE_THP_MIGRATION is supposed to be selected by arch Kconfig. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 17 Jan, 2024 3 commits
-
-
Youling Tang authored
LoongArch already supports two crashkernel regions in kexec-tools, so we can directly use the common interface to support crashkernel=X,[high,low] after commit 0ab97169 ("crash_core: add generic function to do reservation"). With the help of newly changed function parse_crashkernel() and generic reserve_crashkernel_generic(), crashkernel reservation can be simplified by steps: 1) Add a new header file <asm/crash_core.h>, then define CRASH_ALIGN, CRASH_ADDR_LOW_MAX and CRASH_ADDR_HIGH_MAX and in <asm/crash_core.h>; 2) Add arch_reserve_crashkernel() to call parse_crashkernel() and reserve_crashkernel_generic(); 3) Add ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION Kconfig in arch/loongarch/Kconfig. One can reserve the crash kernel from high memory above DMA zone range by explicitly passing "crashkernel=X,high"; or reserve a memory range below 4G with "crashkernel=X,low". Besides, there are few rules need to take notice: 1) "crashkernel=X,[high,low]" will be ignored if "crashkernel=size" is specified. 2) "crashkernel=X,low" is valid only when "crashkernel=X,high" is passed and there is enough memory to be allocated under 4G. 3) When allocating crashkernel above 4G and no "crashkernel=X,low" is specified, a 128M low memory will be allocated automatically for swiotlb bounce buffer. See Documentation/admin-guide/kernel-parameters.txt for more information. Following test cases have been performed as expected: 1) crashkernel=256M //low=256M 2) crashkernel=1G //low=1G 3) crashkernel=4G //high=4G, low=128M(default) 4) crashkernel=4G crashkernel=256M,high //high=4G, low=128M(default), high is ignored 5) crashkernel=4G crashkernel=256M,low //high=4G, low=128M(default), low is ignored 6) crashkernel=4G,high //high=4G, low=128M(default) 7) crashkernel=256M,low //low=0M, invalid 8) crashkernel=4G,high crashkernel=256M,low //high=4G, low=256M 9) crashkernel=4G,high crashkernel=4G,low //high=0M, low=0M, invalid 10) crashkernel=512M@2560M //low=512M 11) crashkernel=1G,high crashkernel=0M,low //high=1G, low=0M Recommended usage in general: 1) In the case of small memory: crashkernel=512M 2) In the case of large memory: crashkernel=1024M,high crashkernel=128M,low Signed-off-by:
Youling Tang <tangyouling@kylinos.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Binbin Zhou authored
During the upstream progress of those DT-based drivers, DT properties are changed a lot so very different from those in existing bootloaders. It is inevitably that some existing systems do not provide a standard, canonical device tree to the kernel at boot time. So let's provide a device tree table in the kernel, keyed by the dts filename, containing the relevant DTBs. We can use the built-in dts files as references. Each SoC has only one built-in dts file which describes all possible device information of that SoC, so the dts files are good examples during development. And as a reference, our built-in dts file only enables the most basic bootable combinations (so it is generic enough), acts as an alternative in case the dts in the bootloader is unexpected. Signed-off-by:
Binbin Zhou <zhoubinbin@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
WANG Rui authored
Enable initial Rust support for LoongArch. Tested-by:
Miguel Ojeda <ojeda@kernel.org> Signed-off-by:
WANG Rui <wangrui@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 06 Dec, 2023 2 commits
-
-
James Morse authored
Now that GENERIC_CPU_DEVICES calls arch_register_cpu(), which can be overridden by the arch code, switch over to this to allow common code to choose when the register_cpu() call is made. This allows topology_init() to be removed. This is an intermediate step to the logic being moved to drivers/acpi, where GENERIC_CPU_DEVICES will do the work when booting with acpi=off. This is a subtle change. Originally: - on boot, topology_init() would have marked present CPUs that io_master() is true for as hotplug-incapable. - if a CPU is hotplugged that is an io_master(), it can later be hot-unplugged. The new behaviour is that any CPU that io_master() is true for will now always be marked as hotplug-incapable, thus even if it was hotplugged, it can no longer be hot-unplugged. This patch also has the effect of moving the registration of CPUs from subsys to driver core initialisation, prior to any initcalls running. Signed-off-by:
James Morse <james.morse@arm.com> Reviewed-by:
Gavin Shan <gshan@redhat.com> Signed-off-by:
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/E1r5R41-00Ct04-Bg@rmk-PC.armlinux.org.ukSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
James Morse authored
Neither arm64 nor riscv support physical hotadd of CPUs that were not present at boot. For arm64 much of the platform description is in static tables which do not have update methods. arm64 does support HOTPLUG_CPU, which is backed by a firmware interface to turn CPUs on and off. acpi_processor_hotadd_init() and acpi_processor_remove() are for adding and removing CPUs that were not present at boot. arm64 systems that do this are not supported as there is currently insufficient information in the platform description. (e.g. did the GICR get removed too?) arm64 currently relies on the MADT enabled flag check in map_gicc_mpidr() to prevent CPUs that were not described as present at boot from being added to the system. Similarly, riscv relies on the same check in map_rintc_hartid(). Both architectures also rely on the weak 'always fails' definitions of acpi_map_cpu() and arch_register_cpu(). Subsequent changes will redefine ACPI_HOTPLUG_CPU as making possible CPUs present. Neither arm64 nor riscv support this. Disable ACPI_HOTPLUG_CPU for arm64 and riscv by removing 'default y' and selecting it on the other three ACPI architectures. This allows the weak definitions of some symbols to be removed. Signed-off-by:
James Morse <james.morse@arm.com> Reviewed-by:
Shaoqin Huang <shahuang@redhat.com> Reviewed-by:
Gavin Shan <gshan@redhat.com> Signed-off-by:
"Russell King (Oracle)" <rmk+kernel@armlinux.org.uk> Reviewed-by:
Jonathan Cameron <Jonathan.Cameron@huawei.com> Reviewed-by:
Thomas Gleixner <tglx@linutronix.de> Link: https://lore.kernel.org/r/E1r5R31-00Csyt-Jq@rmk-PC.armlinux.org.ukSigned-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 08 Nov, 2023 1 commit
-
-
Huacai Chen authored
Since commit 4e90d052 ("riscv: support PREEMPT_DYNAMIC with static keys"), the infrastructure is complete and we can simply select HAVE_PREEMPT_DYNAMIC_KEY to enable PREEMPT_DYNAMIC on LoongArch because we already support static keys. Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 02 Oct, 2023 1 commit
-
-
Tianrui Zhao authored
Enable LoongArch kvm config and add the makefile to support build kvm module. Reviewed-by:
Bibo Mao <maobibo@loongson.cn> Tested-by:
Huacai Chen <chenhuacai@loongson.cn> Signed-off-by:
Tianrui Zhao <zhaotianrui@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 06 Sep, 2023 5 commits
-
-
Qing Zhang authored
1/8 of kernel addresses reserved for shadow memory. But for LoongArch, There are a lot of holes between different segments and valid address space (256T available) is insufficient to map all these segments to kasan shadow memory with the common formula provided by kasan core, saying (addr >> KASAN_SHADOW_SCALE_SHIFT) + KASAN_SHADOW_OFFSET So LoongArch has a arch-specific mapping formula, different segments are mapped individually, and only limited space lengths of these specific segments are mapped to shadow. At early boot stage the whole shadow region populated with just one physical page (kasan_early_shadow_page). Later, this page is reused as readonly zero shadow for some memory that kasan currently don't track. After mapping the physical memory, pages for shadow memory are allocated and mapped. Functions like memset()/memcpy()/memmove() do a lot of memory accesses. If bad pointer passed to one of these function it is important to be caught. Compiler's instrumentation cannot do this since these functions are written in assembly. KASan replaces memory functions with manually instrumented variants. Original functions declared as weak symbols so strong definitions in mm/kasan/kasan.c could replace them. Original functions have aliases with '__' prefix in names, so we could call non-instrumented variant if needed. Signed-off-by:
Qing Zhang <zhangqing@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Enze Li authored
The LoongArch architecture is quite different from other architectures. When the allocating of KFENCE itself is done, it is mapped to the direct mapping configuration window [1] by default on LoongArch. It means that it is not possible to use the page table mapped mode which required by the KFENCE system and therefore it should be remapped to the appropriate region. This patch adds architecture specific implementation details for KFENCE. In particular, this implements the required interface in <asm/kfence.h>. Tested this patch by running the testcases and all passed. [1] https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#virtual-address-space-and-address-translation-modeSigned-off-by:
Enze Li <lienze@kylinos.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Feiyang Chen authored
Add ARCH_HAS_KCOV and HAVE_GCC_PLUGINS to the LoongArch Kconfig. And also disable instrumentation of vdso. Signed-off-by:
Feiyang Chen <chenfeiyang@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Qing Zhang authored
KGDB is intended to be used as a source level debugger for the Linux kernel. It is used along with gdb to debug a Linux kernel. GDB can be used to "break in" to the kernel to inspect memory, variables and regs similar to the way an application developer would use GDB to debug an application. KDB is a frontend of KGDB which is similar to GDB. By now, in addition to the generic KGDB features, the LoongArch KGDB implements the following features: - Hardware breakpoints/watchpoints; - Software single-step support for KDB. Signed-off-by: Qing Zhang <zhangqing@loongson.cn> # Framework & CoreFeature Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn> # BreakPoint & SingleStep Signed-off-by: Hui Li <lihui@loongson.cn> # Some Minor Improvements Signed-off-by: Randy Dunlap <rdunlap@infradead.org> # Some Build Error Fixes Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Qi Hu authored
Loongson Binary Translation (LBT) is used to accelerate binary translation, which contains 4 scratch registers (scr0 to scr3), x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This patch support kernel to save/restore these registers, handle the LBT exception and maintain sigcontext. Signed-off-by:
Qi Hu <huqi@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 25 Aug, 2023 1 commit
-
-
Xi Ruoyao authored
In drivers/Kconfig, drivers/firmware/Kconfig is sourced for all ports so there is no need to source it in the port-specific Kconfig file. And sourcing it here also caused the "Firmware Drivers" menu appeared two times: one in the "Device Drivers" menu, another in the toplevel menu. This is really puzzling so remove it. Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Xi Ruoyao <xry111@xry111.site> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 18 Aug, 2023 2 commits
-
-
Eric DeVolder authored
The kexec and crash kernel options are provided in the common kernel/Kconfig.kexec. Utilize the common options and provide the ARCH_SUPPORTS_ and ARCH_SELECTS_ entries to recreate the equivalent set of KEXEC and CRASH options. Link: https://lkml.kernel.org/r/20230712161545.87870-7-eric.devolder@oracle.comSigned-off-by:
Eric DeVolder <eric.devolder@oracle.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
Aneesh Kumar K.V authored
Arm disabled hugetlb vmemmap optimization [1] because hugetlb vmemmap optimization includes an update of both the permissions (writeable to read-only) and the output address (pfn) of the vmemmap ptes. That is not supported without unmapping of pte(marking it invalid) by some architectures. With DAX vmemmap optimization we don't require such pte updates and architectures can enable DAX vmemmap optimization while having hugetlb vmemmap optimization disabled. Hence split DAX optimization support into a different config. s390, loongarch and riscv don't have devdax support. So the DAX config is not enabled for them. With this change, arm64 should be able to select DAX optimization [1] commit 060a2c92 ("arm64: mm: hugetlb: Disable HUGETLB_PAGE_OPTIMIZE_VMEMMAP") Link: https://lkml.kernel.org/r/20230724190759.483013-8-aneesh.kumar@linux.ibm.comSigned-off-by:
Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Cc: Dan Williams <dan.j.williams@intel.com> Cc: Joao Martins <joao.m.martins@oracle.com> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Mike Kravetz <mike.kravetz@oracle.com> Cc: Muchun Song <muchun.song@linux.dev> Cc: Nicholas Piggin <npiggin@gmail.com> Cc: Oscar Salvador <osalvador@suse.de> Cc: Will Deacon <will@kernel.org> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org>
-
- 28 Jul, 2023 1 commit
-
-
Chenguang Zhao authored
Currently nettrace does not work on LoongArch due to missing bpf_probe_read{,str}() support, with the error message: ERROR: failed to load kprobe-based eBPF ERROR: failed to load kprobe-based bpf According to commit 0ebeea8c ("bpf: Restrict bpf_probe_read{, str}() only to archs where they work"), we only need to select CONFIG_ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE to add said support, because LoongArch does have non-overlapping address ranges for kernel and userspace. Cc: stable@vger.kernel.org # 6.1 Signed-off-by:
Chenguang Zhao <zhaochenguang@kylinos.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
- 29 Jun, 2023 6 commits
-
-
Tiezhu Yang authored
Uprobes is the user-space counterpart to kprobes, this patch adds uprobes support for LoongArch. Here is a simple example with CONFIG_UPROBE_EVENTS=y: # cat test.c #include <stdio.h> int add(int a, int b) { return a + b; } int main() { return add(2, 7); } # gcc test.c -o /tmp/test # nm /tmp/test | grep add 0000000120004194 T add # cd /sys/kernel/debug/tracing # echo > uprobe_events # echo "p:myuprobe /tmp/test:0x4194 %r4 %r5" > uprobe_events # echo "r:myuretprobe /tmp/test:0x4194 %r4" >> uprobe_events # echo 1 > events/uprobes/enable # echo 1 > tracing_on # /tmp/test # cat trace ... # TASK-PID CPU# ||||| TIMESTAMP FUNCTION # | | | ||||| | | test-1060 [001] DNZff 1015.770620: myuprobe: (0x120004194) arg1=0x2 arg2=0x7 test-1060 [001] DNZff 1015.770930: myuretprobe: (0x1200041f0 <- 0x120004194) arg1=0x9 Tested-by:
Jeff Xie <xiehuan09@gmail.com> Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Haoran Jiang authored
This is an adaptation of commit f3a112c0 ("x86,rethook,kprobes: Replace kretprobe with rethook on x86") and commit b57c2f12 ("riscv: add riscv rethook implementation") to LoongArch. Mainly refer to commit b57c2f12 ("riscv: add riscv rethook implementation"). Replaces the kretprobe code with rethook on LoongArch. With this patch, kretprobe on LoongArch uses the rethook instead of kretprobe specific trampoline code. Signed-off-by:
Haoran Jiang <jianghaoran@kylinos.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Youling Tang authored
Add support for jump labels based on the ARM64 version. Acked-by:
Peter Zijlstra (Intel) <peterz@infradead.org> Signed-off-by:
Youling Tang <tangyouling@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Tiezhu Yang authored
We can see that DEBUG_KMEMLEAK depends on HAVE_DEBUG_KMEMLEAK after commit b69ec42b ("Kconfig: clean up the long arch list for the DEBUG_KMEMLEAK config option"), just select HAVE_DEBUG_KMEMLEAK to support kmemleak on LoongArch. Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Huacai Chen authored
Loongson-3A6000 has SMT (Simultaneous Multi-Threading) support, each physical core has two logical cores (threads). This patch add SMT probe and scheduler support via ACPI PPTT. If SCHED_SMT enabled, Loongson-3A6000 is treated as 4 cores, 8 threads; If SCHED_SMT disabled, Loongson-3A6000 is treated as 8 cores, 8 threads. Remove smp_num_siblings to support HMP (Heterogeneous Multi-Processing). Signed-off-by:
Liupu Wang <wangliupu@loongson.cn> Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-
Huacai Chen authored
Add LoongArch's vector extensions support, which including 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX (i.e., Loongson Advanced SIMD eXtension). Linux kernel doesn't use vector itself, it only handle exceptions and context save/restore. So it only needs a subset of these instructions: * Vector load/store: vld vst vldx vstx xvld xvst xvldx xvstx * 8bit-elements move: vpickve2gr.b xvpickve2gr.b vinsgr2vr.b xvinsgr2vr.b * 16bit-elements move: vpickve2gr.h xvpickve2gr.h vinsgr2vr.h xvinsgr2vr.h * 32bit-elements move: vpickve2gr.w xvpickve2gr.w vinsgr2vr.w xvinsgr2vr.w * 64bit-elements move: vpickve2gr.d xvpickve2gr.d vinsgr2vr.d xvinsgr2vr.d * Elements permute: vpermi.w vpermi.d xvpermi.w xvpermi.d xvpermi.q Introduce AS_HAS_LSX_EXTENSION and AS_HAS_LASX_EXTENSION to avoid non- vector toolchains complains unsupported instructions. Signed-off-by:
Huacai Chen <chenhuacai@loongson.cn>
-