An error occurred fetching the project authors.
  1. 09 Sep, 2020 1 commit
  2. 30 Jul, 2020 7 commits
  3. 10 Jul, 2020 1 commit
  4. 04 Jul, 2020 1 commit
  5. 29 Jun, 2020 1 commit
  6. 11 Jun, 2020 1 commit
    • Vincent Chen's avatar
      riscv: use vDSO common flow to reduce the latency of the time-related functions · ad5d1122
      Vincent Chen authored
      Even if RISC-V has supported the vDSO feature, the latency of the functions
      for obtaining the system time is still expensive. It is because these
      functions still trigger a corresponding system call in the process, which
      slows down the response time. If we want to remove the system call to
      reduce the latency, the kernel should have the ability to output the system
      clock information to userspace. This patch introduces the vDSO common flow
      to enable the kernel to achieve the above feature and uses "rdtime"
      instruction to obtain the current time in the user space. Under this
      condition, the latency cost by the ecall from U-mode to S-mode can be
      eliminated. After applying this patch, the latency of gettimeofday()
      measured on the HiFive unleashed board can be reduced by %61.
      Signed-off-by: default avatarVincent Chen <vincent.chen@sifive.com>
      Reviewed-by: default avatarAtish Patra <atish.patra@wdc.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      ad5d1122
  7. 10 Jun, 2020 3 commits
  8. 04 Jun, 2020 2 commits
    • Zong Li's avatar
      riscv: support DEBUG_WX · b422d28b
      Zong Li authored
      Support DEBUG_WX to check whether there are mapping with write and execute
      permission at the same time.
      
      [akpm@linux-foundation.org: replace macros with C]
      Signed-off-by: default avatarZong Li <zong.li@sifive.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Palmer Dabbelt <palmer@dabbelt.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Will Deacon <will@kernel.org>
      Link: http://lkml.kernel.org/r/282e266311bced080bc6f7c255b92f87c1eb65d6.1587455584.git.zong.li@sifive.comSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      b422d28b
    • Mike Rapoport's avatar
      mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option · 3f08a302
      Mike Rapoport authored
      CONFIG_HAVE_MEMBLOCK_NODE_MAP is used to differentiate initialization of
      nodes and zones structures between the systems that have region to node
      mapping in memblock and those that don't.
      
      Currently all the NUMA architectures enable this option and for the
      non-NUMA systems we can presume that all the memory belongs to node 0 and
      therefore the compile time configuration option is not required.
      
      The remaining few architectures that use DISCONTIGMEM without NUMA are
      easily updated to use memblock_add_node() instead of memblock_add() and
      thus have proper correspondence of memblock regions to NUMA nodes.
      
      Still, free_area_init_node() must have a backward compatible version
      because its semantics with and without CONFIG_HAVE_MEMBLOCK_NODE_MAP is
      different.  Once all the architectures will use the new semantics, the
      entire compatibility layer can be dropped.
      
      To avoid addition of extra run time memory to store node id for
      architectures that keep memblock but have only a single node, the node id
      field of the memblock_region is guarded by CONFIG_NEED_MULTIPLE_NODES and
      the corresponding accessors presume that in those cases it is always 0.
      Signed-off-by: default avatarMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Tested-by: Hoan Tran <hoan@os.amperecomputing.com>	[arm64]
      Acked-by: Catalin Marinas <catalin.marinas@arm.com>	[arm64]
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Brian Cain <bcain@codeaurora.org>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Greg Ungerer <gerg@linux-m68k.org>
      Cc: Guan Xuetao <gxt@pku.edu.cn>
      Cc: Guo Ren <guoren@kernel.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: "James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Ley Foon Tan <ley.foon.tan@intel.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Michal Hocko <mhocko@kernel.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Nick Hu <nickhu@andestech.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Richard Weinberger <richard@nod.at>
      Cc: Rich Felker <dalias@libc.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Stafford Horne <shorne@gmail.com>
      Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Link: http://lkml.kernel.org/r/20200412194859.12663-4-rppt@kernel.orgSigned-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      3f08a302
  9. 18 May, 2020 3 commits
  10. 13 May, 2020 2 commits
  11. 24 Apr, 2020 1 commit
  12. 02 Apr, 2020 1 commit
    • Björn Töpel's avatar
      riscv, bpf: Remove BPF JIT for nommu builds · 93bbb255
      Björn Töpel authored
      The BPF JIT fails to build for kernels configured to !MMU. Without an
      MMU, the BPF JIT does not make much sense, therefore this patch
      disables the JIT for nommu builds.
      
      This was reported by the kbuild test robot:
      
         All errors (new ones prefixed by >>):
      
            arch/riscv/net/bpf_jit_comp64.c: In function 'bpf_jit_alloc_exec':
         >> arch/riscv/net/bpf_jit_comp64.c:1094:47: error: 'BPF_JIT_REGION_START' undeclared (first use in this function)
             1094 |  return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START,
                  |                                               ^~~~~~~~~~~~~~~~~~~~
            arch/riscv/net/bpf_jit_comp64.c:1094:47: note: each undeclared identifier is reported only once for each function it appears in
         >> arch/riscv/net/bpf_jit_comp64.c:1095:9: error: 'BPF_JIT_REGION_END' undeclared (first use in this function)
             1095 |         BPF_JIT_REGION_END, GFP_KERNEL,
                  |         ^~~~~~~~~~~~~~~~~~
            arch/riscv/net/bpf_jit_comp64.c:1098:1: warning: control reaches end of non-void function [-Wreturn-type]
             1098 | }
                  | ^
      Reported-by: default avatarkbuild test robot <lkp@intel.com>
      Signed-off-by: default avatarBjörn Töpel <bjorn.topel@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: default avatarLuke Nelson <luke.r.nels@gmail.com>
      Link: https://lore.kernel.org/bpf/20200331101046.23252-1-bjorn.topel@gmail.com
      93bbb255
  13. 31 Mar, 2020 2 commits
    • Atish Patra's avatar
      RISC-V: Support cpu hotplug · f1e58583
      Atish Patra authored
      This patch enable support for cpu hotplug in RISC-V. It uses SBI HSM
      extension to online/offline any hart. As a result, the harts are
      returned to firmware once they are offline. If the harts are brought
      online afterwards, they re-enter Linux kernel as if a secondary hart
      booted for the first time. All booting requirements are honored during
      this process.
      
      Tested both on QEMU and HighFive Unleashed board with. Test result follows.
      
      ---------------------------------------------------
      Offline cpu 2
      ---------------------------------------------------
      $ echo 0 > /sys/devices/system/cpu/cpu2/online
      [   32.828684] CPU2: off
      $ cat /proc/cpuinfo
      processor       : 0
      hart            : 0
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 1
      hart            : 1
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 3
      hart            : 3
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 4
      hart            : 4
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 5
      hart            : 5
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 6
      hart            : 6
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 7
      hart            : 7
      isa             : rv64imafdcsu
      mmu             : sv48
      
      ---------------------------------------------------
      online cpu 2
      ---------------------------------------------------
      $ echo 1 > /sys/devices/system/cpu/cpu2/online
      $ cat /proc/cpuinfo
      processor       : 0
      hart            : 0
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 1
      hart            : 1
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 2
      hart            : 2
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 3
      hart            : 3
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 4
      hart            : 4
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 5
      hart            : 5
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 6
      hart            : 6
      isa             : rv64imafdcsu
      mmu             : sv48
      
      processor       : 7
      hart            : 7
      isa             : rv64imafdcsu
      mmu             : sv48
      Signed-off-by: default avatarAtish Patra <atish.patra@wdc.com>
      Reviewed-by: default avatarAnup Patel <anup@brainfault.org>
      f1e58583
    • Atish Patra's avatar
      RISC-V: Introduce a new config for SBI v0.1 · efca1398
      Atish Patra authored
      We now have SBI v0.2 which is more scalable and extendable to handle
      future needs for RISC-V supervisor interfaces.
      
      Introduce a new config and move all SBI v0.1 code under that config.
      This allows to implement the new replacement SBI extensions cleanly
      and remove v0.1 extensions easily in future. Currently, the config
      is enabled by default. Once all M-mode software, with v0.1, is no
      longer in use, this config option and all relevant code can be easily
      removed.
      Signed-off-by: default avatarAtish Patra <atish.patra@wdc.com>
      Reviewed-by: default avatarAnup Patel <anup@brainfault.org>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      efca1398
  14. 26 Mar, 2020 5 commits
  15. 19 Mar, 2020 1 commit
    • Greentime Hu's avatar
      riscv: uaccess should be used in nommu mode · adccfb1a
      Greentime Hu authored
      It might have the unaligned access exception when trying to exchange data
      with user space program. In this case, it failed in tty_ioctl(). Therefore
      we should enable uaccess.S for NOMMU mode since the generic code doesn't
      handle the unaligned access cases.
      
         0x8013a212 <tty_ioctl+462>:  ld      a5,460(s1)
      
      [    0.115279] Oops - load address misaligned [#1]
      [    0.115284] CPU: 0 PID: 29 Comm: sh Not tainted 5.4.0-rc5-00020-gb4c27160d562-dirty #36
      [    0.115294] epc: 000000008013a212 ra : 000000008013a212 sp : 000000008f48dd50
      [    0.115303]  gp : 00000000801cac28 tp : 000000008fb80000 t0 : 00000000000000e8
      [    0.115312]  t1 : 000000008f58f108 t2 : 0000000000000009 s0 : 000000008f48ddf0
      [    0.115321]  s1 : 000000008f8c6220 a0 : 0000000000000001 a1 : 000000008f48dd28
      [    0.115330]  a2 : 000000008fb80000 a3 : 00000000801a7398 a4 : 0000000000000000
      [    0.115339]  a5 : 0000000000000000 a6 : 000000008f58f0c6 a7 : 000000000000001d
      [    0.115348]  s2 : 000000008f8c6308 s3 : 000000008f78b7c8 s4 : 000000008fb834c0
      [    0.115357]  s5 : 0000000000005413 s6 : 0000000000000000 s7 : 000000008f58f2b0
      [    0.115366]  s8 : 000000008f858008 s9 : 000000008f776818 s10: 000000008f776830
      [    0.115375]  s11: 000000008fb840a8 t3 : 1999999999999999 t4 : 000000008f78704c
      [    0.115384]  t5 : 0000000000000005 t6 : 0000000000000002
      [    0.115391] status: 0000000200001880 badaddr: 000000008f8c63ec cause: 0000000000000004
      [    0.115401] ---[ end trace 00d490c6a8b6c9ac ]---
      
      This failure could be fixed after this patch applied.
      
      [    0.002282] Run /init as init process
      Initializing random number generator... [    0.005573] random: dd: uninitialized urandom read (512 bytes read)
      done.
      
      Welcome to Buildroot
      buildroot login: root
      Password:
      Jan  1 00:00:00 login[62]: root login on 'ttySIF0'
      ~ #
      Signed-off-by: default avatarGreentime Hu <greentime.hu@sifive.com>
      Reviewed-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      adccfb1a
  16. 05 Mar, 2020 1 commit
    • Luke Nelson's avatar
      riscv, bpf: Add RV32G eBPF JIT · 5f316b65
      Luke Nelson authored
      This is an eBPF JIT for RV32G, adapted from the JIT for RV64G and
      the 32-bit ARM JIT.
      
      There are two main changes required for this to work compared to
      the RV64 JIT.
      
      First, eBPF registers are 64-bit, while RV32G registers are 32-bit.
      BPF registers either map directly to 2 RISC-V registers, or reside
      in stack scratch space and are saved and restored when used.
      
      Second, many 64-bit ALU operations do not trivially map to 32-bit
      operations. Operations that move bits between high and low words,
      such as ADD, LSH, MUL, and others must emulate the 64-bit behavior
      in terms of 32-bit instructions.
      
      This patch also makes related changes to bpf_jit.h, such
      as adding RISC-V instructions required by the RV32 JIT.
      
      Supported features:
      
      The RV32 JIT supports the same features and instructions as the
      RV64 JIT, with the following exceptions:
      
      - ALU64 DIV/MOD: Requires loops to implement on 32-bit hardware.
      
      - BPF_XADD | BPF_DW: There's no 8-byte atomic instruction in RV32.
      
      These features are also unsupported on other BPF JITs for 32-bit
      architectures.
      
      Testing:
      
      - lib/test_bpf.c
      test_bpf: Summary: 378 PASSED, 0 FAILED, [349/366 JIT'ed]
      test_bpf: test_skb_segment: Summary: 2 PASSED, 0 FAILED
      
      The tests that are not JITed are all due to use of 64-bit div/mod
      or 64-bit xadd.
      
      - tools/testing/selftests/bpf/test_verifier.c
      Summary: 1415 PASSED, 122 SKIPPED, 43 FAILED
      
      Tested both with and without BPF JIT hardening.
      
      This is the same set of tests that pass using the BPF interpreter
      with the JIT disabled.
      
      Verification and synthesis:
      
      We developed the RV32 JIT using our automated verification tool,
      Serval. We have used Serval in the past to verify patches to the
      RV64 JIT. We also used Serval to superoptimize the resulting code
      through program synthesis.
      
      You can find the tool and a guide to the approach and results here:
      https://github.com/uw-unsat/serval-bpf/tree/rv32-jit-v5Co-developed-by: default avatarXi Wang <xi.wang@gmail.com>
      Signed-off-by: default avatarXi Wang <xi.wang@gmail.com>
      Signed-off-by: default avatarLuke Nelson <luke.r.nels@gmail.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: default avatarBjörn Töpel <bjorn.topel@gmail.com>
      Acked-by: default avatarBjörn Töpel <bjorn.topel@gmail.com>
      Link: https://lore.kernel.org/bpf/20200305050207.4159-3-luke.r.nels@gmail.com
      5f316b65
  17. 04 Mar, 2020 1 commit
  18. 23 Jan, 2020 1 commit
    • Zong Li's avatar
      riscv: mm: add support for CONFIG_DEBUG_VIRTUAL · 6435f773
      Zong Li authored
      This patch implements CONFIG_DEBUG_VIRTUAL to do additional checks on
      virt_to_phys and __pa_symbol calls. virt_to_phys used for linear mapping
      check, and __pa_symbol used for kernel symbol check. In current RISC-V,
      kernel image maps to linear mapping area. If CONFIG_DEBUG_VIRTUAL is
      disable, these two functions calculate the offset on the address feded
      directly without any checks.
      
      The result of test_debug_virtual as follows:
      
      [    0.358456] ------------[ cut here ]------------
      [    0.358738] virt_to_phys used for non-linear address: (____ptrval____) (0xffffffd000000000)
      [    0.359174] WARNING: CPU: 0 PID: 1 at arch/riscv/mm/physaddr.c:16 __virt_to_phys+0x3c/0x50
      [    0.359409] Modules linked in:
      [    0.359630] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.5.0-rc3-00002-g5133c5c0ca13 #57
      [    0.359861] epc: ffffffe000253d1a ra : ffffffe000253d1a sp : ffffffe03aa87da0
      [    0.360019]  gp : ffffffe000ae03b0 tp : ffffffe03aa88000 t0 : ffffffe000af2660
      [    0.360175]  t1 : 0000000000000064 t2 : 00000000000000b7 s0 : ffffffe03aa87dc0
      [    0.360330]  s1 : ffffffd000000000 a0 : 000000000000004f a1 : 0000000000000000
      [    0.360492]  a2 : 0000000000000000 a3 : 0000000000000000 a4 : ffffffe000a84358
      [    0.360672]  a5 : 0000000000000000 a6 : 0000000000000000 a7 : 0000000000000000
      [    0.360876]  s2 : ffffffe000ae0600 s3 : ffffffe00000fc7c s4 : ffffffe0000224b0
      [    0.361067]  s5 : ffffffe000030890 s6 : ffffffe000022470 s7 : 0000000000000008
      [    0.361267]  s8 : ffffffe0000002c4 s9 : ffffffe000ae0640 s10: ffffffe000ae0630
      [    0.361453]  s11: 0000000000000000 t3 : 0000000000000000 t4 : 000000000001e6d0
      [    0.361636]  t5 : ffffffe000ae0a18 t6 : ffffffe000aee54e
      [    0.361806] status: 0000000000000120 badaddr: 0000000000000000 cause: 0000000000000003
      [    0.362056] ---[ end trace aec0bf78d4978122 ]---
      [    0.362404] PA: 0xfffffff080200000 for VA: 0xffffffd000000000
      [    0.362607] PA: 0x00000000baddd2d0 for VA: 0xffffffe03abdd2d0
      Signed-off-by: default avatarZong Li <zong.li@sifive.com>
      Reviewed-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      Tested-by: default avatarPaul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      6435f773
  19. 22 Jan, 2020 2 commits
    • Olof Johansson's avatar
      riscv: keep 32-bit kernel to 32-bit phys_addr_t · fc76324f
      Olof Johansson authored
      While rv32 technically has 34-bit physical addresses, no current platforms
      use it and it's likely to shake out driver bugs.
      
      Let's keep 64-bit phys_addr_t off on 32-bit builds until one shows up,
      since other work will be needed to make such a system useful anyway.
      
      PHYS_ADDR_T_64BIT is def_bool 64BIT, so just remove the select.
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      fc76324f
    • Nick Hu's avatar
      riscv: Add KASAN support · 8ad8b727
      Nick Hu authored
      This patch ports the feature Kernel Address SANitizer (KASAN).
      
      Note: The start address of shadow memory is at the beginning of kernel
      space, which is 2^64 - (2^39 / 2) in SV39. The size of the kernel space is
      2^38 bytes so the size of shadow memory should be 2^38 / 8. Thus, the
      shadow memory would not overlap with the fixmap area.
      
      There are currently two limitations in this port,
      
      1. RV64 only: KASAN need large address space for extra shadow memory
      region.
      
      2. KASAN can't debug the modules since the modules are allocated in VMALLOC
      area. We mapped the shadow memory, which corresponding to VMALLOC area, to
      the kasan_early_shadow_page because we don't have enough physical space for
      all the shadow memory corresponding to VMALLOC area.
      Signed-off-by: default avatarNick Hu <nickhu@andestech.com>
      Reported-by: default avatarGreentime Hu <green.hu@gmail.com>
      Signed-off-by: default avatarPalmer Dabbelt <palmerdabbelt@google.com>
      8ad8b727
  20. 07 Jan, 2020 1 commit
  21. 03 Jan, 2020 1 commit
  22. 20 Dec, 2019 1 commit