An error occurred fetching the project authors.
  1. 22 Jul, 2024 1 commit
  2. 19 May, 2024 1 commit
  3. 14 May, 2024 5 commits
    • Tiezhu Yang's avatar
      LoongArch: Give a chance to build with !CONFIG_SMP · 5685d7fc
      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: default avatarTiezhu Yang <yangtiezhu@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      5685d7fc
    • Huacai Chen's avatar
      LoongArch: Select THP_SWAP if HAVE_ARCH_TRANSPARENT_HUGEPAGE · ff4a2443
      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: default avatarHuacai Chen <chenhuacai@loongson.cn>
      ff4a2443
    • Huacai Chen's avatar
      LoongArch: Select ARCH_WANT_DEFAULT_BPF_JIT · d0b35b02
      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: default avatarHuacai Chen <chenhuacai@loongson.cn>
      d0b35b02
    • Xi Ruoyao's avatar
      LoongArch: Select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 · 5125d033
      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: default avatarXi Ruoyao <xry111@xry111.site>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      5125d033
    • Xi Ruoyao's avatar
      LoongArch: Select ARCH_HAS_FAST_MULTIPLIER · 2cce9059
      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: default avatarXi Ruoyao <xry111@xry111.site>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      2cce9059
  4. 06 May, 2024 1 commit
    • Bibo Mao's avatar
      LoongArch: KVM: Add PV IPI support on guest side · 74c16b2e
      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: default avatarBibo Mao <maobibo@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      74c16b2e
  5. 26 Apr, 2024 1 commit
  6. 24 Apr, 2024 1 commit
  7. 19 Mar, 2024 2 commits
  8. 11 Mar, 2024 2 commits
    • Jinyang He's avatar
      LoongArch: Add kernel livepatching support · 199cc14c
      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: default avatarJinyang He <hejinyang@loongson.cn>
      Signed-off-by: default avatarTiezhu Yang <yangtiezhu@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      199cc14c
    • Tiezhu Yang's avatar
      LoongArch: Add ORC stack unwinder support · cb8a2ef0
      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: default avatarJinyang He <hejinyang@loongson.cn>
      Signed-off-by: default avatarJinyang He <hejinyang@loongson.cn>
      Co-developed-by: default avatarYouling Tang <tangyouling@loongson.cn>
      Signed-off-by: default avatarYouling Tang <tangyouling@loongson.cn>
      Signed-off-by: default avatarTiezhu Yang <yangtiezhu@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      cb8a2ef0
  9. 06 Mar, 2024 1 commit
  10. 08 Feb, 2024 1 commit
  11. 06 Feb, 2024 2 commits
  12. 17 Jan, 2024 3 commits
    • Youling Tang's avatar
      LoongArch: Use generic interface to support crashkernel=X,[high,low] · 78de91b4
      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: default avatarYouling Tang <tangyouling@kylinos.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      78de91b4
    • Binbin Zhou's avatar
      LoongArch: Allow device trees be built into the kernel · 5f346a6e
      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: default avatarBinbin Zhou <zhoubinbin@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      5f346a6e
    • WANG Rui's avatar
      LoongArch: Enable initial Rust support · 90868ff9
      WANG Rui authored
      Enable initial Rust support for LoongArch.
      Tested-by: default avatarMiguel Ojeda <ojeda@kernel.org>
      Signed-off-by: default avatarWANG Rui <wangrui@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      90868ff9
  13. 06 Dec, 2023 2 commits
  14. 08 Nov, 2023 1 commit
  15. 02 Oct, 2023 1 commit
  16. 06 Sep, 2023 5 commits
    • Qing Zhang's avatar
      LoongArch: Add KASAN (Kernel Address Sanitizer) support · 5aa4ac64
      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: default avatarQing Zhang <zhangqing@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      5aa4ac64
    • Enze Li's avatar
      LoongArch: Add KFENCE (Kernel Electric-Fence) support · 6ad3df56
      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: default avatarEnze Li <lienze@kylinos.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      6ad3df56
    • Feiyang Chen's avatar
      LoongArch: Allow building with kcov coverage · 2363088e
      Feiyang Chen authored
      Add ARCH_HAS_KCOV and HAVE_GCC_PLUGINS to the LoongArch Kconfig. And
      also disable instrumentation of vdso.
      Signed-off-by: default avatarFeiyang Chen <chenfeiyang@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      2363088e
    • Qing Zhang's avatar
      LoongArch: Add basic KGDB & KDB support · e14dd076
      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: default avatarHuacai Chen <chenhuacai@loongson.cn>
      e14dd076
    • Qi Hu's avatar
      LoongArch: Add Loongson Binary Translation (LBT) extension support · bd3c5798
      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: default avatarQi Hu <huqi@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      bd3c5798
  17. 25 Aug, 2023 1 commit
  18. 18 Aug, 2023 2 commits
  19. 28 Jul, 2023 1 commit
  20. 29 Jun, 2023 6 commits
    • Tiezhu Yang's avatar
      LoongArch: Add uprobes support · 19bc6cb6
      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: default avatarJeff Xie <xiehuan09@gmail.com>
      Signed-off-by: default avatarTiezhu Yang <yangtiezhu@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      19bc6cb6
    • Haoran Jiang's avatar
      LoongArch: Replace kretprobe with rethook · 7b0a0964
      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: default avatarHaoran Jiang <jianghaoran@kylinos.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      7b0a0964
    • Youling Tang's avatar
      LoongArch: Add jump-label implementation · f02644e3
      Youling Tang authored
      Add support for jump labels based on the ARM64 version.
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarYouling Tang <tangyouling@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      f02644e3
    • Tiezhu Yang's avatar
      LoongArch: Select HAVE_DEBUG_KMEMLEAK to support kmemleak · 5d553770
      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: default avatarTiezhu Yang <yangtiezhu@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      5d553770
    • Huacai Chen's avatar
      LoongArch: Add SMT (Simultaneous Multi-Threading) support · f6f0c9a7
      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: default avatarLiupu Wang <wangliupu@loongson.cn>
      Signed-off-by: default avatarHuacai Chen <chenhuacai@loongson.cn>
      f6f0c9a7
    • Huacai Chen's avatar
      LoongArch: Add vector extensions support · 61650023
      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: default avatarHuacai Chen <chenhuacai@loongson.cn>
      61650023