1. 11 6月, 2020 1 次提交
    • V
      riscv: use vDSO common flow to reduce the latency of the time-related functions · ad5d1122
      Vincent Chen 提交于
      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: NVincent Chen <vincent.chen@sifive.com>
      Reviewed-by: NAtish Patra <atish.patra@wdc.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      ad5d1122
  2. 10 6月, 2020 3 次提交
  3. 04 6月, 2020 2 次提交
    • Z
      riscv: support DEBUG_WX · b422d28b
      Zong Li 提交于
      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: NZong Li <zong.li@sifive.com>
      Signed-off-by: NAndrew 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: NLinus Torvalds <torvalds@linux-foundation.org>
      b422d28b
    • M
      mm: remove CONFIG_HAVE_MEMBLOCK_NODE_MAP option · 3f08a302
      Mike Rapoport 提交于
      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: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NAndrew 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: NLinus Torvalds <torvalds@linux-foundation.org>
      3f08a302
  4. 19 5月, 2020 3 次提交
  5. 13 5月, 2020 2 次提交
  6. 25 4月, 2020 1 次提交
  7. 03 4月, 2020 1 次提交
    • B
      riscv, bpf: Remove BPF JIT for nommu builds · 93bbb255
      Björn Töpel 提交于
      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: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NBjörn Töpel <bjorn.topel@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NLuke Nelson <luke.r.nels@gmail.com>
      Link: https://lore.kernel.org/bpf/20200331101046.23252-1-bjorn.topel@gmail.com
      93bbb255
  8. 01 4月, 2020 2 次提交
    • A
      RISC-V: Support cpu hotplug · f1e58583
      Atish Patra 提交于
      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: NAtish Patra <atish.patra@wdc.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      f1e58583
    • A
      RISC-V: Introduce a new config for SBI v0.1 · efca1398
      Atish Patra 提交于
      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: NAtish Patra <atish.patra@wdc.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      efca1398
  9. 27 3月, 2020 5 次提交
  10. 19 3月, 2020 1 次提交
    • G
      riscv: uaccess should be used in nommu mode · adccfb1a
      Greentime Hu 提交于
      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: NGreentime Hu <greentime.hu@sifive.com>
      Reviewed-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      adccfb1a
  11. 05 3月, 2020 2 次提交
    • L
      riscv, bpf: Add RV32G eBPF JIT · 5f316b65
      Luke Nelson 提交于
      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: NXi Wang <xi.wang@gmail.com>
      Signed-off-by: NXi Wang <xi.wang@gmail.com>
      Signed-off-by: NLuke Nelson <luke.r.nels@gmail.com>
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Reviewed-by: NBjörn Töpel <bjorn.topel@gmail.com>
      Acked-by: NBjörn Töpel <bjorn.topel@gmail.com>
      Link: https://lore.kernel.org/bpf/20200305050207.4159-3-luke.r.nels@gmail.com
      5f316b65
    • D
      riscv: Force flat memory model with no-mmu · aa273420
      Damien Le Moal 提交于
      Compilation errors trigger if ARCH_SPARSEMEM_ENABLE is enabled for
      a nommu kernel. Since the sparsemem model does not make sense anyway
      for the nommu case, do not allow selecting this option to always use
      the flatmem model.
      Signed-off-by: NDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      Reviewed-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      aa273420
  12. 24 1月, 2020 1 次提交
    • Z
      riscv: mm: add support for CONFIG_DEBUG_VIRTUAL · 6435f773
      Zong Li 提交于
      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: NZong Li <zong.li@sifive.com>
      Reviewed-by: NPaul Walmsley <paul.walmsley@sifive.com>
      Tested-by: NPaul Walmsley <paul.walmsley@sifive.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      6435f773
  13. 23 1月, 2020 2 次提交
    • O
      riscv: keep 32-bit kernel to 32-bit phys_addr_t · fc76324f
      Olof Johansson 提交于
      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: NOlof Johansson <olof@lixom.net>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      fc76324f
    • N
      riscv: Add KASAN support · 8ad8b727
      Nick Hu 提交于
      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: NNick Hu <nickhu@andestech.com>
      Reported-by: NGreentime Hu <green.hu@gmail.com>
      Signed-off-by: NPalmer Dabbelt <palmerdabbelt@google.com>
      8ad8b727
  14. 07 1月, 2020 1 次提交
  15. 03 1月, 2020 1 次提交
  16. 20 12月, 2019 1 次提交
  17. 18 11月, 2019 1 次提交
    • C
      riscv: add nommu support · 6bd33e1e
      Christoph Hellwig 提交于
      The kernel runs in M-mode without using page tables, and thus can't run
      bare metal without help from additional firmware.
      
      Most of the patch is just stubbing out code not needed without page
      tables, but there is an interesting detail in the signals implementation:
      
       - The normal RISC-V syscall ABI only implements rt_sigreturn as VDSO
         entry point, but the ELF VDSO is not supported for nommu Linux.
         We instead copy the code to call the syscall onto the stack.
      
      In addition to enabling the nommu code a new defconfig for a small
      kernel image that can run in nommu mode on qemu is also provided, to run
      a kernel in qemu you can use the following command line:
      
      qemu-system-riscv64 -smp 2 -m 64 -machine virt -nographic \
      	-kernel arch/riscv/boot/loader \
      	-drive file=rootfs.ext2,format=raw,id=hd0 \
      	-device virtio-blk-device,drive=hd0
      
      Contains contributions from Damien Le Moal <Damien.LeMoal@wdc.com>.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NAnup Patel <anup@brainfault.org>
      [paul.walmsley@sifive.com: updated to apply; add CONFIG_MMU guards
       around PCI_IOBASE definition to fix build issues; fixed checkpatch
       issues; move the PCI_IO_* and VMEMMAP address space macros along
       with the others; resolve sparse warning]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      6bd33e1e
  18. 17 11月, 2019 1 次提交
    • A
      int128: move __uint128_t compiler test to Kconfig · c12d3362
      Ard Biesheuvel 提交于
      In order to use 128-bit integer arithmetic in C code, the architecture
      needs to have declared support for it by setting ARCH_SUPPORTS_INT128,
      and it requires a version of the toolchain that supports this at build
      time. This is why all existing tests for ARCH_SUPPORTS_INT128 also test
      whether __SIZEOF_INT128__ is defined, since this is only the case for
      compilers that can support 128-bit integers.
      
      Let's fold this additional test into the Kconfig declaration of
      ARCH_SUPPORTS_INT128 so that we can also use the symbol in Makefiles,
      e.g., to decide whether a certain object needs to be included in the
      first place.
      
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      c12d3362
  19. 14 11月, 2019 1 次提交
  20. 12 11月, 2019 1 次提交
  21. 06 11月, 2019 1 次提交
    • C
      riscv: abstract out CSR names for supervisor vs machine mode · a4c3733d
      Christoph Hellwig 提交于
      Many of the privileged CSRs exist in a supervisor and machine version
      that are used very similarly.  Provide versions of the CSR names and
      fields that map to either the S-mode or M-mode variant depending on
      a new CONFIG_RISCV_M_MODE kconfig symbol.
      
      Contains contributions from Damien Le Moal <Damien.LeMoal@wdc.com>
      and Paul Walmsley <paul.walmsley@sifive.com>.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Acked-by: Thomas Gleixner <tglx@linutronix.de> # for drivers/clocksource, drivers/irqchip
      [paul.walmsley@sifive.com: updated to apply]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      a4c3733d
  22. 30 10月, 2019 1 次提交
  23. 25 9月, 2019 1 次提交
    • A
      riscv: make mmap allocation top-down by default · 54c95a11
      Alexandre Ghiti 提交于
      In order to avoid wasting user address space by using bottom-up mmap
      allocation scheme, prefer top-down scheme when possible.
      
      Before:
      root@qemuriscv64:~# cat /proc/self/maps
      00010000-00016000 r-xp 00000000 fe:00 6389       /bin/cat.coreutils
      00016000-00017000 r--p 00005000 fe:00 6389       /bin/cat.coreutils
      00017000-00018000 rw-p 00006000 fe:00 6389       /bin/cat.coreutils
      00018000-00039000 rw-p 00000000 00:00 0          [heap]
      1555556000-155556d000 r-xp 00000000 fe:00 7193   /lib/ld-2.28.so
      155556d000-155556e000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
      155556e000-155556f000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
      155556f000-1555570000 rw-p 00000000 00:00 0
      1555570000-1555572000 r-xp 00000000 00:00 0      [vdso]
      1555574000-1555576000 rw-p 00000000 00:00 0
      1555576000-1555674000 r-xp 00000000 fe:00 7187   /lib/libc-2.28.so
      1555674000-1555678000 r--p 000fd000 fe:00 7187   /lib/libc-2.28.so
      1555678000-155567a000 rw-p 00101000 fe:00 7187   /lib/libc-2.28.so
      155567a000-15556a0000 rw-p 00000000 00:00 0
      3fffb90000-3fffbb1000 rw-p 00000000 00:00 0      [stack]
      
      After:
      root@qemuriscv64:~# cat /proc/self/maps
      00010000-00016000 r-xp 00000000 fe:00 6389       /bin/cat.coreutils
      00016000-00017000 r--p 00005000 fe:00 6389       /bin/cat.coreutils
      00017000-00018000 rw-p 00006000 fe:00 6389       /bin/cat.coreutils
      2de81000-2dea2000 rw-p 00000000 00:00 0          [heap]
      3ff7eb6000-3ff7ed8000 rw-p 00000000 00:00 0
      3ff7ed8000-3ff7fd6000 r-xp 00000000 fe:00 7187   /lib/libc-2.28.so
      3ff7fd6000-3ff7fda000 r--p 000fd000 fe:00 7187   /lib/libc-2.28.so
      3ff7fda000-3ff7fdc000 rw-p 00101000 fe:00 7187   /lib/libc-2.28.so
      3ff7fdc000-3ff7fe2000 rw-p 00000000 00:00 0
      3ff7fe4000-3ff7fe6000 r-xp 00000000 00:00 0      [vdso]
      3ff7fe6000-3ff7ffd000 r-xp 00000000 fe:00 7193   /lib/ld-2.28.so
      3ff7ffd000-3ff7ffe000 r--p 00016000 fe:00 7193   /lib/ld-2.28.so
      3ff7ffe000-3ff7fff000 rw-p 00017000 fe:00 7193   /lib/ld-2.28.so
      3ff7fff000-3ff8000000 rw-p 00000000 00:00 0
      3fff888000-3fff8a9000 rw-p 00000000 00:00 0      [stack]
      
      [alex@ghiti.fr: v6]
        Link: http://lkml.kernel.org/r/20190808061756.19712-15-alex@ghiti.fr
      Link: http://lkml.kernel.org/r/20190730055113.23635-15-alex@ghiti.frSigned-off-by: NAlexandre Ghiti <alex@ghiti.fr>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Reviewed-by: NLuis Chamberlain <mcgrof@kernel.org>
      Acked-by: Paul Walmsley <paul.walmsley@sifive.com>	[arch/riscv]
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: James Hogan <jhogan@kernel.org>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: Paul Burton <paul.burton@mips.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Will Deacon <will.deacon@arm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      54c95a11
  24. 05 9月, 2019 1 次提交
    • M
      riscv: Add support for perf registers sampling · 98a93b0b
      Mao Han 提交于
      This patch implements the perf registers sampling and validation API
      for the riscv arch. The valid registers and their register ID are
      defined in perf_regs.h. Perf tool can backtrace in userspace with
      unwind library and the registers/user stack dump support.
      Signed-off-by: NMao Han <han_mao@c-sky.com>
      Cc: Paul Walmsley <paul.walmsley@sifive.com>
      Cc: Greentime Hu <green.hu@gmail.com>
      Cc: Palmer Dabbelt <palmer@sifive.com>
      Cc: linux-riscv <linux-riscv@lists.infradead.org>
      Cc: Christoph Hellwig <hch@lst.de>
      Cc: Guo Ren <guoren@kernel.org>
      Tested-by: NGreentime Hu <greentime.hu@sifive.com>
      [paul.walmsley@sifive.com: minor patch description fix]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      98a93b0b
  25. 31 8月, 2019 1 次提交
    • L
      RISC-V: Implement sparsemem · d95f1a54
      Logan Gunthorpe 提交于
      Implement sparsemem support for Risc-v which helps pave the
      way for memory hotplug and eventually P2P support.
      
      Introduce Kconfig options for virtual and physical address bits which
      are used to calculate the size of the vmemmap and set the
      MAX_PHYSMEM_BITS.
      
      The vmemmap is located directly before the VMALLOC region and sized
      such that we can allocate enough pages to populate all the virtual
      address space in the system (similar to the way it's done in arm64).
      
      During initialization, call memblocks_present() and sparse_init(),
      and provide a stub for vmemmap_populate() (all of which is similar to
      arm64).
      
      [greentime.hu@sifive.com: fixed pfn_valid, FIXADDR_TOP and fixed a bug
       rebasing onto v5.3]
      Signed-off-by: NGreentime Hu <greentime.hu@sifive.com>
      Signed-off-by: NLogan Gunthorpe <logang@deltatee.com>
      Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Cc: Albert Ou <aou@eecs.berkeley.edu>
      Cc: Andrew Waterman <andrew@sifive.com>
      Cc: Olof Johansson <olof@lixom.net>
      Cc: Michael Clark <michaeljclark@mac.com>
      Cc: Rob Herring <robh@kernel.org>
      Cc: Zong Li <zong@andestech.com>
      Reviewed-by: NMike Rapoport <rppt@linux.ibm.com>
      [paul.walmsley@sifive.com: updated to apply; minor commit message
       reformat]
      Signed-off-by: NPaul Walmsley <paul.walmsley@sifive.com>
      d95f1a54
  26. 22 8月, 2019 1 次提交
  27. 23 7月, 2019 1 次提交