LoongArch: Enable jump table for objtool

For now, it is time to remove -fno-jump-tables to enable jump table for
objtool if the compiler has -mannotate-tablejump, otherwise it is better
to remain -f

LoongArch: Enable jump table for objtool

For now, it is time to remove -fno-jump-tables to enable jump table for
objtool if the compiler has -mannotate-tablejump, otherwise it is better
to remain -fno-jump-tables to keep compatibility with older compilers.

Signed-off-by: Tiezhu Yang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Acked-by: Huacai Chen <[email protected]>
Signed-off-by: Josh Poimboeuf <[email protected]>

show more ...

LoongArch: Explicitly specify code model in Makefile

LoongArch's toolchain may change the default code model from normal to
medium. This is unnecessary for kernel, and generates some relocations
whi

LoongArch: Explicitly specify code model in Makefile

LoongArch's toolchain may change the default code model from normal to
medium. This is unnecessary for kernel, and generates some relocations
which cannot be handled by the module loader. So explicitly specify the
code model to normal in Makefile (for Rust 'normal' is 'small').

Cc: [email protected]
Tested-by: Haiyong Sun <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Use rustc option -Zdirect-access-external-data

-Zdirect-access-external-data is a new Rust compiler option added in
Rust 1.78, which we use to optimize the access of external data in the

LoongArch: Use rustc option -Zdirect-access-external-data

-Zdirect-access-external-data is a new Rust compiler option added in
Rust 1.78, which we use to optimize the access of external data in the
Linux kernel's Rust code. This patch modifies the Rust code in vmlinux
to directly access externa data, using PC-REL instead of GOT. However,
Rust code whithin modules is constrained by the PC-REL addressing range
and is explicitly set to use an indirect method.

Acked-by: Miguel Ojeda <[email protected]>
Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: implement ARCH_HAS_KERNEL_FPU_SUPPORT

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

LoongArch: implement ARCH_HAS_KERNEL_FPU_SUPPORT

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/[email protected]
Signed-off-by: Samuel Holland <[email protected]>
Acked-by: WANG Xuerui <[email protected]>
Reviewed-by: Christoph Hellwig <[email protected]>
Acked-by: Christian König <[email protected]>
Cc: Alex Deucher <[email protected]>
Cc: Borislav Petkov (AMD) <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Dave Hansen <[email protected]>
Cc: Huacai Chen <[email protected]>
Cc: Ingo Molnar <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Masahiro Yamada <[email protected]>
Cc: Michael Ellerman <[email protected]>
Cc: Nathan Chancellor <[email protected]>
Cc: Nicolas Schier <[email protected]>
Cc: Palmer Dabbelt <[email protected]>
Cc: Russell King <[email protected]>
Cc: Thomas Gleixner <[email protected]>
Cc: Will Deacon <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>

show more ...

LoongArch: rust: Switch to use built-in rustc target

This commit switches to use the LoongArch's built-in rustc target
'loongarch64-unknown-none-softfloat'. The Rust samples have been tested.

Acked

LoongArch: rust: Switch to use built-in rustc target

This commit switches to use the LoongArch's built-in rustc target
'loongarch64-unknown-none-softfloat'. The Rust samples have been tested.

Acked-by: Miguel Ojeda <[email protected]>
Tested-by: Miguel Ojeda <[email protected]>
Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Add ORC stack unwinder support

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 OR

LoongArch: Add ORC stack unwinder support

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 <[email protected]>
Signed-off-by: Jinyang He <[email protected]>
Co-developed-by: Youling Tang <[email protected]>
Signed-off-by: Youling Tang <[email protected]>
Signed-off-by: Tiezhu Yang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

rust: Refactor the build target to allow the use of builtin targets

Eventually we want all architectures to be using the target as defined
by rustc. However currently some architectures can't do tha

rust: Refactor the build target to allow the use of builtin targets

Eventually we want all architectures to be using the target as defined
by rustc. However currently some architectures can't do that and are
using the target.json specification. This puts in place the foundation
to allow the use of the builtin target definition or a target.json
specification.

Signed-off-by: Jamie Cunliffe <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Tested-by: Alice Ryhl <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
[[email protected]: squashed loongarch ifneq fix from WANG Rui]
Signed-off-by: Catalin Marinas <[email protected]>

show more ...

LoongArch: Allow device trees be built into the kernel

During the upstream progress of those DT-based drivers, DT properties
are changed a lot so very different from those in existing bootloaders.
I

