- 09 Dec, 2022 2 commits
-
-
Jisheng Zhang authored
Support build the zstd compressed Image.zst. Similar as other compressed formats, the Image.zst is not self-decompressing and the bootloader still needs to handle decompression before launching the kernel image. Signed-off-by:
Jisheng Zhang <jszhang@kernel.org> Link: https://lore.kernel.org/r/20221123150257.3108-1-jszhang@kernel.orgSigned-off-by:
Palmer Dabbelt <palmer@rivosinc.com>
-
Palmer Dabbelt authored
Conor Dooley <conor@kernel.org> says: From: Conor Dooley <conor.dooley@microchip.com> Submitted a patch yesterday defaulting the SiFive PLIC driver to enabled [0], and in the ensuing conversation Marc suggested just doing a select at the arch level and dropping the user selectability completely. * b4-shazam-merge: RISC-V: stop selecting SIFIVE_PLIC at the SoC level irqchip/riscv-intc: remove user selectability of RISCV_INTC irqchip/sifive-plic: remove user selectability of SIFIVE_PLIC Link: https://lore.kernel.org/r/20221118104300.85016-1-conor@kernel.orgAcked-by:
Marc Zyngier <maz@kernel.org> Link: https://lore.kernel.org/all/87zgceszp8.wl-maz@kernel.org/Signed-off-by:
-
- 08 Dec, 2022 10 commits
-
-
Conor Dooley authored
The SIFIVE_PLIC driver is used by all current RISC-V SoCs & will be, where possible, used for future implementations. Rather than having each driver select the option on a case-by-case basis, do so at the arch level. Signed-off-by:
Conor Dooley <conor.dooley@microchip.com> Acked-by:
-
Conor Dooley authored
Since commit e71ee06e ("RISC-V: Force select RISCV_INTC for CONFIG_RISCV") the driver has been enabled at the arch level - and is mandatory anyway. There's no point exposing this as a choice to users, so stop bothering. Signed-off-by:
-
Conor Dooley authored
The SiFive PLIC driver is used by all current implementations, including those that do not have a SiFive PLIC. The current driver supports more than just SiFive PLICs at present and, where possible, future PLIC implementations will also use this driver. As every supported RISC-V SoC selects the driver directly in Kconfig.socs there's no point in exposing this kconfig option to users. The Kconfig help text, in its current form, is misleading. There's no point doing anything about that though, as it will no longer be user selectable. Remove it. Suggested-by:
-
Palmer Dabbelt authored
Anup Patel <apatel@ventanamicro.com> says: The Linux NVDIMM PEM drivers require arch support to map and access the persistent memory device. This series adds RISC-V PMEM support using recently added Svpbmt and Zicbom support. * b4-shazam-merge: RISC-V: Enable PMEM drivers RISC-V: Implement arch specific PMEM APIs RISC-V: Fix MEMREMAP_WB for systems with Svpbmt Link: https://lore.kernel.org/r/20221114090536.1662624-1-apatel@ventanamicro.comSigned-off-by:
-
Anup Patel authored
We now have PMEM arch support available in RISC-V kernel so let us enable relevant drivers in defconfig. Signed-off-by:
Anup Patel <apatel@ventanamicro.com> Acked-by:
-
Anup Patel authored
The NVDIMM PMEM driver expects arch specific APIs for cache maintenance and if arch does not provide these APIs then NVDIMM PMEM driver will always use MEMREMAP_WT to map persistent memory which in-turn maps as UC memory type defined by the RISC-V Svpbmt specification. Now that the Svpbmt and Zicbom support is available in RISC-V kernel, we implement PMEM APIs using ALT_CMO_OP() macros so that the NVDIMM PMEM driver can use MEMREMAP_WB to map persistent memory. Co-developed-by:
Mayuresh Chitale <mchitale@ventanamicro.com> Signed-off-by:
-
Anup Patel authored
Currently, the memremap() called with MEMREMAP_WB maps memory using the generic ioremap() function which breaks on system with Svpbmt because memory mapped using _PAGE_IOREMAP page attributes is treated as strongly-ordered non-cacheable IO memory. To address this, we implement RISC-V specific arch_memremap_wb() which maps memory using _PAGE_KERNEL page attributes resulting in write-back cacheable mapping on systems with Svpbmt. Fixes: ff689fd2 ("riscv: add RISC-V Svpbmt extension support") Co-developed-by:
-
Palmer Dabbelt authored
I'm merging this in as a single patch to make it easier to handle the backports. * b4-shazam-merge: RISC-V: Fix unannoted hardirqs-on in return to userspace slow-path Link: https://lore.kernel.org/r/20221111223108.1976562-1-abrestic@rivosinc.comSigned-off-by:
-
Andrew Bresticker authored
The return to userspace path in entry.S may enable interrupts without the corresponding lockdep annotation, producing a splat[0] when DEBUG_LOCKDEP is enabled. Simply calling __trace_hardirqs_on() here gets a bit messy due to the use of RA to point back to ret_from_exception, so just move the whole slow-path loop into C. It's more readable and it lets us use local_irq_{enable,disable}(), avoiding the need for manual annotations altogether. [0]: ------------[ cut here ]------------ DEBUG_LOCKS_WARN_ON(!lockdep_hardirqs_enabled()) WARNING: CPU: 2 PID: 1 at kernel/locking/lockdep.c:5512 check_flags+0x10a/0x1e0 Modules linked in: CPU: 2 PID: 1 Comm: init Not tainted 6.1.0-rc4-00160-gb56b6e2b4f31 #53 Hardware name: riscv-virtio,qemu (DT) epc : check_flags+0x10a/0x1e0 ra : check_flags+0x10a/0x1e0 <snip> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003 [<ffffffff808edb90>] lock_is_held_type+0x78/0x14e [<ffffffff8003dae2>] __might_resched+0x26/0x22c [<ffffffff8003dd24>] __might_sleep+0x3c/0x66 [<ffffffff80022c60>] get_signal+0x9e/0xa70 [<ffffffff800054a2>] do_notify_resume+0x6e/0x422 [<ffffffff80003c68>] ret_from_exception+0x0/0x10 irq event stamp: 44512 hardirqs last enabled at (44511): [<ffffffff808f901c>] _raw_spin_unlock_irqrestore+0x54/0x62 hardirqs last disabled at (44512): [<ffffffff80008200>] __trace_hardirqs_off+0xc/0x14 softirqs last enabled at (44472): [<ffffffff808f9fbe>] __do_softirq+0x3de/0x51e softirqs last disabled at (44467): [<ffffffff80017760>] irq_exit+0xd6/0x104 ---[ end trace 0000000000000000 ]--- possible reason: unannotated irqs-on. Signed-off-by:Andrew Bresticker <abrestic@rivosinc.com> Fixes: 3c469798 ("riscv: Enable LOCKDEP_SUPPORT & fixup TRACE_IRQFLAGS_SUPPORT") Link: https://lore.kernel.org/r/20221111223108.1976562-1-abrestic@rivosinc.comSigned-off-by:
-
Sergey Matyukevich authored
Current implementation of update_mmu_cache function performs local TLB flush. It does not take into account ASID information. Besides, it does not take into account other harts currently running the same mm context or possible migration of the running context to other harts. Meanwhile TLB flush is not performed for every context switch if ASID support is enabled. Patch [1] proposed to add ASID support to update_mmu_cache to avoid flushing local TLB entirely. This patch takes into account other harts currently running the same mm context as well as possible migration of this context to other harts. For this purpose the approach from flush_icache_mm is reused. Remote harts currently running the same mm context are informed via SBI calls that they need to flush their local TLBs. All the other harts are marked as needing a deferred TLB flush when this mm context runs on them. [1] https://lore.kernel.org/linux-riscv/20220821013926.8968-1-tjytimi@163.com/Signed-off-by:
Sergey Matyukevich <sergey.matyukevich@syntacore.com> Fixes: 65d4b9c5 ("RISC-V: Implement ASID allocator") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/linux-riscv/20220829205219.283543-1-geomatsi@gmail.com/#tSigned-off-by:
-
- 06 Dec, 2022 2 commits
-
-
Guo Ren authored
The current walk_stackframe with FRAME_POINTER would stop unwinding at ret_from_exception: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192 Call Trace: [<ffffffe0002038c8>] walk_stackframe+0x0/0xee [<ffffffe000aecf48>] show_stack+0x32/0x4a [<ffffffe000af1618>] dump_stack_lvl+0x72/0x8e [<ffffffe000af1648>] dump_stack+0x14/0x1c [<ffffffe000239ad2>] ___might_sleep+0x12e/0x138 [<ffffffe000239aec>] __might_sleep+0x10/0x18 [<ffffffe000afe3fe>] down_read+0x22/0xa4 [<ffffffe000207588>] do_page_fault+0xb0/0x2fe [<ffffffe000201b80>] ret_from_exception+0x0/0xc The optimization would help walk_stackframe cross the pt_regs frame and get more backtrace of debug info: BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1518 in_atomic(): 0, irqs_disabled(): 1, non_block: 0, pid: 1, name: init CPU: 0 PID: 1 Comm: init Not tainted 5.10.113-00021-g15c15974895c-dirty #192 Call Trace: [<ffffffe0002038c8>] walk_stackframe+0x0/0xee [<ffffffe000aecf48>] show_stack+0x32/0x4a [<ffffffe000af1618>] dump_stack_lvl+0x72/0x8e [<ffffffe000af1648>] dump_stack+0x14/0x1c [<ffffffe000239ad2>] ___might_sleep+0x12e/0x138 [<ffffffe000239aec>] __might_sleep+0x10/0x18 [<ffffffe000afe3fe>] down_read+0x22/0xa4 [<ffffffe000207588>] do_page_fault+0xb0/0x2fe [<ffffffe000201b80>] ret_from_exception+0x0/0xc [<ffffffe000613c06>] riscv_intc_irq+0x1a/0x72 [<ffffffe000201b80>] ret_from_exception+0x0/0xc [<ffffffe00033f44a>] vma_link+0x54/0x160 [<ffffffe000341d7a>] mmap_region+0x2cc/0x4d0 [<ffffffe000342256>] do_mmap+0x2d8/0x3ac [<ffffffe000326318>] vm_mmap_pgoff+0x70/0xb8 [<ffffffe00032638a>] vm_mmap+0x2a/0x36 [<ffffffe0003cfdde>] elf_map+0x72/0x84 [<ffffffe0003d05f8>] load_elf_binary+0x69a/0xec8 [<ffffffe000376240>] bprm_execve+0x246/0x53a [<ffffffe00037786c>] kernel_execve+0xe8/0x124 [<ffffffe000aecdf2>] run_init_process+0xfa/0x10c [<ffffffe000aece16>] try_to_run_init_process+0x12/0x3c [<ffffffe000afa920>] kernel_init+0xb4/0xf8 [<ffffffe000201b80>] ret_from_exception+0x0/0xc Here is the error injection test code for the above output: drivers/irqchip/irq-riscv-intc.c: static asmlinkage void riscv_intc_irq(struct pt_regs *regs) { unsigned long cause = regs->cause & ~CAUSE_IRQ_FLAG; + u32 tmp; __get_user(tmp, (u32 *)0); Signed-off-by:Guo Ren <guoren@linux.alibaba.com> Signed-off-by:
Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20221109064937.3643993-3-guoren@kernel.org [Palmer: use SYM_CODE_*] Signed-off-by:
-
Guo Ren authored
The 'retp' is a pointer to the return address on the stack, so we must pass the current return address pointer as the 'retp' argument to ftrace_push_return_trace(). Not parent function's return address on the stack. Fixes: b785ec12 ("riscv/ftrace: Add HAVE_FUNCTION_GRAPH_RET_ADDR_PTR support") Signed-off-by:
-
- 05 Dec, 2022 2 commits
-
-
Li Huafei authored
This is reported by kmemleak detector: unreferenced object 0xff2000000403d000 (size 4096): comm "kexec", pid 146, jiffies 4294900633 (age 64.792s) hex dump (first 32 bytes): 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 .ELF............ 04 00 f3 00 01 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000566ca97c>] kmemleak_vmalloc+0x3c/0xbe [<00000000979283d8>] __vmalloc_node_range+0x3ac/0x560 [<00000000b4b3712a>] __vmalloc_node+0x56/0x62 [<00000000854f75e2>] vzalloc+0x2c/0x34 [<00000000e9a00db9>] crash_prepare_elf64_headers+0x80/0x30c [<0000000067e8bf48>] elf_kexec_load+0x3e8/0x4ec [<0000000036548e09>] kexec_image_load_default+0x40/0x4c [<0000000079fbe1b4>] sys_kexec_file_load+0x1c4/0x322 [<0000000040c62c03>] ret_from_syscall+0x0/0x2 In elf_kexec_load(), a buffer is allocated via vzalloc() to store elf headers. While it's not freed back to system when kdump kernel is reloaded or unloaded, or when image->elf_header is successfully set and then fails to load kdump kernel for some reason. Fix it by freeing the buffer in arch_kimage_file_post_load_cleanup(). Fixes: 8acea455 ("RISC-V: Support for kexec_file on panic") Signed-off-by:Li Huafei <lihuafei1@huawei.com> Reviewed-by:
-
Li Huafei authored
This is reported by kmemleak detector: unreferenced object 0xff60000082864000 (size 9588): comm "kexec", pid 146, jiffies 4294900634 (age 64.788s) hex dump (first 32 bytes): d0 0d fe ed 00 00 12 ed 00 00 00 48 00 00 11 40 ...........H...@ 00 00 00 28 00 00 00 11 00 00 00 02 00 00 00 00 ...(............ backtrace: [<00000000f95b17c4>] kmemleak_alloc+0x34/0x3e [<00000000b9ec8e3e>] kmalloc_order+0x9c/0xc4 [<00000000a95cf02e>] kmalloc_order_trace+0x34/0xb6 [<00000000f01e68b4>] __kmalloc+0x5c2/0x62a [<000000002bd497b2>] kvmalloc_node+0x66/0xd6 [<00000000906542fa>] of_kexec_alloc_and_setup_fdt+0xa6/0x6ea [<00000000e1166bde>] elf_kexec_load+0x206/0x4ec [<0000000036548e09>] kexec_image_load_default+0x40/0x4c [<0000000079fbe1b4>] sys_kexec_file_load+0x1c4/0x322 [<0000000040c62c03>] ret_from_syscall+0x0/0x2 In elf_kexec_load(), a buffer is allocated via kvmalloc() to store fdt. While it's not freed back to system when kexec kernel is reloaded or unloaded. Then memory leak is caused. Fix it by introducing riscv specific function arch_kimage_file_post_load_cleanup(), and freeing the buffer there. Fixes: 6261586e ("RISC-V: Add kexec_file support") Signed-off-by:Liao Chang <liaochang1@huawei.com> Link: https://lore.kernel.org/r/20221104095658.141222-1-lihuafei1@huawei.com Cc: stable@vger.kernel.org Signed-off-by:
-
- 03 Dec, 2022 3 commits
-
-
Palmer Dabbelt authored
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. * b4-shazam-merge: Documentation: kdump: describe VMCOREINFO export for RISCV64 RISC-V: Add arch_crash_save_vmcoreinfo support Link: https://lore.kernel.org/r/20221026144208.373504-1-xianting.tian@linux.alibaba.comSigned-off-by:
-
Xianting Tian authored
The following interrelated definitions and ranges are needed by the kdump crash tool, which are exported by "arch/riscv/kernel/crash_core.c": VA_BITS, PAGE_OFFSET, phys_ram_base, KERNEL_LINK_ADDR, MODULES_VADDR ~ MODULES_END, VMALLOC_START ~ VMALLOC_END, VMEMMAP_START ~ VMEMMAP_END, Document these RISCV64 exports above. Reviewed-by:Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by:
Xianting Tian <xianting.tian@linux.alibaba.com> Acked-by:
Baoquan He <bhe@redhat.com> Link: https://lore.kernel.org/r/20221026144208.373504-3-xianting.tian@linux.alibaba.com [Palmer: wrap commit text] Signed-off-by:
-
Xianting Tian authored
Add arch_crash_save_vmcoreinfo(), which exports VM layout(MODULES, VMALLOC, VMEMMAP ranges and KERNEL_LINK_ADDR), va bits and ram base for vmcore. Default pagetable levels and PAGE_OFFSET aren't same for different kernel version as below. For pagetable levels, it sets sv57 by default and falls back to setting sv48 at boot time if sv57 is not supported by the hardware. For ram base, the default value is 0x80200000 for qemu riscv64 env and, for example, is 0x200000 on the XuanTie 910 CPU. * Linux Kernel 5.18 ~ * PGTABLE_LEVELS = 5 * PAGE_OFFSET = 0xff60000000000000 * Linux Kernel 5.17 ~ * PGTABLE_LEVELS = 4 * PAGE_OFFSET = 0xffffaf8000000000 * Linux Kernel 4.19 ~ * PGTABLE_LEVELS = 3 * PAGE_OFFSET = 0xffffffe000000000 Since these configurations change from time to time and version to version, it is preferable to export them via vmcoreinfo than to change the crash's code frequently, it can simplify the development of crash tool. Signed-off-by:
Deepak Gupta <debug@rivosinc.com> Tested-by:
-
- 02 Dec, 2022 9 commits
-
-
Binglei Wang authored
Implement the kretprobes on riscv arch by using rethook machenism which abstracts general kretprobe info into a struct rethook_node to be embedded in the struct kretprobe_instance. Acked-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by:
Binglei Wang <l3b2w1@gmail.com> Signed-off-by:
-
Tong Tiangen authored
With the PG_arch_1 we keep track if the page's data cache is clean, architecture rely on this property to treat new pages as dirty with respect to the data cache and perform the flushing before mapping the pages into userspace. This patch adds a new architecture hook, arch_clear_hugepage_flags,so that architectures which rely on the page flags being in a particular state for fresh allocations can adjust the flags accordingly when a page is freed into the pool. Fixes: 9e953cda ("riscv: Introduce huge page support for 32/64bit kernel") Signed-off-by:
Tong Tiangen <tongtiangen@huawei.com> Link: https://lore.kernel.org/r/20221024094725.3054311-3-tongtiangen@huawei.comSigned-off-by:
-
Tong Tiangen authored
HugeTLB pages are always fully mapped, so only setting head page's PG_dcache_clean flag is enough. Signed-off-by:
-
Hal Feng authored
Add CONFIG_SERIAL_8250_DW=y, which is a necessary option for StarFive JH7110 and JH7100 SoCs to boot with serial ports. Reviewed-by:
Hal Feng <hal.feng@starfivetech.com> Acked-by:
-
Palmer Dabbelt authored
Jamie Iles <jamie@jamieiles.com> says: This series enables dynamic ftrace support for RV32I bringing it to parity with RV64I. Most of the work is already there, this is largely just assembly fixes to handle register sizes, correct handling of the psABI calling convention and Kconfig change. Validated with all ftrace boot time self test with qemu for RV32I and RV64I in addition to real tracing on an RV32I FPGA design. * b4-shazam-merge: RISC-V: enable dynamic ftrace for RV32I RISC-V: preserve a1 in mcount RISC-V: reduce mcount save space on RV32 RISC-V: use REG_S/REG_L for mcount Link: https://lore.kernel.org/r/20221115200832.706370-1-jamie@jamieiles.comSigned-off-by:
-
Jamie Iles authored
The RISC-V mcount function is now capable of supporting RV32I so make it available in the kernel config. Signed-off-by:
Jamie Iles <jamie@jamieiles.com> Link: https://lore.kernel.org/r/20221115200832.706370-5-jamie@jamieiles.comSigned-off-by:
-
Jamie Iles authored
The RISC-V ELF psABI states that both a0 and a1 are used for return values so we should preserve them both in return_to_handler. This is especially important for RV32 for functions returning a 64-bit quantity otherwise the return value can be corrupted and undefined behaviour results. Reviewed-by:
Andrew Jones <ajones@ventanamicro.com> Signed-off-by:
-
Jamie Iles authored
For RV32 we can reduce the size of the ABI save+restore state by using SZREG so that register stores are packed rather than on an 8 byte boundary. Signed-off-by:
-
Jamie Iles authored
In preparation for rv32i ftrace support, convert mcount routines to use native sized loads/stores. Reviewed-by:
-
- 29 Nov, 2022 1 commit
-
-
Conor Dooley authored
on an arch level, RISC-V defaults to FLATMEM. On PolarFire SoC, the memory layout is almost always sparse, with a maximum of 1 GiB at 0x8000_0000 & a possible 16 GiB range at 0x10_0000_0000. The Icicle kit, for example, has 2 GiB of DDR - so there's a big hole in the memory map between the two gigs. Prior to v6.1-rc1, boot times from defconfig builds were pretty bad on Icicle but enabling sparsemem would fix those issues. As of v6.1-rc1, the Icicle kit no longer boots from defconfig builds with the in-kernel devicetree. A change to the memory map resulted in a futher "sparse-ification", producing a splat on boot: OF: fdt: Ignoring memory range 0x80000000 - 0x80200000 Machine model: Microchip PolarFire-SoC Icicle Kit earlycon: ns16550a0 at MMIO32 0x0000000020100000 (options '115200n8') printk: bootconsole [ns16550a0] enabled printk: debug: skip boot console de-registration. efi: UEFI not found. Zone ranges: DMA32 [mem 0x0000000080200000-0x00000000ffffffff] Normal [mem 0x0000000100000000-0x000000107fffffff] Movable zone start for each node Early memory node ranges node 0: [mem 0x0000000080200000-0x00000000bfbfffff] node 0: [mem 0x00000000bfc00000-0x00000000bfffffff] node 0: [mem 0x0000001040000000-0x000000107fffffff] Initmem setup node 0 [mem 0x0000000080200000-0x000000107fffffff] Kernel panic - not syncing: Failed to allocate 1073741824 bytes for node 0 memory map CPU: 0 PID: 0 Comm: swapper Not tainted 5.19.0-dirty #1 Hardware name: Microchip PolarFire-SoC Icicle Kit (DT) Call Trace: [<ffffffff800057f0>] show_stack+0x30/0x3c [<ffffffff807d5802>] dump_stack_lvl+0x4a/0x66 [<ffffffff807d5836>] dump_stack+0x18/0x20 [<ffffffff807d1ae8>] panic+0x124/0x2c6 [<ffffffff80814064>] free_area_init_core+0x0/0x11e [<ffffffff80813720>] free_area_init_node+0xc2/0xf6 [<ffffffff8081331e>] free_area_init+0x222/0x260 [<ffffffff808064d6>] misc_mem_init+0x62/0x9a [<ffffffff80803cb2>] setup_arch+0xb0/0xea [<ffffffff8080039a>] start_kernel+0x88/0x4ee ---[ end Kernel panic - not syncing: Failed to allocate 1073741824 bytes for node 0 memory map ]--- With the aim of keeping defconfig builds booting on icicle, enable SPARSEMEM_MANUAL. Signed-off-by:
-
- 17 Nov, 2022 1 commit
-
-
Lad Prabhakar authored
Enable cpufreq kconfig menu for RISC-V. Signed-off-by:
Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by:
-
- 29 Oct, 2022 2 commits
-
-
Liu Shixin authored
After we support HAVE_ARCH_HUGE_VMAP, we can now enable HAVE_ARCH_HUGE_VMALLOC too. This feature has been used in kvmalloc and alloc_large_system_hash for now. This feature can be disabled by kernel parameters "nohugevmalloc". Signed-off-by:
Liu Shixin <liushixin2@huawei.com> Reviewed-by:
Björn Töpel <bjorn@kernel.org> Tested-by:
-
Liu Shixin authored
This sets the HAVE_ARCH_HUGE_VMAP option, and defines the required page table functions. With this feature, ioremap area will be mapped with huge page granularity according to its actual size. This feature can be disabled by kernel parameter "nohugeiomap". Signed-off-by:
-
- 28 Oct, 2022 2 commits
-
-
Cleo John authored
Change the two comments in ucontext.h by getting them up to the coding style proposed by torvalds. Signed-off-by:
Cleo John <waterdev@galaxycrow.de> Reviewed-by:
-
Jinyu Tang authored
Add macro definition to support update_mmu_tlb() for riscv, this function is from commit:7df67697 ("mm/memory.c:Update local TLB if PTE entry exists"). update_mmu_tlb() is used when a thread notice that other cpu thread has handled the fault and changed the PTE. For MIPS, it's worth to do that,this cpu thread will trap in tlb fault again otherwise. For RISCV, it's also better to flush local tlb than do nothing in update_mmu_tlb(). There are two kinds of page fault that have update_mmu_tlb() inside: 1.page fault which PTE is NOT none, only protection check error, like write protection fault. If updata_mmu_tlb() is empty, after finsh page fault this time and re-execute, cpu will find address but protection checked error in tlb again. So this will cause another page fault. PTE in memory is good now,so update_mmu_cache() in handle_pte_fault() will be executed. If updata_mmu_tlb() is not empty flush local tlb, cpu won't find this address in tlb next time, and get entry in physical memory, so it won't cause another page fault. 2.page fault which PTE is none or swapped. For this case, this cpu thread won't cause another page fault,cpu will have tlb miss when re-execute, and get entry in memory directly. But "set pte in phycial memory and flush local tlb" is pratice in Linux, it's better to flush local tlb if it find entry in phycial memory has changed. Maybe it's same for other ARCH which can't detect PTE changed and update it in local tlb automatically. Signed-off-by:
Jinyu Tang <tjytimi@163.com> Reviewed-by:
-
- 27 Oct, 2022 4 commits
-
-
Jisheng Zhang authored
arch/riscv/kernel/head.o does not need any special treatment - the only requirement is the ".head.text" section must be placed before the normal ".text" section. The linker script does the right thing to do. The build system does not need to manipulate the link order of head.o. Signed-off-by:
-
Palmer Dabbelt authored
The PMU on T-Head C9xx cores is quite similar to the SSCOFPMF extension but not completely identical, so this series adds a T-Head PMU errata that handlen the differences. * 'riscv-pmu' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/palmer/linux: drivers/perf: riscv_pmu_sbi: add support for PMU variant on T-Head C9xx cores RISC-V: Cache SBI vendor values
-
Heiko Stuebner authored
With the T-HEAD C9XX cores being designed before or during the ratification to the SSCOFPMF extension, it implements functionality very similar but not equal to it. It implements overflow handling and also some privilege-mode filtering. While SSCOFPMF supports this for all modes, the C9XX only implements the filtering for M-mode and S-mode but not user-mode. So add some adaptions to allow the C9XX to still handle its PMU through the regular SBI PMU interface instead of defining new interfaces or drivers. To work properly, this requires a matching change in SBI, though the actual interface between kernel and SBI does not change. The main differences are a the overflow CSR and irq number. As the reading of the overflow-csr is in the hot-path during irq handling, use an errata and alternatives to not introduce new conditionals there. Reviewed-by:
Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/all/20221011231841.2951264-2-heiko@sntech.de/Signed-off-by:
-
Heiko Stuebner authored
sbi_get_mvendorid(), sbi_get_marchid() and sbi_get_mimpid() might get called multiple times, though the values of these CSRs should not change during the runtime of a specific machine. Though the values can be different depending on which hart of the system they get called. So hook into the newly introduced cpuinfo struct to allow retrieving these cached values via new functions. Also use arch_initcall for the cpuinfo setup instead, as that now clearly is "architecture specific initialization" and also makes these information available slightly earlier. [caching vendor ids] Suggested-by:
Atish Patra <atishp@atishpatra.org> [using cpuinfo struct as cache] Suggested-by:
-
- 26 Oct, 2022 1 commit
-
-
Heinrich Schuchardt authored
The adverbs 'therefor' and 'therefore' have different meaning. As the meaning here is 'consequently' the spelling should be 'therefore'. Signed-off-by:
Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Reviewed-by:
-
- 16 Oct, 2022 1 commit
-
-
Linus Torvalds authored
-