LoongArch: Allow device trees be built into the kernel

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 <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Enable initial Rust support

Enable initial Rust support for LoongArch.

Tested-by: Miguel Ojeda <[email protected]>
Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen

LoongArch: Enable initial Rust support

Enable initial Rust support for LoongArch.

Tested-by: Miguel Ojeda <[email protected]>
Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Apply dynamic relocations for LLD

For the following assembly code:

.text
.global func
func:
nop

.data
var:
.dword func

When linked with `-pie`, GNU LD popula

LoongArch: Apply dynamic relocations for LLD

For the following assembly code:

.text
.global func
func:
nop

.data
var:
.dword func

When linked with `-pie`, GNU LD populates the `var` variable with the
pre-relocated value of `func`. However, LLVM LLD does not exhibit the
same behavior. This issue also arises with the `kernel_entry` in arch/
loongarch/kernel/head.S:

_head:
.word MZ_MAGIC /* "MZ", MS-DOS header */
.org 0x8
.dword kernel_entry /* Kernel entry point */

The correct kernel entry from the MS-DOS header is crucial for jumping
to vmlinux from zboot. This necessity is why the compressed relocatable
kernel compiled by Clang encounters difficulties in booting.

To address this problem, it is proposed to apply dynamic relocations to
place with `--apply-dynamic-relocs`.

Link: https://github.com/ClangBuiltLinux/linux/issues/1962
Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Explicitly set -fdirect-access-external-data for vmlinux

After this llvm commit [1], The -fno-pic does not imply direct access
external data. Explicitly set -fdirect-access-external-data

LoongArch: Explicitly set -fdirect-access-external-data for vmlinux

After this llvm commit [1], The -fno-pic does not imply direct access
external data. Explicitly set -fdirect-access-external-data for vmlinux
that can avoids GOT entries.

Link: https://github.com/llvm/llvm-project/commit/47eeee297775347cbdb7624d6a766c2a3eec4a59
Suggested-by: Xi Ruoyao <[email protected]>
Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Add dependency between vmlinuz.efi and vmlinux.efi

A common issue in Makefile is a race in parallel building.

You need to be careful to prevent multiple threads from writing to the
same

LoongArch: Add dependency between vmlinuz.efi and vmlinux.efi

A common issue in Makefile is a race in parallel building.

You need to be careful to prevent multiple threads from writing to the
same file simultaneously.

Commit 3939f3345050 ("ARM: 8418/1: add boot image dependencies to not
generate invalid images") addressed such a bad scenario.

A similar symptom occurs with the following command:

$ make -j$(nproc) ARCH=loongarch vmlinux.efi vmlinuz.efi
[ snip ]
SORTTAB vmlinux
OBJCOPY arch/loongarch/boot/vmlinux.efi
OBJCOPY arch/loongarch/boot/vmlinux.efi
PAD arch/loongarch/boot/vmlinux.bin
GZIP arch/loongarch/boot/vmlinuz
OBJCOPY arch/loongarch/boot/vmlinuz.o
LD arch/loongarch/boot/vmlinuz.efi.elf
OBJCOPY arch/loongarch/boot/vmlinuz.efi

The log "OBJCOPY arch/loongarch/boot/vmlinux.efi" is displayed twice.

It indicates that two threads simultaneously enter arch/loongarch/boot/
and write to arch/loongarch/boot/vmlinux.efi.

It occasionally leads to a build failure:

$ make -j$(nproc) ARCH=loongarch vmlinux.efi vmlinuz.efi
[ snip ]
SORTTAB vmlinux
OBJCOPY arch/loongarch/boot/vmlinux.efi
PAD arch/loongarch/boot/vmlinux.bin
truncate: Invalid number: ‘arch/loongarch/boot/vmlinux.bin’
make[2]: *** [drivers/firmware/efi/libstub/Makefile.zboot:13:
arch/loongarch/boot/vmlinux.bin] Error 1
make[2]: *** Deleting file 'arch/loongarch/boot/vmlinux.bin'
make[1]: *** [arch/loongarch/Makefile:146: vmlinuz.efi] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [Makefile:234: __sub-make] Error 2

vmlinuz.efi depends on vmlinux.efi, but such a dependency is not
specified in arch/loongarch/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Disable module from accessing external data directly

The distance between vmlinux and the module is too far so that PC-REL
cannot be accessed directly, only GOT.

When compiling module wi

LoongArch: Disable module from accessing external data directly

The distance between vmlinux and the module is too far so that PC-REL
cannot be accessed directly, only GOT.

When compiling module with GCC, the option `-mdirect-extern-access` is
disabled by default. The Clang option `-fdirect-access-external-data` is
enabled by default, so it needs to be explicitly disabled.

Signed-off-by: WANG Rui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

kbuild: unify vdso_install rules

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just

kbuild: unify vdso_install rules

Currently, there is no standard implementation for vdso_install,
leading to various issues:

1. Code duplication

Many architectures duplicate similar code just for copying files
to the install destination.

Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.

2. Unintended updates of in-tree build artifacts

The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").

3. Broken code in some architectures

Makefile code is often copied from one architecture to another
without proper adaptation.

'make vdso_install' for parisc does not work.

'make vdso_install' for s390 installs vdso64, but not vdso32.

To address these problems, this commit introduces a generic vdso_install
rule.

Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.

For example, arch/x86/Makefile looks like this:

vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg

These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.

vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.

The following is a snippet from arch/arm64/Makefile.

vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so

This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Sven Schnelle <[email protected]> # s390
Reviewed-by: Nicolas Schier <[email protected]>
Reviewed-by: Guo Ren <[email protected]>
Acked-by: Helge Deller <[email protected]> # parisc
Acked-by: Catalin Marinas <[email protected]>
Acked-by: Russell King (Oracle) <[email protected]>

show more ...

LoongArch: Add KASAN (Kernel Address Sanitizer) support

1/8 of kernel addresses reserved for shadow memory. But for LoongArch,
There are a lot of holes between different segments and valid address
s

LoongArch: Add KASAN (Kernel Address Sanitizer) support

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 <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Replace -ffreestanding with finer-grained -fno-builtin's

As explained by Nick in the original issue: the kernel usually does a
good job of providing library helpers that have similar sema

LoongArch: Replace -ffreestanding with finer-grained -fno-builtin's

As explained by Nick in the original issue: the kernel usually does a
good job of providing library helpers that have similar semantics as
their ordinary userspace libc equivalents, but -ffreestanding disables
such libcall optimization and other related features in the compiler,
which can lead to unexpected things such as CONFIG_FORTIFY_SOURCE not
working (!).

However, due to the desire for better control over unaligned accesses
with respect to CONFIG_ARCH_STRICT_ALIGN, and also for avoiding the
GCC bug https://gcc.gnu.org/PR109465, we do want to still disable
optimizations for the memory libcalls (memcpy, memmove and memset for
now). Use finer-grained -fno-builtin-* toggles to achieve this without
losing source fortification and other libcall optimizations.

Closes: https://github.com/ClangBuiltLinux/linux/issues/1897
Reported-by: Nathan Chancellor <[email protected]>
Suggested-by: Nick Desaulniers <[email protected]>
Signed-off-by: WANG Xuerui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Fix module relocation error with binutils 2.41

Binutils 2.41 enables linker relaxation by default, but the kernel
module loader doesn't support that, so just disable it. Otherwise we
get

LoongArch: Fix module relocation error with binutils 2.41

Binutils 2.41 enables linker relaxation by default, but the kernel
module loader doesn't support that, so just disable it. Otherwise we
get such an error when loading modules:

"Unknown relocation type 102"

As an alternative, we could add linker relaxation support in the kernel
module loader. But it is relatively large complexity that may or may not
bring a similar gain, and we don't really want to include this linker
pass in the kernel.

Reviewed-by: WANG Xuerui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Only fiddle with CHECKFLAGS if `need-compiler'

This is a port of commit 4fe4a6374c4db9ae2b ("MIPS: Only fiddle with
CHECKFLAGS if `need-compiler'") to LoongArch.

We have originally guard

LoongArch: Only fiddle with CHECKFLAGS if `need-compiler'

This is a port of commit 4fe4a6374c4db9ae2b ("MIPS: Only fiddle with
CHECKFLAGS if `need-compiler'") to LoongArch.

We have originally guarded fiddling with CHECKFLAGS in our arch Makefile
by checking for the CONFIG_LOONGARCH variable, not set for targets such
as `distclean', etc. that neither include `.config' nor use the compiler.

Starting from commit 805b2e1d427aab4 ("kbuild: include Makefile.compiler
only when compiler is needed") we have had a generic `need-compiler'
variable explicitly telling us if the compiler will be used and thus its
capabilities need to be checked and expressed in the form of compilation
flags. If this variable is not set, then `make' functions such as
`cc-option' are undefined, causing all kinds of weirdness to happen if
we expect specific results to be returned.

It doesn't cause problems on LoongArch now. But as a guard we replace
the check for CONFIG_LOONGARCH with one for `need-compiler' instead, so
as to prevent the compiler from being ever called for CHECKFLAGS when
not needed.

Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation

This is a port of commit 08f6554ff90e ("mips: Include KBUILD_CPPFLAGS in
CHECKFLAGS invocation") to arch/loongarch, for fixing cross-compi

LoongArch: Include KBUILD_CPPFLAGS in CHECKFLAGS invocation

This is a port of commit 08f6554ff90e ("mips: Include KBUILD_CPPFLAGS in
CHECKFLAGS invocation") to arch/loongarch, for fixing cross-compilation
of Linux/LoongArch with Clang, where previously the `--target` flag
would no longer be present for the CHECKFLAGS cc invocation leading to
build failure.

Reported-by: Nathan Chancellor <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Link: https://github.com/ClangBuiltLinux/linux/issues/1787#issuecomment-1608306002
Signed-off-by: WANG Xuerui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Tweak CFLAGS for Clang compatibility

Now the arch code is mostly ready for LLVM/Clang consumption, it is time
to re-organize the CFLAGS a little to actually enable the LLVM build.
Namely,

LoongArch: Tweak CFLAGS for Clang compatibility

Now the arch code is mostly ready for LLVM/Clang consumption, it is time
to re-organize the CFLAGS a little to actually enable the LLVM build.
Namely, all -G0 switches from CFLAGS are removed, and -mexplicit-relocs
and -mdirect-extern-access are now wrapped with cc-option (with the
related asm/percpu.h definition guarded against toolchain combos that
are known to not work).

A build with !RELOCATABLE && !MODULE is confirmed working within a QEMU
environment; support for the two features are currently blocked on
LLVM/Clang, and will come later.

Why -G0 can be removed:

In GCC, -G stands for "small data threshold", that instructs the
compiler to put data smaller than the specified threshold in a dedicated
"small data" section (called .sdata on LoongArch and several other
arches).

However, benefiting from this would require ABI cooperation, which is
not the case for LoongArch; and current GCC behave the same whether -G0
(equal to disabling this optimization) is given or not. So, remove -G0
from CFLAGS altogether for one less thing to care about. This also
benefits LLVM/Clang compatibility where the -G switch is not supported.

Why -mexplicit-relocs can now be conditionally applied without
regressions:

Originally -mexplicit-relocs is unconditionally added to CFLAGS in case
of CONFIG_AS_HAS_EXPLICIT_RELOCS, because not having it (i.e. old GCC +
new binutils) would not work: modules will have R_LARCH_ABS_* relocs
inside, but given the rarity of such toolchain combo in the wild, it may
not be worthwhile to support it, so support for such relocs in modules
were not added back when explicit relocs support was upstreamed, and
-mexplicit-relocs is unconditionally added to fail the build early.

Now that Clang compatibility is desired, given Clang is behaving like
-mexplicit-relocs from day one but without support for the CLI flag, we
must ensure the flag is not passed in case of Clang. However, explicit
compiler flavor checks can be more brittle than feature detection: in
this case what actually matters is support for __attribute__((model))
when building modules. Given neither older GCC nor current Clang support
this attribute, probing for the attribute support and #error'ing out
would allow proper UX without checking for Clang, and also automatically
work when Clang support for the attribute is to be added in the future.

Why -mdirect-extern-access is now conditionally applied:

This is actually a nice-to-have optimization that can reduce GOT
accesses, but not having it is harmless either. Because Clang does not
support the option currently, but might do so in the future, conditional
application via cc-option ensures compatibility with both current and
future Clang versions.

Suggested-by: Xi Ruoyao <[email protected]> # cc-option changes
Signed-off-by: WANG Xuerui <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: crypto: Add crc32 and crc32c hw acceleration

With a blatant copy of some MIPS bits we introduce the crc32 and crc32c
hw accelerated module to LoongArch.

LoongArch has provided these inst

LoongArch: crypto: Add crc32 and crc32c hw acceleration

With a blatant copy of some MIPS bits we introduce the crc32 and crc32c
hw accelerated module to LoongArch.

LoongArch has provided these instructions to calculate crc32 and crc32c:
* crc.w.b.w crcc.w.b.w
* crc.w.h.w crcc.w.h.w
* crc.w.w.w crcc.w.w.w
* crc.w.d.w crcc.w.d.w

So we can make use of these instructions to improve the performance of
calculation for crc32(c) checksums.

As can be seen from the following test results, crc32(c) instructions
can improve the performance by 58%.

Software implemention Hardware acceleration
Buffer size time cost (seconds) time cost (seconds) Accel.
100 KB 0.000845 0.000534 59.1%
1 MB 0.007758 0.004836 59.4%
10 MB 0.076593 0.047682 59.4%
100 MB 0.756734 0.479126 58.5%
1000 MB 7.563841 4.778266 58.5%

Signed-off-by: Min Zhou <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: kdump: Add single kernel image implementation

This feature depends on the kernel being relocatable.

Enable using single kernel image for kdump, and then no longer need to
build two kerne

LoongArch: kdump: Add single kernel image implementation

This feature depends on the kernel being relocatable.

Enable using single kernel image for kdump, and then no longer need to
build two kernels (production kernel and capture kernel share a single
kernel image).

Also enable CONFIG_CRASH_DUMP in loongson3_defconfig.

Signed-off-by: Youling Tang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Add support for kernel relocation

This config allows to compile kernel as PIE and to relocate it at any
virtual address at runtime: this paves the way to KASLR.

Runtime relocation is pos

LoongArch: Add support for kernel relocation

This config allows to compile kernel as PIE and to relocate it at any
virtual address at runtime: this paves the way to KASLR.

Runtime relocation is possible since relocation metadata are embedded
into the kernel.

Signed-off-by: Youling Tang <[email protected]>
Signed-off-by: Xi Ruoyao <[email protected]> # Use arch_initcall
Signed-off-by: Jinyang He <[email protected]> # Provide la_abs relocation code
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch: Make -mstrict-align configurable

Introduce Kconfig option ARCH_STRICT_ALIGN to make -mstrict-align be
configurable.

Not all LoongArch cores support h/w unaligned access, we can use the
-

LoongArch: Make -mstrict-align configurable

Introduce Kconfig option ARCH_STRICT_ALIGN to make -mstrict-align be
configurable.

Not all LoongArch cores support h/w unaligned access, we can use the
-mstrict-align build parameter to prevent unaligned accesses.

CPUs with h/w unaligned access support:
Loongson-2K2000/2K3000/3A5000/3C5000/3D5000.

CPUs without h/w unaligned access support:
Loongson-2K500/2K1000.

This option is enabled by default to make the kernel be able to run on
all LoongArch systems. But you can disable it manually if you want to
run kernel only on systems with h/w unaligned access support in order to
optimise for performance.

Reviewed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...

LoongArch/ftrace: Add dynamic function tracer support

The compiler has inserted 2 NOPs before the regular function prologue.
T series registers are available and safe because of LoongArch's psABI.

LoongArch/ftrace: Add dynamic function tracer support

The compiler has inserted 2 NOPs before the regular function prologue.
T series registers are available and safe because of LoongArch's psABI.

At runtime, we can replace nop with bl to enable ftrace call and replace
bl with nop to disable ftrace call. The bl instruction requires us to
save the original RA value, so it saves RA at t0 here.

Details are:

| Compiled | Disabled | Enabled |
+------------+------------------------+------------------------+
| nop | move t0, ra | move t0, ra |
| nop | nop | bl ftrace_caller |
| func_body | func_body | func_body |

The RA value will be recovered by ftrace_regs_entry, and restored into
RA before returning to the regular function prologue. When a function is
not being traced, the "move t0, ra" is not harmful.

1) ftrace_make_call, ftrace_make_nop (in kernel/ftrace.c)
The two functions turn each recorded call site of filtered functions
into a call to ftrace_caller or nops.

2) ftracce_update_ftrace_func (in kernel/ftrace.c)
turns the nops at ftrace_call into a call to a generic entry for
function tracers.

3) ftrace_caller (in kernel/mcount_dyn.S)
The entry where each _mcount call sites calls to once they are
filtered to be traced.

Co-developed-by: Jinyang He <[email protected]>
Signed-off-by: Jinyang He <[email protected]>
Signed-off-by: Qing Zhang <[email protected]>
Signed-off-by: Huacai Chen <[email protected]>

show more ...