Re: [PATCH -fixes] riscv: patch: Flush the icache right after patching to avoid illegal insns

[Palmer Dabbelt]

On Mon, 24 Jun 2024 01:21:41 PDT (-0700), alexgh...@rivosinc.com wrote:

We cannot delay the icache flush after patching some functions as we may
have patched a function that will get called before the icache flush.

The only way to completely avoid such scenario is by flushing the icache
as soon as we patch a function. This will probably be costly as we don't
batch the icache maintenance anymore.


Ya, it's going to be pretty miserable for performance.  We'd talked 
about using objtool for the static rewriting a few weeks ago in the 
patchwork meeting, but with the dynamic rewriting suffering from similar 
issues it seems best to just pick this one up.   We can always sort out 
the performance isuses later, at least this is correct.



Fixes: 6ca445d8af0e ("riscv: Fix early ftrace nop patching")
Reported-by: Conor Dooley 
Closes: 
https://lore.kernel.org/linux-riscv/20240613-lubricant-breath-061192a9489a@wendy/
Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/kernel/ftrace.c |  7 ++-
 arch/riscv/kernel/patch.c  | 26 ++
 2 files changed, 20 insertions(+), 13 deletions(-)

diff --git a/arch/riscv/kernel/ftrace.c b/arch/riscv/kernel/ftrace.c
index 87cbd86576b2..4b95c574fd04 100644
--- a/arch/riscv/kernel/ftrace.c
+++ b/arch/riscv/kernel/ftrace.c
@@ -120,9 +120,6 @@ int ftrace_init_nop(struct module *mod, struct dyn_ftrace 
*rec)
out = ftrace_make_nop(mod, rec, MCOUNT_ADDR);
mutex_unlock(&text_mutex);

-   if (!mod)
-   local_flush_icache_range(rec->ip, rec->ip + MCOUNT_INSN_SIZE);
-
return out;
 }

@@ -156,9 +153,9 @@ static int __ftrace_modify_code(void *data)
} else {
while (atomic_read(¶m->cpu_count) <= num_online_cpus())
cpu_relax();
-   }

-   local_flush_icache_all();
+   local_flush_icache_all();
+   }

return 0;
 }
diff --git a/arch/riscv/kernel/patch.c b/arch/riscv/kernel/patch.c
index 4007563fb607..ab03732d06c4 100644
--- a/arch/riscv/kernel/patch.c
+++ b/arch/riscv/kernel/patch.c
@@ -89,6 +89,14 @@ static int __patch_insn_set(void *addr, u8 c, size_t len)

memset(waddr, c, len);

+   /*
+* We could have just patched a function that is about to be
+* called so make sure we don't execute partially patched
+* instructions by flushing the icache as soon as possible.
+*/
+   local_flush_icache_range((unsigned long)waddr,
+(unsigned long)waddr + len);
+
patch_unmap(FIX_TEXT_POKE0);

if (across_pages)
@@ -135,6 +143,14 @@ static int __patch_insn_write(void *addr, const void 
*insn, size_t len)

ret = copy_to_kernel_nofault(waddr, insn, len);

+   /*
+* We could have just patched a function that is about to be
+* called so make sure we don't execute partially patched
+* instructions by flushing the icache as soon as possible.
+*/
+   local_flush_icache_range((unsigned long)waddr,
+(unsigned long)waddr + len);
+
patch_unmap(FIX_TEXT_POKE0);

if (across_pages)
@@ -189,9 +205,6 @@ int patch_text_set_nosync(void *addr, u8 c, size_t len)

ret = patch_insn_set(tp, c, len);

-   if (!ret)
-   flush_icache_range((uintptr_t)tp, (uintptr_t)tp + len);
-
return ret;
 }
 NOKPROBE_SYMBOL(patch_text_set_nosync);
@@ -224,9 +237,6 @@ int patch_text_nosync(void *addr, const void *insns, size_t 
len)

ret = patch_insn_write(tp, insns, len);

-   if (!ret)
-   flush_icache_range((uintptr_t) tp, (uintptr_t) tp + len);
-
return ret;
 }
 NOKPROBE_SYMBOL(patch_text_nosync);
@@ -253,9 +263,9 @@ static int patch_text_cb(void *data)
} else {
while (atomic_read(&patch->cpu_count) <= num_online_cpus())
cpu_relax();
-   }

-   local_flush_icache_all();
+   local_flush_icache_all();
+   }

return ret;
 }

Re: [PATCH 1/8] riscv: stacktrace: convert arch_stack_walk() to noinstr

[Palmer Dabbelt]

On Tue, 18 Jun 2024 02:55:32 PDT (-0700), a...@ghiti.fr wrote:

Hi Andy,

On 13/06/2024 09:11, Andy Chiu wrote:

arch_stack_walk() is called intensively in function_graph when the
kernel is compiled with CONFIG_TRACE_IRQFLAGS. As a result, the kernel
logs a lot of arch_stack_walk and its sub-functions into the ftrace
buffer. However, these functions should not appear on the trace log
because they are part of the ftrace itself. This patch references what
arm64 does for the smae function. So it further prevent the re-enter
kprobe issue, which is also possible on riscv.

Related-to: commit 0fbcd8abf337 ("arm64: Prohibit instrumentation on 
arch_stack_walk()")
Fixes: 680341382da5 ("riscv: add CALLER_ADDRx support")
Signed-off-by: Andy Chiu 
---
  arch/riscv/kernel/stacktrace.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/stacktrace.c b/arch/riscv/kernel/stacktrace.c
index 528ec7cc9a62..0d3f00eb0bae 100644
--- a/arch/riscv/kernel/stacktrace.c
+++ b/arch/riscv/kernel/stacktrace.c
@@ -156,7 +156,7 @@ unsigned long __get_wchan(struct task_struct *task)
return pc;
  }

-noinline void arch_stack_walk(stack_trace_consume_fn consume_entry, void 
*cookie,
+noinline noinstr void arch_stack_walk(stack_trace_consume_fn consume_entry, 
void *cookie,
 struct task_struct *task, struct pt_regs *regs)
  {
walk_stackframe(task, regs, consume_entry, cookie);



Reviewed-by: Alexandre Ghiti 

I'll try to make this go into -fixes, this is in my fixes branch at least.


Looks like there's some comments on the rest of the patch set.

Andy: aree you going to send a v2, or do you want me to just pick this 
one up onto fixes now and then handle the rest later?




Thanks,

Alex

[GIT PULL] RISC-V Fixes for 5.12-rc8 (or 5.12)

[Palmer Dabbelt]

The following changes since commit e49d033bddf5b565044e2abe4241353959bc9120:

  Linux 5.12-rc6 (2021-04-04 14:15:36 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.12-rc8

for you to fetch changes up to 7ae11635ec90072083503c6b6485cdffe46203b3:

  riscv: keep interrupts disabled for BREAKPOINT exception (2021-04-15 21:32:40 
-0700)


RISC-V Fixes for 5.12-rc8 (or 5.12)

I have a handful of fixes that I'd like to target for 5.12, regardless
of whether there's an rc8 or not:

* A fix to properly select SPARSEMEM_STATIC on rv32.
* A handful of fixes to kprobes.

I don't generally like sending stuff this late, but these all seem
pretty safe.


Jisheng Zhang (3):
  riscv: add do_page_fault and do_trap_break into the kprobes blacklist
  riscv: kprobes/ftrace: Add recursion protection to the ftrace callback
  riscv: keep interrupts disabled for BREAKPOINT exception

Kefeng Wang (1):
  riscv: Fix spelling mistake "SPARSEMEM" to "SPARSMEM"

 arch/riscv/Kconfig|  2 +-
 arch/riscv/kernel/entry.S |  3 +++
 arch/riscv/kernel/probes/ftrace.c | 11 ++-
 arch/riscv/kernel/traps.c |  1 +
 arch/riscv/mm/fault.c |  1 +
 5 files changed, 16 insertions(+), 2 deletions(-)

Re: [PATCH] riscv: Protect kernel linear mapping only if CONFIG_STRICT_KERNEL_RWX is set

[Palmer Dabbelt]

On Fri, 16 Apr 2021 03:47:19 PDT (-0700), a...@ghiti.fr wrote:

Hi Anup,

Le 4/16/21 à 6:41 AM, Anup Patel a écrit :

On Thu, Apr 15, 2021 at 4:34 PM Alexandre Ghiti  wrote:


If CONFIG_STRICT_KERNEL_RWX is not set, we cannot set different permissions
to the kernel data and text sections, so make sure it is defined before
trying to protect the kernel linear mapping.

Signed-off-by: Alexandre Ghiti 


Maybe you should add "Fixes:" tag in commit tag ?


Yes you're right I should have done that. Maybe Palmer will squash it as
it just entered for-next?


Ya, I'll do it.  My testing box was just tied up last night for the rc8 
PR, so I threw this on for-next to get the buildbots to take a look.  
It's a bit too late to take something for this week, as I try to be 
pretty conservative this late in the cycle.  There's another kprobes fix 
on the list so if we end up with an rc8 I might send this along with 
that, otherwise this'll just go onto for-next before the linear map 
changes that exercise the bug.


You're more than welcome to just dig up the fixes tag and reply, my 
scripts pull all tags from replies (just like Revieweb-by).  Otherwise 
I'll do it myself, most people don't really post Fixes tags that 
accurately so I go through it for pretty much everything anyway.


Thanks for sorting this out so quickly!





Otherwise it looks good.

Reviewed-by: Anup Patel 


Thank you!

Alex



Regards,
Anup


---
  arch/riscv/kernel/setup.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 626003bb5fca..ab394d173cd4 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -264,12 +264,12 @@ void __init setup_arch(char **cmdline_p)

 sbi_init();

-   if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX))
+   if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX)) {
 protect_kernel_text_data();
-
-#if defined(CONFIG_64BIT) && defined(CONFIG_MMU)
-   protect_kernel_linear_mapping_text_rodata();
+#ifdef CONFIG_64BIT
+   protect_kernel_linear_mapping_text_rodata();
  #endif
+   }

  #ifdef CONFIG_SWIOTLB
 swiotlb_init(1);
--
2.20.1



___
linux-riscv mailing list
linux-ri...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

Re: [PATCH v3 2/2] riscv: Cleanup KASAN_VMALLOC support

[Palmer Dabbelt]

On Tue, 30 Mar 2021 02:47:30 PDT (-0700), ge...@linux-m68k.org wrote:

Hi Palmer,

On Tue, Mar 30, 2021 at 7:08 AM Palmer Dabbelt  wrote:

On Sat, 13 Mar 2021 00:45:05 PST (-0800), a...@ghiti.fr wrote:
> When KASAN vmalloc region is populated, there is no userspace process and
> the page table in use is swapper_pg_dir, so there is no need to read
> SATP. Then we can use the same scheme used by kasan_populate_p*d
> functions to go through the page table, which harmonizes the code.
>
> In addition, make use of set_pgd that goes through all unused page table
> levels, contrary to p*d_populate functions, which makes this function work
> whatever the number of page table levels.
>
> Signed-off-by: Alexandre Ghiti 
> Reviewed-by: Palmer Dabbelt 
> ---
>  arch/riscv/mm/kasan_init.c | 59 --
>  1 file changed, 18 insertions(+), 41 deletions(-)
>
> diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
> index 57bf4ae09361..c16178918239 100644
> --- a/arch/riscv/mm/kasan_init.c
> +++ b/arch/riscv/mm/kasan_init.c
> @@ -11,18 +11,6 @@
>  #include 
>  #include 
>
> -static __init void *early_alloc(size_t size, int node)
> -{
> - void *ptr = memblock_alloc_try_nid(size, size,
> - __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, node);
> -
> - if (!ptr)
> - panic("%pS: Failed to allocate %zu bytes align=%zx nid=%d 
from=%llx\n",
> - __func__, size, size, node, (u64)__pa(MAX_DMA_ADDRESS));
> -
> - return ptr;
> -}
> -
>  extern pgd_t early_pg_dir[PTRS_PER_PGD];
>  asmlinkage void __init kasan_early_init(void)
>  {
> @@ -155,38 +143,27 @@ static void __init kasan_populate(void *start, void 
*end)
>   memset(start, KASAN_SHADOW_INIT, end - start);
>  }
>
> -void __init kasan_shallow_populate(void *start, void *end)
> +static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned 
long end)
>  {
> - unsigned long vaddr = (unsigned long)start & PAGE_MASK;
> - unsigned long vend = PAGE_ALIGN((unsigned long)end);
> - unsigned long pfn;
> - int index;
> + unsigned long next;
>   void *p;
> - pud_t *pud_dir, *pud_k;
> - pgd_t *pgd_dir, *pgd_k;
> - p4d_t *p4d_dir, *p4d_k;
> -
> - while (vaddr < vend) {
> - index = pgd_index(vaddr);
> - pfn = csr_read(CSR_SATP) & SATP_PPN;
> - pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
> - pgd_k = init_mm.pgd + index;
> - pgd_dir = pgd_offset_k(vaddr);
> - set_pgd(pgd_dir, *pgd_k);
> -
> - p4d_dir = p4d_offset(pgd_dir, vaddr);
> - p4d_k  = p4d_offset(pgd_k, vaddr);
> -
> - vaddr = (vaddr + PUD_SIZE) & PUD_MASK;
> - pud_dir = pud_offset(p4d_dir, vaddr);
> - pud_k = pud_offset(p4d_k, vaddr);
> -
> - if (pud_present(*pud_dir)) {
> - p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
> - pud_populate(&init_mm, pud_dir, p);
> + pgd_t *pgd_k = pgd_offset_k(vaddr);
> +
> + do {
> + next = pgd_addr_end(vaddr, end);
> + if (pgd_page_vaddr(*pgd_k) == (unsigned 
long)lm_alias(kasan_early_shadow_pmd)) {
> + p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
> + set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
>   }
> - vaddr += PAGE_SIZE;
> - }
> + } while (pgd_k++, vaddr = next, vaddr != end);
> +}
> +
> +static void __init kasan_shallow_populate(void *start, void *end)
> +{
> + unsigned long vaddr = (unsigned long)start & PAGE_MASK;
> + unsigned long vend = PAGE_ALIGN((unsigned long)end);
> +
> + kasan_shallow_populate_pgd(vaddr, vend);
>
>   local_flush_tlb_all();
>  }

Thanks, this is on for-next.


Your for-next does not include your fixes branch, hence they now conflict,
and for-next lacks the local_flush_tlb_all().


This came up before and I don't think we ever sorted out what the right 
thing to do is.  Right now I'm keeping for-next pinned an at early RC, 
but fast-forwarding fixes to the latest RC every time I sent a PR.  I 
don't have fixes merged back into for-next because I don't want those 
merges to show up when I send my merge window PRs.


For this one I purposefully left out the local_flush_tlb_all() whene I 
pulled in this patch, and was planning on fixing it up along with any 
other merge conflicts when I send along the PR.  It does all seem like a 
bit of a song and dance here, though, so I'm open to suggestions as to 
how to run this better -- though last time I went through t

Re: [PATCH v2 0/2] Fix binfmt_flat loader for RISC-V

[Palmer Dabbelt]

On Wed, 14 Apr 2021 17:32:10 PDT (-0700), Damien Le Moal wrote:

On 2021/04/08 0:49, Damien Le Moal wrote:
RISC-V NOMMU flat binaries cannot tolerate a gap between the text and
data section as the toolchain fully resolves at compile time the PC
relative global pointer (__global_pointer$ value loaded in gp register).
Without a relocation entry provided, the flat bin loader cannot fix the
value if a gap is introduced and executables fail to run.

This series fixes this problem by allowing an architecture to request
the flat loader to suppress the gap between the text and data sections.
The first patch fixes binfmt_flat flat_load_file() using the new
configuration option CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP. The second
patch enables this option for RISCV NOMMU builds.

These patches do not change the binfmt_flat loader behavior for other
architectures.

Changes from v1:
* Replace FLAT_TEXT_DATA_NO_GAP macro with
  CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP config option (patch 1).
* Remove the addition of riscv/include/asm/flat.h and set
  CONFIG_BINFMT_FLAT_NO_TEXT_DATA_GAP for RISCV and !MMU

Damien Le Moal (2):
  binfmt_flat: allow not offsetting data start
  riscv: Disable text-data gap in flat binaries

 arch/riscv/Kconfig |  1 +
 fs/Kconfig.binfmt  |  3 +++
 fs/binfmt_flat.c   | 21 +++--
 3 files changed, 19 insertions(+), 6 deletions(-)



Ping ?

Any comment on these patches ?

Without them, RISC-V NOMMU user space does not run... I would really like to get
these in this cycle if possible.


This LGTM, but it's pretty far out of my area of expertise.  I'm happy 
to take them via my tree, but I'd prefer to get an Ack from someone.


Al, get_maintainer suggests you?

Acked-by: Palmer Dabbelt 

Re: [PATCH v5 1/3] riscv: Move kernel mapping outside of linear mapping

[Palmer Dabbelt]

On Sun, 11 Apr 2021 09:41:44 PDT (-0700), a...@ghiti.fr wrote:

This is a preparatory patch for relocatable kernel and sv48 support.

The kernel used to be linked at PAGE_OFFSET address therefore we could use
the linear mapping for the kernel mapping. But the relocated kernel base
address will be different from PAGE_OFFSET and since in the linear mapping,
two different virtual addresses cannot point to the same physical address,
the kernel mapping needs to lie outside the linear mapping so that we don't
have to copy it at the same physical offset.

The kernel mapping is moved to the last 2GB of the address space, BPF
is now always after the kernel and modules use the 2GB memory range right
before the kernel, so BPF and modules regions do not overlap. KASLR
implementation will simply have to move the kernel in the last 2GB range
and just take care of leaving enough space for BPF.

In addition, by moving the kernel to the end of the address space, both
sv39 and sv48 kernels will be exactly the same without needing to be
relocated at runtime.

Suggested-by: Arnd Bergmann 
Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/boot/loader.lds.S|  3 +-
 arch/riscv/include/asm/page.h   | 17 +-
 arch/riscv/include/asm/pgtable.h| 37 
 arch/riscv/include/asm/set_memory.h |  1 +
 arch/riscv/kernel/head.S|  3 +-
 arch/riscv/kernel/module.c  |  6 +-
 arch/riscv/kernel/setup.c   |  5 ++
 arch/riscv/kernel/vmlinux.lds.S |  3 +-
 arch/riscv/mm/fault.c   | 13 +
 arch/riscv/mm/init.c| 87 ++---
 arch/riscv/mm/kasan_init.c  |  9 +++
 arch/riscv/mm/physaddr.c|  2 +-
 12 files changed, 146 insertions(+), 40 deletions(-)

diff --git a/arch/riscv/boot/loader.lds.S b/arch/riscv/boot/loader.lds.S
index 47a5003c2e28..62d94696a19c 100644
--- a/arch/riscv/boot/loader.lds.S
+++ b/arch/riscv/boot/loader.lds.S
@@ -1,13 +1,14 @@
 /* SPDX-License-Identifier: GPL-2.0 */

 #include 
+#include 

 OUTPUT_ARCH(riscv)
 ENTRY(_start)

 SECTIONS
 {
-   . = PAGE_OFFSET;
+   . = KERNEL_LINK_ADDR;

.payload : {
*(.payload)
diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index adc9d26f3d75..22cfb2be60dc 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -90,15 +90,28 @@ typedef struct page *pgtable_t;

 #ifdef CONFIG_MMU
 extern unsigned long va_pa_offset;
+extern unsigned long va_kernel_pa_offset;
 extern unsigned long pfn_base;
 #define ARCH_PFN_OFFSET(pfn_base)
 #else
 #define va_pa_offset   0
+#define va_kernel_pa_offset0
 #define ARCH_PFN_OFFSET(PAGE_OFFSET >> PAGE_SHIFT)
 #endif /* CONFIG_MMU */

-#define __pa_to_va_nodebug(x)  ((void *)((unsigned long) (x) + va_pa_offset))
-#define __va_to_pa_nodebug(x)  ((unsigned long)(x) - va_pa_offset)
+extern unsigned long kernel_virt_addr;
+
+#define linear_mapping_pa_to_va(x) ((void *)((unsigned long)(x) + 
va_pa_offset))
+#define kernel_mapping_pa_to_va(x) ((void *)((unsigned long)(x) + 
va_kernel_pa_offset))
+#define __pa_to_va_nodebug(x)  linear_mapping_pa_to_va(x)
+
+#define linear_mapping_va_to_pa(x) ((unsigned long)(x) - va_pa_offset)
+#define kernel_mapping_va_to_pa(x) ((unsigned long)(x) - 
va_kernel_pa_offset)
+#define __va_to_pa_nodebug(x)  ({  
\
+   unsigned long _x = x;   
\
+   (_x < kernel_virt_addr) ?\
+   linear_mapping_va_to_pa(_x) : kernel_mapping_va_to_pa(_x);  
\
+   })

 #ifdef CONFIG_DEBUG_VIRTUAL
 extern phys_addr_t __virt_to_phys(unsigned long x);
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index ebf817c1bdf4..80e63a93e903 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -11,23 +11,30 @@

 #include 

-#ifndef __ASSEMBLY__
-
-/* Page Upper Directory not used in RISC-V */
-#include 
-#include 
-#include 
-#include 
+#ifndef CONFIG_MMU
+#define KERNEL_LINK_ADDR   PAGE_OFFSET
+#else

-#ifdef CONFIG_MMU
+#define ADDRESS_SPACE_END  (UL(-1))
+/*
+ * Leave 2GB for kernel and BPF at the end of the address space
+ */
+#define KERNEL_LINK_ADDR   (ADDRESS_SPACE_END - SZ_2G + 1)

 #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
 #define VMALLOC_END  (PAGE_OFFSET - 1)
 #define VMALLOC_START(PAGE_OFFSET - VMALLOC_SIZE)

+/* KASLR should leave at least 128MB for BPF after the kernel */
 #define BPF_JIT_REGION_SIZE(SZ_128M)
-#define BPF_JIT_REGION_START   (PAGE_OFFSET - BPF_JIT_REGION_SIZE)
-#define BPF_JIT_REGION_END (VMALLOC_END)
+#define BPF_JIT_REGION_START   PFN_ALIGN((unsigned long)&_end)
+#define BPF_JIT_REGION_END (BPF_JIT_REGION_START + BPF_JIT_REGION_SIZE)
+
+/* Modules always live before the kernel */
+#ifdef CONFIG_64BIT
+#define M

Re: [PATCH] riscv: locks: introduce ticket-based spinlock implementation

[Palmer Dabbelt]

On Mon, 12 Apr 2021 06:32:27 PDT (-0700), christoph...@gmail.com wrote:

On Sun, Apr 11, 2021 at 11:11 PM Palmer Dabbelt  wrote:


On Wed, 24 Mar 2021 05:53:51 PDT (-0700), a...@brainfault.org wrote:
> On Wed, Mar 24, 2021 at 6:08 PM Peter Zijlstra  wrote:
>>
>> On Wed, Mar 24, 2021 at 05:58:58PM +0530, Anup Patel wrote:
>> > On Wed, Mar 24, 2021 at 3:45 PM  wrote:
>> > >
>> > > From: Guo Ren 
>> > >
>> > > This patch introduces a ticket lock implementation for riscv, along the
>> > > same lines as the implementation for arch/arm & arch/csky.
>> > >
>> > > Signed-off-by: Guo Ren 
>> > > Cc: Catalin Marinas 
>> > > Cc: Will Deacon 
>> > > Cc: Peter Zijlstra 
>> > > Cc: Palmer Dabbelt 
>> > > Cc: Anup Patel 
>> > > Cc: Arnd Bergmann 
>> > > ---
>> > >  arch/riscv/Kconfig  |   1 +
>> > >  arch/riscv/include/asm/Kbuild   |   1 +
>> > >  arch/riscv/include/asm/spinlock.h   | 158 

>> > >  arch/riscv/include/asm/spinlock_types.h |  19 ++--
>> >
>> > NACK from myside.
>> >
>> > Linux ARM64 has moved away from ticket spinlock to qspinlock.
>> >
>> > We should directly go for qspinlock.
>>
>> I think it is a sensible intermediate step, even if you want to go
>> qspinlock. Ticket locks are more or less trivial and get you fairness
>> and all that goodness without the mind bending complexity of qspinlock.
>>
>> Once you have the ticket lock implementation solid (and qrwlock) and
>> everything, *then* start to carefully look at qspinlock.
>
> I do understand qspinlock are relatively complex but the best thing
> about qspinlock is it tries to ensure each CPU spins on it's own location.
>
> Instead of adding ticket spinlock now and later replacing it with qspinlock,
> it is better to straight away explore qspinlock hence my NACK.
>
>>
>> Now, arguably arm64 did the heavy lifting of making qspinlock good on
>> weak architectures, but if you want to do it right, you still have to
>> analyze the whole thing for your own architecture.
>
> Most of the RISC-V implementations are weak memory ordering so it
> makes more sense to explore qspinlock first.

I know I'm somewhat late to the party here.  I talked with Will (and
to a lesser extent Peter) about this a week or two ago and it seems the
best way to go here is to start with ticket locks.  They're simpler, and
in Arm land they performed better until we got to the larger systems.
Given that we don't have any high performance implementations of the
RISC-V memory model (and likely won't any time soon) it's hard to reason
about the performance of anything like this, but at a bare minimum
having fair locks is a pretty big positive and ticket locks should have
very little overhead while providing fairness.

IMO the decision between ticket and queueing locks is really more of a
property of the hardware/workload than the ISA, though there are of
course some pretty deep ISA dependencies than can make one saner than
the other.  It seems best to me to just allow users to pick their own
flavor of locks, and at least PPC is already doing that.  I threw
together a quick asm-generic ticket lock that can be selected at compile
time, but I want to spend some more time playing with the other
architectures before sending anything out.


This discussion came up again a few weeks ago because I've been stumbling over
the test-and-set implementation and was wondering if nobody cared to
improve that yet.
Then I saw, that there have been a few attempts so far, but they did not land.
So I brought this up in RVI's platform group meeting and the attendees
showed big
interest to get at least fairness. I assume Guo sent out his new
patchset as a reaction
to this call (1 or 2 days later).

We have the same situation on OpenSBI, where we've agreed (with Anup)
to go for a ticket lock implementation.
A series for that can be found here (the implementation was tested in
the kernel):
http://lists.infradead.org/pipermail/opensbi/2021-April/000789.html

In the mentioned RVI call, I've asked the question if ticket locks or
MCF locks are preferred.
And the feedback was to go for qspinlock/qrwlock. One good argument to
do so would be,
to not have to maintain an RV-specific implementation, but to use a
well-tested in-kernel mechanism.

The feedback in the call is also aligned with the previous attempts to
enable MCF-locks on RV.
However, the kernel's implementation requires sub-word atomics. And
here is, where we are.
The discussion last week was about changing the generic kernel code to
loosen its requirem

Re: [PATCH] riscv: keep interrupts disabled for BREAKPOINT exception

[Palmer Dabbelt]

On Mon, 29 Mar 2021 11:16:24 PDT (-0700), jszha...@mail.ustc.edu.cn wrote:

From: Jisheng Zhang 

Current riscv's kprobe handlers are run with both preemption and
interrupt enabled, this violates kprobe requirements. Fix this issue
by keeping interrupts disabled for BREAKPOINT exception.

Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
Signed-off-by: Jisheng Zhang 
---
 arch/riscv/kernel/entry.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 744f3209c48d..4114b65698ec 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -130,6 +130,8 @@ skip_context_tracking:
 */
andi t0, s1, SR_PIE
beqz t0, 1f
+   li t0, EXC_BREAKPOINT
+   beq s4, t0, 1f
 #ifdef CONFIG_TRACE_IRQFLAGS
call trace_hardirqs_on
 #endif


This is on fixes, with a comment as otherwise I'm just going to forget 
why.

Re: [PATCH] riscv: add do_page_fault and do_trap_break into the kprobes blacklist

[Palmer Dabbelt]

On Mon, 29 Mar 2021 11:12:26 PDT (-0700), jszha...@mail.ustc.edu.cn wrote:

From: Jisheng Zhang 

These two functions are used to implement the kprobes feature so they
can't be kprobed.

Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
Signed-off-by: Jisheng Zhang 
---
 arch/riscv/kernel/traps.c | 1 +
 arch/riscv/mm/fault.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 0879b5df11b9..1357abf79570 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -178,6 +178,7 @@ asmlinkage __visible void do_trap_break(struct pt_regs 
*regs)
else
die(regs, "Kernel BUG");
 }
+NOKPROBE_SYMBOL(do_trap_break);

 #ifdef CONFIG_GENERIC_BUG
 int is_valid_bugaddr(unsigned long pc)
diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
index 8f17519208c7..c5dbd55cbf7c 100644
--- a/arch/riscv/mm/fault.c
+++ b/arch/riscv/mm/fault.c
@@ -328,3 +328,4 @@ asmlinkage void do_page_fault(struct pt_regs *regs)
}
return;
 }
+NOKPROBE_SYMBOL(do_page_fault);


Thanks, this is on fixes.

Re: [PATCH] riscv: kprobes/ftrace: Add recursion protection to the ftrace callback

[Palmer Dabbelt]

On Mon, 29 Mar 2021 11:14:40 PDT (-0700), jszha...@mail.ustc.edu.cn wrote:

From: Jisheng Zhang 

Currently, the riscv's kprobes(powerred by ftrace) handler is
preemptible. Futher check indicates we miss something similar as the
commit c536aa1c5b17 ("kprobes/ftrace: Add recursion protection to the
ftrace callback"), so do similar modifications as the commit does.

Fixes: 829adda597fe ("riscv: Add KPROBES_ON_FTRACE supported")
Signed-off-by: Jisheng Zhang 
---
 arch/riscv/kernel/probes/ftrace.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/probes/ftrace.c 
b/arch/riscv/kernel/probes/ftrace.c
index 17ca5e923bb0..aab85a82f419 100644
--- a/arch/riscv/kernel/probes/ftrace.c
+++ b/arch/riscv/kernel/probes/ftrace.c
@@ -9,10 +9,16 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long 
parent_ip,
struct kprobe *p;
struct pt_regs *regs;
struct kprobe_ctlblk *kcb;
+   int bit;

+   bit = ftrace_test_recursion_trylock(ip, parent_ip);
+   if (bit < 0)
+   return;
+
+   preempt_disable_notrace();
p = get_kprobe((kprobe_opcode_t *)ip);
if (unlikely(!p) || kprobe_disabled(p))
-   return;
+   goto out;

regs = ftrace_get_regs(fregs);
kcb = get_kprobe_ctlblk();
@@ -45,6 +51,9 @@ void kprobe_ftrace_handler(unsigned long ip, unsigned long 
parent_ip,
 */
__this_cpu_write(current_kprobe, NULL);
}
+out:
+   preempt_enable_notrace();
+   ftrace_test_recursion_unlock(bit);
 }
 NOKPROBE_SYMBOL(kprobe_ftrace_handler);


Thanks, this is on fixes.

Re: [PATCH] samples/kprobes: Add riscv support

[Palmer Dabbelt]

On Mon, 29 Mar 2021 11:04:16 PDT (-0700), jszha...@mail.ustc.edu.cn wrote:

From: Jisheng Zhang 

Add riscv specific info dump in both handler_pre() and handler_post().

Signed-off-by: Jisheng Zhang 
---
 samples/kprobes/kprobe_example.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/samples/kprobes/kprobe_example.c b/samples/kprobes/kprobe_example.c
index 331dcf151532..c495664c0a9b 100644
--- a/samples/kprobes/kprobe_example.c
+++ b/samples/kprobes/kprobe_example.c
@@ -47,6 +47,10 @@ static int __kprobes handler_pre(struct kprobe *p, struct 
pt_regs *regs)
pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx, cpsr = 0x%lx\n",
p->symbol_name, p->addr, (long)regs->ARM_pc, 
(long)regs->ARM_cpsr);
 #endif
+#ifdef CONFIG_RISCV
+   pr_info("<%s> pre_handler: p->addr = 0x%p, pc = 0x%lx, status = 
0x%lx\n",
+   p->symbol_name, p->addr, regs->epc, regs->status);
+#endif
 #ifdef CONFIG_S390
pr_info("<%s> pre_handler: p->addr, 0x%p, ip = 0x%lx, flags = 0x%lx\n",
p->symbol_name, p->addr, regs->psw.addr, regs->flags);
@@ -80,6 +84,10 @@ static void __kprobes handler_post(struct kprobe *p, struct 
pt_regs *regs,
pr_info("<%s> post_handler: p->addr = 0x%p, cpsr = 0x%lx\n",
p->symbol_name, p->addr, (long)regs->ARM_cpsr);
 #endif
+#ifdef CONFIG_RISCV
+   pr_info("<%s> post_handler: p->addr = 0x%p, status = 0x%lx\n",
+   p->symbol_name, p->addr, regs->status);
+#endif
 #ifdef CONFIG_S390
pr_info("<%s> pre_handler: p->addr, 0x%p, flags = 0x%lx\n",
p->symbol_name, p->addr, regs->flags);


Thanks, this is on for-next.

Re: [PATCH] implement flush_cache_vmap and flush_cache_vunmap for RISC-V

[Palmer Dabbelt]

On Sun, 28 Mar 2021 18:55:09 PDT (-0700), l...@jiuyang.me wrote:

This patch implements flush_cache_vmap and flush_cache_vunmap for
RISC-V, since these functions might modify PTE. Without this patch,
SFENCE.VMA won't be added to related codes, which might introduce a bug
in some out-of-order micro-architecture implementations.

Signed-off-by: Jiuyang Liu 
---
 arch/riscv/include/asm/cacheflush.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/riscv/include/asm/cacheflush.h 
b/arch/riscv/include/asm/cacheflush.h
index 23ff70350992..4adf25248c43 100644
--- a/arch/riscv/include/asm/cacheflush.h
+++ b/arch/riscv/include/asm/cacheflush.h
@@ -8,6 +8,14 @@

 #include 

+/*
+ * flush_cache_vmap and flush_cache_vunmap might modify PTE, needs SFENCE.VMA.
+ * - flush_cache_vmap is invoked after map_kernel_range() has installed the 
page table entries.
+ * - flush_cache_vunmap is invoked before unmap_kernel_range() deletes the 
page table entries


These should have line breaks.


+ */
+#define flush_cache_vmap(start, end) flush_tlb_all()


We shouldn't need cache flushes for permission upgrades: the ISA allows 
the old mappings to be visible until a fence, but the theory is that 
window will be sort for reasonable architectures so the overhead of 
flushing the entire TLB will overwhelm the extra faults.  There are a 
handful of places where we preemptively flush, but those are generally 
because we can't handle the faults correctly.


If you have some benchmark that demonstrates a performance issue on real 
hardware here then I'm happy to talk about this further, but this 
assumption is all over arch/riscv so I'd prefer to keep things 
consistent for now.



+#define flush_cache_vunmap(start, end) flush_tlb_all()


This one does seem necessary.


+
 static inline void local_flush_icache_all(void)
 {
asm volatile ("fence.i" ::: "memory");

Re: [PATCH 0/3] Fix CONFIG_FUNCTION_TRACER with clang

[Palmer Dabbelt]

On Thu, 25 Mar 2021 15:38:04 PDT (-0700), nat...@kernel.org wrote:

Hi all,

This series fixes function tracing with clang.

Patch 1 adjusts the mcount regex in scripts/recordmcount.pl to handle
the presence of PLT relocations, which happen with clang. Without this,
the mcount_loc section will not be created properly.

Patch 2 adds a workaround for clang less than 13.0.0 in relation to the
mcount symbol name, which was "mcount" rather than "_mcount". This was
written as a separate patch so that it can be reverted when the minimum
clang version is bumped to clang 13.0.0.

Patch 3 avoids a build error when -fpatchable-function-entry is not
available, which is the case with clang less than 13.0.0. This will make
dynamic ftrace unavailable but all of the other function tracing should
work due to the prescence of the previous patch.

I am hoping this series can go in as fixes for 5.12, due to patch 3, but
if not, they can always be backported (patches 1 and 2 are already
marked for stable).

This series has been build tested with gcc-8 through gcc-10 and clang-11
through clang-13 with defconfig and nommu_virt_defconfig plus
CONFIG_FTRACE=y and CONFIG_FUNCTION_TRACER=y then boot tested under
QEMU.

Cheers,
Nathan

Nathan Chancellor (3):
  scripts/recordmcount.pl: Fix RISC-V regex for clang
  riscv: Workaround mcount name prior to clang-13
  riscv: Select HAVE_DYNAMIC_FTRACE when -fpatchable-function-entry is
available

 arch/riscv/Kconfig  |  2 +-
 arch/riscv/include/asm/ftrace.h | 14 --
 arch/riscv/kernel/mcount.S  | 10 +-
 scripts/recordmcount.pl |  2 +-
 4 files changed, 19 insertions(+), 9 deletions(-)


Thanks, these are on for-next.

Re: [PATCH] riscv: Use $(LD) instead of $(CC) to link vDSO

[Palmer Dabbelt]

On Thu, 25 Mar 2021 14:51:56 PDT (-0700), nat...@kernel.org wrote:

Currently, the VDSO is being linked through $(CC). This does not match
how the rest of the kernel links objects, which is through the $(LD)
variable.

When linking with clang, there are a couple of warnings about flags that
will not be used during the link:

clang-12: warning: argument unused during compilation: '-no-pie' 
[-Wunused-command-line-argument]
clang-12: warning: argument unused during compilation: '-pg' 
[-Wunused-command-line-argument]

'-no-pie' was added in commit 85602bea297f ("RISC-V: build vdso-dummy.o
with -no-pie") to override '-pie' getting added to the ld command from
distribution versions of GCC that enable PIE by default. It is
technically no longer needed after commit c2c81bb2f691 ("RISC-V: Fix the
VDSO symbol generaton for binutils-2.35+"), which removed vdso-dummy.o
in favor of generating vdso-syms.S from vdso.so with $(NM) but this also
resolves the issue in case it ever comes back due to having full control
over the $(LD) command. '-pg' is for function tracing, it is not used
during linking as clang states.

These flags could be removed/filtered to fix the warnings but it is
easier to just match the rest of the kernel and use $(LD) directly for
linking. See commits

  fe00e50b2db8 ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO")
  691efbedc60d ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO")
  2ff906994b6c ("MIPS: VDSO: Use $(LD) instead of $(CC) to link VDSO")
  2b2a25845d53 ("s390/vdso: Use $(LD) instead of $(CC) to link vDSO")

for more information.

The flags are converted to linker flags and '--eh-frame-hdr' is added to
match what is added by GCC implicitly, which can be seen by adding '-v'
to GCC's invocation.

Additionally, since this area is being modified, use the $(OBJCOPY)
variable instead of an open coded $(CROSS_COMPILE)objcopy so that the
user's choice of objcopy binary is respected.

Link: https://github.com/ClangBuiltLinux/linux/issues/803
Link: https://github.com/ClangBuiltLinux/linux/issues/970
Signed-off-by: Nathan Chancellor 
---
 arch/riscv/kernel/vdso/Makefile | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/riscv/kernel/vdso/Makefile b/arch/riscv/kernel/vdso/Makefile
index 71a315e73cbe..ca2b40dfd24b 100644
--- a/arch/riscv/kernel/vdso/Makefile
+++ b/arch/riscv/kernel/vdso/Makefile
@@ -41,11 +41,10 @@ KASAN_SANITIZE := n
 $(obj)/vdso.o: $(obj)/vdso.so

 # link rule for the .so file, .lds has to be first
-SYSCFLAGS_vdso.so.dbg = $(c_flags)
 $(obj)/vdso.so.dbg: $(src)/vdso.lds $(obj-vdso) FORCE
$(call if_changed,vdsold)
-SYSCFLAGS_vdso.so.dbg = -shared -s -Wl,-soname=linux-vdso.so.1 \
-   -Wl,--build-id=sha1 -Wl,--hash-style=both
+LDFLAGS_vdso.so.dbg = -shared -s -soname=linux-vdso.so.1 \
+   --build-id=sha1 --hash-style=both --eh-frame-hdr

 # We also create a special relocatable object that should mirror the symbol
 # table and layout of the linked DSO. With ld --just-symbols we can then
@@ -60,13 +59,10 @@ $(obj)/%.so: $(obj)/%.so.dbg FORCE

 # actual build commands
 # The DSO images are built using a special linker script
-# Add -lgcc so rv32 gets static muldi3 and lshrdi3 definitions.
 # Make sure only to export the intended __vdso_xxx symbol offsets.
 quiet_cmd_vdsold = VDSOLD  $@
-  cmd_vdsold = $(CC) $(KBUILD_CFLAGS) $(call cc-option, -no-pie) -nostdlib 
-nostartfiles $(SYSCFLAGS_$(@F)) \
-   -Wl,-T,$(filter-out FORCE,$^) -o $@.tmp && \
-   $(CROSS_COMPILE)objcopy \
-   $(patsubst %, -G __vdso_%, $(vdso-syms)) $@.tmp $@ 
&& \
+  cmd_vdsold = $(LD) $(ld_flags) -T $(filter-out FORCE,$^) -o $@.tmp && \
+   $(OBJCOPY) $(patsubst %, -G __vdso_%, $(vdso-syms)) $@.tmp $@ 
&& \
rm $@.tmp

 # Extracts symbol offsets from the VDSO, converting them into an assembly file


Thanks, this is on for-next.

Re: [PATCH] riscv: locks: introduce ticket-based spinlock implementation

[Palmer Dabbelt]

On Wed, 24 Mar 2021 05:53:51 PDT (-0700), a...@brainfault.org wrote:

On Wed, Mar 24, 2021 at 6:08 PM Peter Zijlstra  wrote:


On Wed, Mar 24, 2021 at 05:58:58PM +0530, Anup Patel wrote:
> On Wed, Mar 24, 2021 at 3:45 PM  wrote:
> >
> > From: Guo Ren 
> >
> > This patch introduces a ticket lock implementation for riscv, along the
> > same lines as the implementation for arch/arm & arch/csky.
> >
> > Signed-off-by: Guo Ren 
> > Cc: Catalin Marinas 
> > Cc: Will Deacon 
> > Cc: Peter Zijlstra 
> > Cc: Palmer Dabbelt 
> > Cc: Anup Patel 
> > Cc: Arnd Bergmann 
> > ---
> >  arch/riscv/Kconfig  |   1 +
> >  arch/riscv/include/asm/Kbuild   |   1 +
> >  arch/riscv/include/asm/spinlock.h   | 158 

> >  arch/riscv/include/asm/spinlock_types.h |  19 ++--
>
> NACK from myside.
>
> Linux ARM64 has moved away from ticket spinlock to qspinlock.
>
> We should directly go for qspinlock.

I think it is a sensible intermediate step, even if you want to go
qspinlock. Ticket locks are more or less trivial and get you fairness
and all that goodness without the mind bending complexity of qspinlock.

Once you have the ticket lock implementation solid (and qrwlock) and
everything, *then* start to carefully look at qspinlock.


I do understand qspinlock are relatively complex but the best thing
about qspinlock is it tries to ensure each CPU spins on it's own location.

Instead of adding ticket spinlock now and later replacing it with qspinlock,
it is better to straight away explore qspinlock hence my NACK.



Now, arguably arm64 did the heavy lifting of making qspinlock good on
weak architectures, but if you want to do it right, you still have to
analyze the whole thing for your own architecture.


Most of the RISC-V implementations are weak memory ordering so it
makes more sense to explore qspinlock first.


I know I'm somewhat late to the party here.  I talked with Will (and 
to a lesser extent Peter) about this a week or two ago and it seems the 
best way to go here is to start with ticket locks.  They're simpler, and 
in Arm land they performed better until we got to the larger systems.  
Given that we don't have any high performance implementations of the 
RISC-V memory model (and likely won't any time soon) it's hard to reason 
about the performance of anything like this, but at a bare minimum 
having fair locks is a pretty big positive and ticket locks should have 
very little overhead while providing fairness.


IMO the decision between ticket and queueing locks is really more of a 
property of the hardware/workload than the ISA, though there are of 
course some pretty deep ISA dependencies than can make one saner than 
the other.  It seems best to me to just allow users to pick their own 
flavor of locks, and at least PPC is already doing that.  I threw 
together a quick asm-generic ticket lock that can be selected at compile 
time, but I want to spend some more time playing with the other 
architectures before sending anything out.

Re: [PATCH v16 00/17] KVM RISC-V Support

[Palmer Dabbelt]

On Wed, 31 Mar 2021 02:21:58 PDT (-0700), pbonz...@redhat.com wrote:

On 30/03/21 07:48, Anup Patel wrote:


It seems Andrew does not want to freeze H-extension until we have virtualization
aware interrupt controller (such as RISC-V AIA specification) and IOMMU. Lot
of us feel that these things can be done independently because RISC-V
H-extension already has provisions for external interrupt controller with
virtualization support.


Sorry to hear that.  It's really gotten to a point where I'm just 
embarrassed with how the RISC-V foundation is being run -- not sure if 
these other ones bled into Linux land, but this is the third ISA 
extension that's blown up over the last few weeks.  We had a lot of 
discussion about this on the binutils/GCC side of things and I've 
managed to convince myself that coupling the software stack to the 
specification process isn't viable -- we made that decision under the 
assumption that specifications would actually progress through the 
process, but in practice that's just not happening.


My goal with the RISC-V stuff has always been getting us to a place 
where we have real shipping products running a software stack that is as 
close as possible to the upstream codebases.  I see that as the only way 
to get the software stack to a point where it can be sustainably 
maintained.  The "only frozen extensions" policy was meant to help this 
by steering vendors towards a common base we could support, but in 
practice it's just not working out.  The specification process is just 
so unreliable that in practice everything that gets built ends up 
relying on some non-standard behavior: whether it's a draft extension, 
some vendor-specific extension, or just some implementation quirks.  
There's always going to be some degree of that going on, but over the 
last year or so we've just stopped progressing.


My worry with accepting the draft extensions is that we have no 
guarantee of compatibility between various drafts, which makes 
supporting multiple versions much more difficult.  I've always really 
only been worried about supporting what gets implemented in a chip I can 
actually run code on, as I can at least guarantee that doesn't change.  
In practice that really has nothing to do with the specification freeze: 
even ratified specifications change in ways that break compatibility so 
we need to support multiple versions anyway.  That's why we've got 
things like the K210 support (which doesn't quite follow the ratified 
specs) and are going to take the errata stuff.  I hadn't been all that 
worried about the H support because there was a plan to get is to 
hardware, but with the change I'm not really sure how that's going to 
happen.



Yes, frankly that's pretty ridiculous as it's perfectly possible to
emulate the interrupt controller in software (and an IOMMU is not needed
at all if you are okay with emulated or paravirtualized devices---which
is almost always the case except for partitioning hypervisors).


There's certainly some risk to freezing the H extension before we have 
all flavors of systems up and running.  I spent a lot of time arguing 
that case years ago before we started telling people that the H 
extension just needed implementation, but that's not the decision we 
made.  I don't really do RISC-V foundation stuff any more so I don't 
know why this changed, but it's just too late.  It would be wonderful to 
have an implementation of everything we need to build out one of these 
complex systems, but I just just don't see how the current plan gets 
there: that's a huge amount of work and I don't see why anyone would 
commit to that when they can't count on it being supported when it's 
released.


There are clearly some systems that can be built with this as it stands.  
They're not going to satisfy every use case, but at least we'll get 
people to start seriously using the spec.  That's the only way I can see 
to move forward with this.  It's pretty clear that sitting around and 
waiting doesn't work, we've tried that.



Palmer, are you okay with merging RISC-V KVM?  Or should we place it in
drivers/staging/riscv/kvm?


I'm certainly ready to drop my objections to merging the code based on 
it targeting a draft extension, but at a bare minimum I want to get a 
new policy in place that everyone can agree to for merging code.  I've 
tried to draft up a new policy a handful of times this week, but I'm not 
really quite sure how to go about this: ultimately trying to build 
stable interfaces around an unstable ISA is just a losing battle.  I've 
got a bunch of stuff going on right now, but I'll try to find some time 
to actually sit down and finish one.


I know it might seem odd to complain about how slowly things are going 
and then throw up another roadblock, but I really do think this is a 
very important thing to get right.  I'm just not sure how we're going to 
get anywhere with RISC-V without someone providing stability, so I want 
to make sure that wh

[GIT PULL] RISC-V Fixes for 5.12-rc6

[Palmer Dabbelt]

The following changes since commit a5e13c6df0e41702d2b2c77c8ad41677ebb065b3:

  Linux 5.12-rc5 (2021-03-28 15:48:16 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.12-rc6

for you to fetch changes up to 1adbc2941eee8acbe3c7dc6b51cdbc5a9bf19565:

  riscv: Make NUMA depend on MMU (2021-04-01 21:37:08 -0700)


RISC-V Fixes for 5.12-rc6

I have a handful of fixes for 5.12:

* A fix for a stack tracing regression related to "const register asm"
  variables, which have unexpected behavior.
* A fix to put_user() that ensures the value to be written is evaluated
  before enabling access to userspace memory..
* A fix to align the exception vector table correctly, so we don't rely
  on the firmware's handling of unaligned accesses.
* A build fix to make NUMA depend on MMU, which triggers some
  randconfigs.


Ben Dooks (1):
  riscv: evaluate put_user() arg before enabling user access

Kefeng Wang (2):
  riscv: Drop const annotation for sp
  riscv: Make NUMA depend on MMU

Yang Li (1):
  riscv: remove unneeded semicolon

Zihao Yu (1):
  riscv,entry: fix misaligned base for excp_vect_table

 arch/riscv/Kconfig   | 2 +-
 arch/riscv/include/asm/uaccess.h | 7 +--
 arch/riscv/kernel/entry.S| 1 +
 arch/riscv/kernel/stacktrace.c   | 2 +-
 arch/riscv/mm/kasan_init.c   | 2 +-
 5 files changed, 9 insertions(+), 5 deletions(-)

Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024

[Palmer Dabbelt]

On Tue, 30 Mar 2021 13:31:45 PDT (-0700), ma...@orcam.me.uk wrote:

On Mon, 29 Mar 2021, Palmer Dabbelt wrote:


> --- /dev/null
> +++ b/arch/riscv/include/uapi/asm/setup.h
> @@ -0,0 +1,8 @@
> +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
> +
> +#ifndef _UAPI_ASM_RISCV_SETUP_H
> +#define _UAPI_ASM_RISCV_SETUP_H
> +
> +#define COMMAND_LINE_SIZE 1024
> +
> +#endif /* _UAPI_ASM_RISCV_SETUP_H */

I put this on fixes, but it seemes like this should really be a Kconfig
enttry.  Either way, ours was quite a bit smaller than most architectures and
it's great that syzbot has started to find bugs, so I'd rather get this in
sooner.


 This macro is exported as a part of the user API so it must not depend on
Kconfig.  Also changing it (rather than say adding COMMAND_LINE_SIZE_V2 or
switching to an entirely new data object that has its dimension set in a
different way) requires careful evaluation as external binaries have and
will have the value it expands to compiled in, so it's a part of the ABI
too.


Thanks, I didn't realize this was part of the user BI.  In that case we 
really can't chage it, so we'll have to sort out some other way do fix 
whatever is going on.


I've dropped this from fixes.

Re: linux-next: manual merge of the risc-v tree with Linus' tree

[Palmer Dabbelt]

On Tue, 30 Mar 2021 15:40:34 PDT (-0700), Stephen Rothwell wrote:

Hi all,

Today's linux-next merge of the risc-v tree got a conflict in:

  arch/riscv/mm/kasan_init.c

between commits:

  f3773dd031de ("riscv: Ensure page table writes are flushed when initializing KASAN 
vmalloc")
  78947bdfd752 ("RISC-V: kasan: Declare kasan_shallow_populate() static")

from Linus' tree and commit:

  2da073c19641 ("riscv: Cleanup KASAN_VMALLOC support")

from the risc-v tree.

I fixed it up (I think - see below) and can carry the fix as
necessary. This is now fixed as far as linux-next is concerned, but any
non trivial conflicts should be mentioned to your upstream maintainer
when your tree is submitted for merging.  You may also want to consider
cooperating with the maintainer of the conflicting tree to minimise any
particularly complex conflicts.


They're my own trees ;)

I'm not so great at reading merge diffs, but the right fix here is to 
have the local_flush_tlb_all() after the call to 
kasan_shallow_populate_pgd(), just as there is one after 
kasan_populate_pgd().  My merge diff looks like this


diff --cc arch/riscv/mm/kasan_init.c
index 2c39f0386673,4f85c6d0ddf8..ec0029097251
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@@ -162,8 -159,36 +162,10 @@@ static void __init kasan_shallow_popula
 {
   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
   unsigned long vend = PAGE_ALIGN((unsigned long)end);
-  unsigned long pfn;
-  int index;
-  void *p;
-  pud_t *pud_dir, *pud_k;
-  pgd_t *pgd_dir, *pgd_k;
-  p4d_t *p4d_dir, *p4d_k;
-
-  while (vaddr < vend) {
-  index = pgd_index(vaddr);
-  pfn = csr_read(CSR_SATP) & SATP_PPN;
-  pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
-  pgd_k = init_mm.pgd + index;
-  pgd_dir = pgd_offset_k(vaddr);
-  set_pgd(pgd_dir, *pgd_k);
-
-  p4d_dir = p4d_offset(pgd_dir, vaddr);
-  p4d_k  = p4d_offset(pgd_k, vaddr);
-
-  vaddr = (vaddr + PUD_SIZE) & PUD_MASK;
-  pud_dir = pud_offset(p4d_dir, vaddr);
-  pud_k = pud_offset(p4d_k, vaddr);
-
-  if (pud_present(*pud_dir)) {
-  p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
-  pud_populate(&init_mm, pud_dir, p);
-  }
-  vaddr += PAGE_SIZE;
-  }
+
+  kasan_shallow_populate_pgd(vaddr, vend);
+
+   local_flush_tlb_all();
 }

 void __init kasan_init(void)

which doesn't include the diff to kasan_shallow_populate_pgd().  Not 
sure if that's just because my diff is in the other direction, though.  
The expected result is that kasan_shallow_populate_pgd() exists both pre 
and post merge.




--
Cheers,
Stephen Rothwell

diff --cc arch/riscv/mm/kasan_init.c
index 4f85c6d0ddf8,2c39f0386673..
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@@ -153,44 -141,31 +141,33 @@@ static void __init kasan_populate(void 
  
  	local_flush_tlb_all();

memset(start, KASAN_SHADOW_INIT, end - start);
  }
  
+ static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long end)

+ {
+   unsigned long next;
+   void *p;
+   pgd_t *pgd_k = pgd_offset_k(vaddr);
+ 
+ 	do {

+   next = pgd_addr_end(vaddr, end);
+   if (pgd_page_vaddr(*pgd_k) == (unsigned 
long)lm_alias(kasan_early_shadow_pmd)) {
+   p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+   set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
+   }
+   } while (pgd_k++, vaddr = next, vaddr != end);
+ }
+ 
  static void __init kasan_shallow_populate(void *start, void *end)

  {
unsigned long vaddr = (unsigned long)start & PAGE_MASK;
unsigned long vend = PAGE_ALIGN((unsigned long)end);
-   unsigned long pfn;
-   int index;
-   void *p;
-   pud_t *pud_dir, *pud_k;
-   pgd_t *pgd_dir, *pgd_k;
-   p4d_t *p4d_dir, *p4d_k;
- 
- 	while (vaddr < vend) {

-   index = pgd_index(vaddr);
-   pfn = csr_read(CSR_SATP) & SATP_PPN;
-   pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
-   pgd_k = init_mm.pgd + index;
-   pgd_dir = pgd_offset_k(vaddr);
-   set_pgd(pgd_dir, *pgd_k);
- 
- 		p4d_dir = p4d_offset(pgd_dir, vaddr);

-   p4d_k  = p4d_offset(pgd_k, vaddr);
- 
- 		vaddr = (vaddr + PUD_SIZE) & PUD_MASK;

-   pud_dir = pud_offset(p4d_dir, vaddr);
-   pud_k = pud_offset(p4d_k, vaddr);
- 
- 		if (pud_present(*pud_dir)) {

-   p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
-   pud_populate(&init_mm, pud_dir, p);
-   }
-   vaddr += PAGE_SIZE;
-   }
+ 
+ 	kasan_shallow_populate_pgd(vaddr, vend);

 +
 +  local_flush_tlb_all();
  }
  
  void __init kasan_init(void)

  {
phys_addr_t _start, _end;

Re: [PATCH v2 6/6] riscv: dts: Add PCIe support for the SiFive FU740-C000 SoC

[Palmer Dabbelt]

On Wed, 17 Mar 2021 23:08:13 PDT (-0700), greentime...@sifive.com wrote:

Signed-off-by: Greentime Hu 
---
 arch/riscv/boot/dts/sifive/fu740-c000.dtsi | 34 ++
 1 file changed, 34 insertions(+)

diff --git a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi 
b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
index d1bb22b11920..d0839739b425 100644
--- a/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
+++ b/arch/riscv/boot/dts/sifive/fu740-c000.dtsi
@@ -158,6 +158,7 @@ prci: clock-controller@1000 {
reg = <0x0 0x1000 0x0 0x1000>;
clocks = <&hfclk>, <&rtcclk>;
#clock-cells = <1>;
+   #reset-cells = <1>;
};
uart0: serial@1001 {
compatible = "sifive,fu740-c000-uart", "sifive,uart0";
@@ -288,5 +289,38 @@ gpio: gpio@1006 {
clocks = <&prci PRCI_CLK_PCLK>;
status = "disabled";
};
+   pcie@e {
+   #address-cells = <3>;
+   #interrupt-cells = <1>;
+   #num-lanes = <8>;
+   #size-cells = <2>;
+   compatible = "sifive,fu740-pcie";
+   reg = <0xe 0x 0x1 0x0
+  0xd 0xf000 0x0 0x1000
+  0x0 0x100d 0x0 0x1000>;
+   reg-names = "dbi", "config", "mgmt";
+   device_type = "pci";
+   dma-coherent;
+   bus-range = <0x0 0xff>;
+   ranges = <0x8100  0x0 0x6008  0x0 0x6008 
0x0 0x1/* I/O */
+ 0x8200  0x0 0x6009  0x0 0x6009 
0x0 0xff7  /* mem */
+ 0x8200  0x0 0x7000  0x0 0x7000 
0x0 0x100  /* mem */
+ 0xc300 0x20 0x 0x20 0x 0x20 
0x>;  /* mem prefetchable */
+   num-lanes = <0x8>;
+   interrupts = <56 57 58 59 60 61 62 63 64>;
+   interrupt-names = "msi", "inta", "intb", "intc", "intd";
+   interrupt-parent = <&plic0>;
+   interrupt-map-mask = <0x0 0x0 0x0 0x7>;
+   interrupt-map = <0x0 0x0 0x0 0x1 &plic0 57>,
+   <0x0 0x0 0x0 0x2 &plic0 58>,
+   <0x0 0x0 0x0 0x3 &plic0 59>,
+   <0x0 0x0 0x0 0x4 &plic0 60>;
+   clock-names = "pcie_aux";
+       clocks = <&prci PRCI_CLK_PCIE_AUX>;
+   pwren-gpios = <&gpio 5 0>;
+   perstn-gpios = <&gpio 8 0>;
+   resets = <&prci 4>;
+   status = "okay";
+   };
};
 };


Acked-by: Palmer Dabbelt 

I'm happy to take these all through the RISC-V tree if that helps, but 
as usual I'd like reviews or acks from the subsystem maintainers.  It 
looks like there are some issues so I'm going to drop this from my 
inbox.

Re: [PATCH v2 2/6] clk: sifive: Use reset-simple in prci driver for PCIe driver

[Palmer Dabbelt]

On Mon, 29 Mar 2021 20:36:12 PDT (-0700), greentime...@sifive.com wrote:

Stephen Boyd  於 2021年3月30日 週二 上午3:14寫道：


Quoting Greentime Hu (2021-03-17 23:08:09)
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index 71ab75a46491..f094df93d911 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -173,7 +173,7 @@ config RESET_SCMI
>
>  config RESET_SIMPLE
> bool "Simple Reset Controller Driver" if COMPILE_TEST
> -   default ARCH_AGILEX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_REALTEK || 
ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARC
> +   default ARCH_AGILEX || ARCH_ASPEED || ARCH_BITMAIN || ARCH_REALTEK || 
ARCH_STM32 || ARCH_STRATIX10 || ARCH_SUNXI || ARCH_ZX || ARC || RISCV

This conflicts. Can this default be part of the riscv defconfig instead?



Maybe I should remove this since it has been selected by CLK_SIFIVE_PRCI?

 config CLK_SIFIVE_PRCI
bool "PRCI driver for SiFive SoCs"
+   select RESET_CONTROLLER
+   select RESET_SIMPLE


Ya, that's better.  IIRC I suggested something similar in some other 
version, but I might have not actually sent the mail.





> help
>   This enables a simple reset controller driver for reset lines that
>   that can be asserted and deasserted by toggling bits in a 
contiguous,
> @@ -187,6 +187,7 @@ config RESET_SIMPLE
>- RCC reset controller in STM32 MCUs
>- Allwinner SoCs
>- ZTE's zx2967 family
> +  - SiFive FU740 SoCs
>
>  config RESET_STM32MP157
> bool "STM32MP157 Reset Driver" if COMPILE_TEST

Re: [PATCH] Insert SFENCE.VMA in function set_pte_at for RISCV

[Palmer Dabbelt]

On Wed, 17 Mar 2021 19:10:28 PDT (-0700), l...@jiuyang.me wrote:

Thanks for the review!

I see, after skimming related codes, and implementation of other architecture,
I also agree this method is too heavy to implement. And there is a potential
bug, that my patch may introduce two SFENCE.VMA in the related codes:
flush at set_pte_at and also flush in the upper level of the calling stack.

My two cents is that the original description in spec is a little
misleading to the
software side, spec requires each set_pte inserting SFENCE.VMA together,
while the kernel chooses to maintain set_pte and flush_tlb separately.


This is a common source of confusion, the wording in the spec is a bit 
odd.



So I think I should add a patch to fix my bug specifically, and
provide this trunk
as an inline function to flush tlb after modification to a pte.


if (pte_present(pteval)) {
if (pte_leaf(pteval)) {
local_flush_tlb_page(addr);
} else {
if (pte_global(pteval))
local_flush_tlb_all();
else
local_flush_tlb_asid();

   }
}


My next patch will become two patches:
1. add flush_tlb related codes according to spec(also flush global tlb
via sbi call if G bit is on)
2. add a bug fix for my stack by adding flush in the flush_cache_vmap.

Does this approach sound reasonable?


I'm not really sure if I understand what you're saying on either of 
these.


For #1: as far as I know we're correctly flushing the TLB, but if 
there's some issue then I'd be happy to take a look.


For #2: We don't have (and I don't think we need) a flush_cache_vmap(), 
but I do think we need a flush_cache_vunmap().  Essentially we can 
handle the spurious faults to the vmalloc region (there was a bug fix 
recently, maybe you just don't have it yet), but we do need to flush the 
TLB when unmapping.  I'm not sure if that was just an oversight or if 
I'm missing some other way the flush ends up there, as not a lot of 
architectures flush there.



Regards,
Jiuyang

On Tue, 16 Mar 2021 at 09:17 PM Palmer Dabbelt  wrote:

We're trying to avoid this sort of thing, instead relying on the generic kernel
functionality to batch up page table modifications before we issue the fences.
If you're seeing some specific issue then I'd be happy to try and sort out a
fix for it, but this is a bit heavy-handed to use as anything but a last
resort.

On Tue, Mar 16, 2021 at 10:03 PM Andrew Waterman
 wrote:


On Tue, Mar 16, 2021 at 5:05 AM Alex Ghiti  wrote:
>
> Le 3/16/21 à 4:40 AM, Anup Patel a écrit :
> > On Tue, Mar 16, 2021 at 1:59 PM Andrew Waterman
> >  wrote:
> >>
> >> On Tue, Mar 16, 2021 at 12:32 AM Anup Patel  wrote:
> >>>
> >>> On Tue, Mar 16, 2021 at 12:27 PM Jiuyang Liu  wrote:
> >>>>
> >>>>> As per my understanding, we don't need to explicitly invalidate local 
TLB
> >>>>> in set_pte() or set_pet_at() because generic Linux page table management
> >>>>> (/mm/*) will call the appropriate flush_tlb_xyz() function after 
page
> >>>>> table updates.
> >>>>
> >>>> I witnessed this bug in our micro-architecture: set_pte instruction is
> >>>> still in the store buffer, no functions are inserting SFENCE.VMA in
> >>>> the stack below, so TLB cannot witness this modification.
> >>>> Here is my call stack:
> >>>> set_pte
> >>>> set_pte_at
> >>>> map_vm_area
> >>>> __vmalloc_area_node
> >>>> __vmalloc_node_range
> >>>> __vmalloc_node
> >>>> __vmalloc_node_flags
> >>>> vzalloc
> >>>> n_tty_open
> >>>>
>
> I don't find this call stack, what I find is (the other way around):
>
> n_tty_open
> vzalloc
> __vmalloc_node
> __vmalloc_node_range
> __vmalloc_area_node
> map_kernel_range
> -> map_kernel_range_noflush
> flush_cache_vmap
>
> Which leads to the fact that we don't have flush_cache_vmap callback
> implemented: shouldn't we add the sfence.vma here ? Powerpc does
> something similar with "ptesync" (see below) instruction that seems to
> do the same as sfence.vma.

I was thinking the same thing, but I hadn't yet wrapped my head around
the fact that most architectures don't have something similar.  I'm OK
with following PPC's lead if it appears to be a correct bug fix :)

>
>
> ptesync: "The ptesync instruction after the Store instruction ensures
> that all searches of the Page Table that are performed after the ptesync
> instruction completes will use the value stored"
>
> >>>> I t

Re: [PATCH v6] RISC-V: enable XIP

[Palmer Dabbelt]

On Tue, 30 Mar 2021 11:39:10 PDT (-0700), a...@ghiti.fr wrote:



Le 3/30/21 à 2:26 AM, Vitaly Wool a écrit :

On Tue, Mar 30, 2021 at 8:23 AM Palmer Dabbelt  wrote:


On Sun, 21 Mar 2021 17:12:15 PDT (-0700), vitaly.w...@konsulko.com wrote:

Introduce XIP (eXecute In Place) support for RISC-V platforms.
It allows code to be executed directly from non-volatile storage
directly addressable by the CPU, such as QSPI NOR flash which can
be found on many RISC-V platforms. This makes way for significant
optimization of RAM footprint. The XIP kernel is not compressed
since it has to run directly from flash, so it will occupy more
space on the non-volatile storage. The physical flash address used
to link the kernel object files and for storing it has to be known
at compile time and is represented by a Kconfig option.

XIP on RISC-V will for the time being only work on MMU-enabled
kernels.

Signed-off-by: Vitaly Wool 

---

Changes in v2:
- dedicated macro for XIP address fixup when MMU is not enabled yet
   o both for 32-bit and 64-bit RISC-V
- SP is explicitly set to a safe place in RAM before __copy_data call
- removed redundant alignment requirements in vmlinux-xip.lds.S
- changed long -> uintptr_t typecast in __XIP_FIXUP macro.
Changes in v3:
- rebased against latest for-next
- XIP address fixup macro now takes an argument
- SMP related fixes
Changes in v4:
- rebased against the current for-next
- less #ifdef's in C/ASM code
- dedicated XIP_FIXUP_OFFSET assembler macro in head.S
- C-specific definitions moved into #ifndef __ASSEMBLY__
- Fixed multi-core boot
Changes in v5:
- fixed build error for non-XIP kernels
Changes in v6:
- XIP_PHYS_RAM_BASE config option renamed to PHYS_RAM_BASE
- added PHYS_RAM_BASE_FIXED config flag to allow usage of
   PHYS_RAM_BASE in non-XIP configurations if needed
- XIP_FIXUP macro rewritten with a tempoarary variable to avoid side
   effects
- fixed crash for non-XIP kernels that don't use built-in DTB


So v5 landed on for-next, which generally means it's best to avoid
re-spinning the patch and instead send along fixups.  That said, the v5
is causing some testing failures for me.

I'm going to drop the v5 for now as I don't have time to test this
tonight.  I'll try and take a look soon, as it will conflict with Alex's
patches.


I can come up with the incremental patch instead pretty much straight
away if that works better.

~Vitaly


  arch/riscv/Kconfig  |  49 ++-
  arch/riscv/Makefile |   8 +-
  arch/riscv/boot/Makefile|  13 +++
  arch/riscv/include/asm/pgtable.h|  65 --
  arch/riscv/kernel/cpu_ops_sbi.c |  11 ++-
  arch/riscv/kernel/head.S|  49 ++-
  arch/riscv/kernel/head.h|   3 +
  arch/riscv/kernel/setup.c   |   8 +-
  arch/riscv/kernel/vmlinux-xip.lds.S | 132 
  arch/riscv/kernel/vmlinux.lds.S |   6 ++
  arch/riscv/mm/init.c| 100 +++--
  11 files changed, 426 insertions(+), 18 deletions(-)
  create mode 100644 arch/riscv/kernel/vmlinux-xip.lds.S

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8ea60a0a19ae..bd6f82240c34 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -441,7 +441,7 @@ config EFI_STUB

  config EFI
   bool "UEFI runtime support"
- depends on OF
+ depends on OF && !XIP_KERNEL
   select LIBFDT
   select UCS2_STRING
   select EFI_PARAMS_FROM_FDT
@@ -465,11 +465,56 @@ config STACKPROTECTOR_PER_TASK
   def_bool y
   depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS

+config PHYS_RAM_BASE_FIXED
+ bool "Explicitly specified physical RAM address"
+ default n
+
+config PHYS_RAM_BASE
+ hex "Platform Physical RAM address"
+ depends on PHYS_RAM_BASE_FIXED
+ default "0x8000"
+ help
+   This is the physical address of RAM in the system. It has to be
+   explicitly specified to run early relocations of read-write data
+   from flash to RAM.
+
+config XIP_KERNEL
+ bool "Kernel Execute-In-Place from ROM"
+ depends on MMU
+ select PHYS_RAM_BASE_FIXED
+ help
+   Execute-In-Place allows the kernel to run from non-volatile storage
+   directly addressable by the CPU, such as NOR flash. This saves RAM
+   space since the text section of the kernel is not loaded from flash
+   to RAM.  Read-write sections, such as the data section and stack,
+   are still copied to RAM.  The XIP kernel is not compressed since
+   it has to run directly from flash, so it will take more space to
+   store it.  The flash address used to link the kernel object files,
+   and for storing it, is configuration dependent. Therefore, if you
+   say Y here, you must know the proper physical address where to
+   store the kernel image depending on your own flash memory usag

Re: [PATCH v6] RISC-V: enable XIP

[Palmer Dabbelt]

On Sun, 21 Mar 2021 17:12:15 PDT (-0700), vitaly.w...@konsulko.com wrote:

Introduce XIP (eXecute In Place) support for RISC-V platforms.
It allows code to be executed directly from non-volatile storage
directly addressable by the CPU, such as QSPI NOR flash which can
be found on many RISC-V platforms. This makes way for significant
optimization of RAM footprint. The XIP kernel is not compressed
since it has to run directly from flash, so it will occupy more
space on the non-volatile storage. The physical flash address used
to link the kernel object files and for storing it has to be known
at compile time and is represented by a Kconfig option.

XIP on RISC-V will for the time being only work on MMU-enabled
kernels.

Signed-off-by: Vitaly Wool 

---

Changes in v2:
- dedicated macro for XIP address fixup when MMU is not enabled yet
  o both for 32-bit and 64-bit RISC-V
- SP is explicitly set to a safe place in RAM before __copy_data call
- removed redundant alignment requirements in vmlinux-xip.lds.S
- changed long -> uintptr_t typecast in __XIP_FIXUP macro.
Changes in v3:
- rebased against latest for-next
- XIP address fixup macro now takes an argument
- SMP related fixes
Changes in v4:
- rebased against the current for-next
- less #ifdef's in C/ASM code
- dedicated XIP_FIXUP_OFFSET assembler macro in head.S
- C-specific definitions moved into #ifndef __ASSEMBLY__
- Fixed multi-core boot
Changes in v5:
- fixed build error for non-XIP kernels
Changes in v6:
- XIP_PHYS_RAM_BASE config option renamed to PHYS_RAM_BASE
- added PHYS_RAM_BASE_FIXED config flag to allow usage of
  PHYS_RAM_BASE in non-XIP configurations if needed
- XIP_FIXUP macro rewritten with a tempoarary variable to avoid side
  effects
- fixed crash for non-XIP kernels that don't use built-in DTB


So v5 landed on for-next, which generally means it's best to avoid 
re-spinning the patch and instead send along fixups.  That said, the v5 
is causing some testing failures for me.


I'm going to drop the v5 for now as I don't have time to test this 
tonight.  I'll try and take a look soon, as it will conflict with Alex's 
patches.



 arch/riscv/Kconfig  |  49 ++-
 arch/riscv/Makefile |   8 +-
 arch/riscv/boot/Makefile|  13 +++
 arch/riscv/include/asm/pgtable.h|  65 --
 arch/riscv/kernel/cpu_ops_sbi.c |  11 ++-
 arch/riscv/kernel/head.S|  49 ++-
 arch/riscv/kernel/head.h|   3 +
 arch/riscv/kernel/setup.c   |   8 +-
 arch/riscv/kernel/vmlinux-xip.lds.S | 132 
 arch/riscv/kernel/vmlinux.lds.S |   6 ++
 arch/riscv/mm/init.c| 100 +++--
 11 files changed, 426 insertions(+), 18 deletions(-)
 create mode 100644 arch/riscv/kernel/vmlinux-xip.lds.S

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8ea60a0a19ae..bd6f82240c34 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -441,7 +441,7 @@ config EFI_STUB

 config EFI
bool "UEFI runtime support"
-   depends on OF
+   depends on OF && !XIP_KERNEL
select LIBFDT
select UCS2_STRING
select EFI_PARAMS_FROM_FDT
@@ -465,11 +465,56 @@ config STACKPROTECTOR_PER_TASK
def_bool y
depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS

+config PHYS_RAM_BASE_FIXED
+   bool "Explicitly specified physical RAM address"
+   default n
+
+config PHYS_RAM_BASE
+   hex "Platform Physical RAM address"
+   depends on PHYS_RAM_BASE_FIXED
+   default "0x8000"
+   help
+ This is the physical address of RAM in the system. It has to be
+ explicitly specified to run early relocations of read-write data
+ from flash to RAM.
+
+config XIP_KERNEL
+   bool "Kernel Execute-In-Place from ROM"
+   depends on MMU
+   select PHYS_RAM_BASE_FIXED
+   help
+ Execute-In-Place allows the kernel to run from non-volatile storage
+ directly addressable by the CPU, such as NOR flash. This saves RAM
+ space since the text section of the kernel is not loaded from flash
+ to RAM.  Read-write sections, such as the data section and stack,
+ are still copied to RAM.  The XIP kernel is not compressed since
+ it has to run directly from flash, so it will take more space to
+ store it.  The flash address used to link the kernel object files,
+ and for storing it, is configuration dependent. Therefore, if you
+ say Y here, you must know the proper physical address where to
+ store the kernel image depending on your own flash memory usage.
+
+ Also note that the make target becomes "make xipImage" rather than
+ "make zImage" or "make Image".  The final kernel binary to put in
+ ROM memory will be arch/riscv/boot/xipImage.
+
+ If unsure, say N.
+
+config XIP_PHYS_ADDR
+   hex "XIP Kernel Physical Location"
+   depends on XIP_KERNE

Re: [PATCH] riscv: remove unneeded semicolon

[Palmer Dabbelt]

On Mon, 22 Mar 2021 01:38:36 PDT (-0700), yang@linux.alibaba.com wrote:

Eliminate the following coccicheck warning:
./arch/riscv/mm/kasan_init.c:219:2-3: Unneeded semicolon

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 arch/riscv/mm/kasan_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 4f85c6d..937d13c 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -216,7 +216,7 @@ void __init kasan_init(void)
break;

kasan_populate(kasan_mem_to_shadow(start), 
kasan_mem_to_shadow(end));
-   };
+   }

for (i = 0; i < PTRS_PER_PTE; i++)
set_pte(&kasan_early_shadow_pte[i],


Thanks, this is on fixes.

Re: [PATCH] ftrace: Fix spelling mistake "disabed" -> "disabled"

[Palmer Dabbelt]

On Wed, 17 Mar 2021 06:42:23 PDT (-0700), rost...@goodmis.org wrote:

On Tue, 16 Mar 2021 21:21:08 -0700 (PDT)
Palmer Dabbelt  wrote:


Thanks, this is on fixes.


What does this mean? Is there a tree that spelling fixes go through now?

I had already pulled this patch into my queue for the next merge window
(and it's still in the testing phase with other patches before going to
linux-next).

Should I drop it?


Oh, sorry.  It's on the fixes branch of the riscv tree 
<https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git> .  
It's what I sent up to Linus every week, this one already went up.


I must have not been looking closely enough, for some reason I thought 
this only touched the riscv tree.  I wouldn't have taken it without an 
Ack if I'd noticed, I guess just because it was only a comment spelling 
change I hadn't checked the paths.  I'll try not to do that again.

Re: [PATCH] riscv,entry: fix misaligned base for excp_vect_table

[Palmer Dabbelt]

On Wed, 17 Mar 2021 01:17:25 PDT (-0700), yuzi...@ict.ac.cn wrote:

* In RV64, the size of each entry in excp_vect_table is 8 bytes. If the
  base of the table is not 8-byte aligned, loading an entry in the table
  will raise a misaligned exception. Although such exception will be
  handled by opensbi/bbl, this still causes performance degradation.

Signed-off-by: Zihao Yu 
---
 arch/riscv/kernel/entry.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/kernel/entry.S b/arch/riscv/kernel/entry.S
index 744f3209c..76274a4a1 100644
--- a/arch/riscv/kernel/entry.S
+++ b/arch/riscv/kernel/entry.S
@@ -447,6 +447,7 @@ ENDPROC(__switch_to)
 #endif

.section ".rodata"
+   .align LGREG
/* Exception vector table */
 ENTRY(excp_vect_table)
RISCV_PTR do_trap_insn_misaligned


Thanks, this is on fixes.

Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024

[Palmer Dabbelt]

On Tue, 16 Mar 2021 12:34:20 PDT (-0700), a...@ghiti.fr wrote:

Increase COMMAND_LINE_SIZE as the current default value is too low
for syzbot kernel command line.

Reported-by: Dmitry Vyukov 
Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/include/uapi/asm/setup.h | 8 
 1 file changed, 8 insertions(+)
 create mode 100644 arch/riscv/include/uapi/asm/setup.h

diff --git a/arch/riscv/include/uapi/asm/setup.h 
b/arch/riscv/include/uapi/asm/setup.h
new file mode 100644
index ..66b13a522880
--- /dev/null
+++ b/arch/riscv/include/uapi/asm/setup.h
@@ -0,0 +1,8 @@
+/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
+
+#ifndef _UAPI_ASM_RISCV_SETUP_H
+#define _UAPI_ASM_RISCV_SETUP_H
+
+#define COMMAND_LINE_SIZE  1024
+
+#endif /* _UAPI_ASM_RISCV_SETUP_H */


I put this on fixes, but it seemes like this should really be a Kconfig 
enttry.  Either way, ours was quite a bit smaller than most 
architectures and it's great that syzbot has started to find bugs, so 
I'd rather get this in sooner.

Re: [PATCH v3 2/2] riscv: Cleanup KASAN_VMALLOC support

[Palmer Dabbelt]

On Sat, 13 Mar 2021 00:45:05 PST (-0800), a...@ghiti.fr wrote:

When KASAN vmalloc region is populated, there is no userspace process and
the page table in use is swapper_pg_dir, so there is no need to read
SATP. Then we can use the same scheme used by kasan_populate_p*d
functions to go through the page table, which harmonizes the code.

In addition, make use of set_pgd that goes through all unused page table
levels, contrary to p*d_populate functions, which makes this function work
whatever the number of page table levels.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Palmer Dabbelt 
---
 arch/riscv/mm/kasan_init.c | 59 --
 1 file changed, 18 insertions(+), 41 deletions(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 57bf4ae09361..c16178918239 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -11,18 +11,6 @@
 #include 
 #include 

-static __init void *early_alloc(size_t size, int node)
-{
-   void *ptr = memblock_alloc_try_nid(size, size,
-   __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, node);
-
-   if (!ptr)
-   panic("%pS: Failed to allocate %zu bytes align=%zx nid=%d 
from=%llx\n",
-   __func__, size, size, node, (u64)__pa(MAX_DMA_ADDRESS));
-
-   return ptr;
-}
-
 extern pgd_t early_pg_dir[PTRS_PER_PGD];
 asmlinkage void __init kasan_early_init(void)
 {
@@ -155,38 +143,27 @@ static void __init kasan_populate(void *start, void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
 }

-void __init kasan_shallow_populate(void *start, void *end)
+static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned 
long end)
 {
-   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
-   unsigned long vend = PAGE_ALIGN((unsigned long)end);
-   unsigned long pfn;
-   int index;
+   unsigned long next;
void *p;
-   pud_t *pud_dir, *pud_k;
-   pgd_t *pgd_dir, *pgd_k;
-   p4d_t *p4d_dir, *p4d_k;
-
-   while (vaddr < vend) {
-   index = pgd_index(vaddr);
-   pfn = csr_read(CSR_SATP) & SATP_PPN;
-   pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
-   pgd_k = init_mm.pgd + index;
-   pgd_dir = pgd_offset_k(vaddr);
-   set_pgd(pgd_dir, *pgd_k);
-
-   p4d_dir = p4d_offset(pgd_dir, vaddr);
-   p4d_k  = p4d_offset(pgd_k, vaddr);
-
-   vaddr = (vaddr + PUD_SIZE) & PUD_MASK;
-   pud_dir = pud_offset(p4d_dir, vaddr);
-   pud_k = pud_offset(p4d_k, vaddr);
-
-   if (pud_present(*pud_dir)) {
-   p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
-   pud_populate(&init_mm, pud_dir, p);
+   pgd_t *pgd_k = pgd_offset_k(vaddr);
+
+   do {
+   next = pgd_addr_end(vaddr, end);
+   if (pgd_page_vaddr(*pgd_k) == (unsigned 
long)lm_alias(kasan_early_shadow_pmd)) {
+   p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+   set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
}
-   vaddr += PAGE_SIZE;
-   }
+   } while (pgd_k++, vaddr = next, vaddr != end);
+}
+
+static void __init kasan_shallow_populate(void *start, void *end)
+{
+   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
+   unsigned long vend = PAGE_ALIGN((unsigned long)end);
+
+   kasan_shallow_populate_pgd(vaddr, vend);

local_flush_tlb_all();
 }


Thanks, this is on for-next.

Re: [PATCH] kbuild: buildtar: add riscv support

[Palmer Dabbelt]

On Tue, 16 Mar 2021 09:02:43 PDT (-0700), m...@carlosedp.com wrote:

Make 'make tar-pkg' and 'tarbz2-pkg' work on riscv.

Signed-off-by: Carlos de Paula 
---
 scripts/package/buildtar | 8 
 1 file changed, 8 insertions(+)

diff --git a/scripts/package/buildtar b/scripts/package/buildtar
index 936198a90477..221aa7df008d 100755
--- a/scripts/package/buildtar
+++ b/scripts/package/buildtar
@@ -123,10 +123,18 @@ case "${ARCH}" in
cp -v -- "${objtree}/arch/arm64/boot/${i}" 
"${tmpdir}/boot/vmlinuz-${KERNELRELEASE}"
break
fi
done
;;
+   riscv)
+   for i in Image.bz2 Image.gz Image; do
+   if [ -f "${objtree}/arch/riscv/boot/${i}" ] ; then
+   cp -v -- "${objtree}/arch/riscv/boot/${i}" 
"${tmpdir}/boot/vmlinux-${KERNELRELEASE}"
+   break
+   fi
+   done
+   ;;
*)
[ -f "${KBUILD_IMAGE}" ] && cp -v -- "${KBUILD_IMAGE}" 
"${tmpdir}/boot/vmlinux-kbuild-${KERNELRELEASE}"
echo "" >&2
echo '** ** **  WARNING  ** ** **' >&2
echo "" >&2


Thanks, this is on for-next.

Re: [PATCH v4 0/5] Add Microchip PolarFire Soc Support

[Palmer Dabbelt]

On Wed, 03 Mar 2021 12:02:48 PST (-0800), Atish Patra wrote:

This series adds minimal support for Microchip Polar Fire Soc Icicle kit.
It is rebased on v5.12-rc1 and depends on clock support.
Only MMC and ethernet drivers are enabled via this series.
The idea here is to add the foundational patches so that other drivers
can be added to on top of this. The device tree may change based on
feedback on bindings of individual driver support patches.

This series has been tested on Qemu and Polar Fire Soc Icicle kit.
It depends on the updated clock-series[2] and macb fix[3].
The series is also tested by Lewis from Microchip.

The series can also be found at.
https://github.com/atishp04/linux/tree/polarfire_support_upstream_v4

[1] https://lists.nongnu.org/archive/html/qemu-devel/2020-10/msg08582.html
[2] https://www.spinics.net/lists/linux-clk/msg54579.html

Changes from v3->v4:
1. Fixed few DT specific issues.
2. Rebased on top of new clock driver.
3. SD card functionality is verified.

Changes from v2->v3:
1. Fixed a typo in dt binding.
2. Included MAINTAINERS entry for PolarFire SoC.
3. Improved the dts file by using lowercase clock names and keeping phy
   details in board specific dts file.

Changes from v1->v2:
1. Modified the DT to match the device tree in U-Boot.
2. Added both eMMC & SDcard entries in DT. However, SD card is only enabled
   as it allows larger storage option for linux distros.

Atish Patra (4):
RISC-V: Add Microchip PolarFire SoC kconfig option
dt-bindings: riscv: microchip: Add YAML documentation for the
PolarFire SoC
RISC-V: Initial DTS for Microchip ICICLE board
RISC-V: Enable Microchip PolarFire ICICLE SoC

Conor Dooley (1):
MAINTAINERS: add microchip polarfire soc support

.../devicetree/bindings/riscv/microchip.yaml  |  27 ++
MAINTAINERS   |   8 +
arch/riscv/Kconfig.socs   |   7 +
arch/riscv/boot/dts/Makefile  |   1 +
arch/riscv/boot/dts/microchip/Makefile|   2 +
.../microchip/microchip-mpfs-icicle-kit.dts   |  72 
.../boot/dts/microchip/microchip-mpfs.dtsi| 329 ++
arch/riscv/configs/defconfig  |   4 +
8 files changed, 450 insertions(+)
create mode 100644 Documentation/devicetree/bindings/riscv/microchip.yaml
create mode 100644 arch/riscv/boot/dts/microchip/Makefile
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs-icicle-kit.dts
create mode 100644 arch/riscv/boot/dts/microchip/microchip-mpfs.dtsi


I had this left in my inbox waiting for either some reviews to come in or a v2,
but I don't see any.  Did I miss something?

[GIT PULL] RISC-V Fixes for 5.12-rc4

[Palmer Dabbelt]

The following changes since commit a38fd8748464831584a19438cbb3082b5a2dab15:

  Linux 5.12-rc2 (2021-03-05 17:33:41 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.12-rc4

for you to fetch changes up to a5406a7ff56e63376c210b06072aa0ef23473366:

  riscv: Correct SPARSEMEM configuration (2021-03-16 22:15:21 -0700)


RISC-V Fixes for 5.12-rc4

I have handful of fixes for 5.12:

* A fix to the SBI remote fence numbers for hypervisor fences, which had
  been transcribed in the wrong order in Linux.  These fences are only
  used with the KVM patches applied.
* A whole host of build warnings have been fixed, these should have no
  functional change.
* A fix to init_resources() that prevents an off-by-one error from
  causing an out-of-bounds array reference.  This is manifesting during
  boot on vexriscv.
* A fix to ensure the KASAN mappings are visible before proceeding to
  use them.


Alexandre Ghiti (1):
  riscv: Ensure page table writes are flushed when initializing KASAN 
vmalloc

Colin Ian King (1):
  ftrace: Fix spelling mistake "disabed" -> "disabled"

Damien Le Moal (1):
  riscv: Fix compilation error with Canaan SoC

Geert Uytterhoeven (1):
  RISC-V: Fix out-of-bounds accesses in init_resources()

Heinrich Schuchardt (1):
  RISC-V: correct enum sbi_ext_rfence_fid

Kefeng Wang (1):
  riscv: Correct SPARSEMEM configuration

Nanyong Sun (9):
  riscv: traps: Fix no prototype warnings
  riscv: irq: Fix no prototype warning
  riscv: sbi: Fix comment of __sbi_set_timer_v01
  riscv: ptrace: Fix no prototype warnings
  riscv: time: Fix no prototype for time_init
  riscv: syscall_table: Reduce W=1 compilation warnings noise
  riscv: process: Fix no prototype for show_regs
  riscv: ftrace: Use ftrace_get_regs helper
  riscv: process: Fix no prototype for arch_dup_task_struct

Palmer Dabbelt (1):
  RISC-V: kasan: Declare kasan_shallow_populate() static

kernel test robot (1):
  riscv: fix bugon.cocci warnings

 arch/csky/kernel/probes/ftrace.c|  2 +-
 arch/riscv/Kconfig  |  4 ++--
 arch/riscv/Kconfig.socs |  2 ++
 arch/riscv/include/asm/asm-prototypes.h | 16 
 arch/riscv/include/asm/irq.h|  2 ++
 arch/riscv/include/asm/processor.h  |  1 +
 arch/riscv/include/asm/ptrace.h |  5 +
 arch/riscv/include/asm/sbi.h|  4 ++--
 arch/riscv/include/asm/timex.h  |  2 ++
 arch/riscv/kernel/Makefile  |  1 +
 arch/riscv/kernel/probes/ftrace.c   | 18 ++
 arch/riscv/kernel/probes/kprobes.c  |  3 +--
 arch/riscv/kernel/process.c |  1 +
 arch/riscv/kernel/sbi.c |  2 +-
 arch/riscv/kernel/setup.c   |  3 ++-
 arch/riscv/kernel/time.c|  1 +
 arch/riscv/kernel/traps.c   |  1 +
 arch/riscv/mm/kasan_init.c  |  4 +++-
 arch/x86/kernel/kprobes/ftrace.c|  2 +-
 19 files changed, 55 insertions(+), 19 deletions(-)

Re: [PATCH] riscv: Fix spelling mistake "initialisation" -> "initialization

[Palmer Dabbelt]

On Tue, 16 Mar 2021 02:30:54 PDT (-0700), musamaan...@gmail.com wrote:

There is a spelling mistake in a comment. Fix it.

Signed-off-by: Muhammad Usama Anjum 
---
 arch/riscv/kernel/smp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index ea028d9e0d24..1ec014067855 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0-only
 /*
- * SMP initialisation and IPI support
+ * SMP initialization and IPI support
  * Based on arch/arm64/kernel/smp.c
  *
  * Copyright (C) 2012 ARM Ltd.


The internet seems to suggest that both of these are words and that they mean
the same thing.

Re: [PATCH v6 1/2] RISC-V: Don't print SBI version for all detected extensions

[Palmer Dabbelt]

On Mon, 15 Mar 2021 04:04:59 PDT (-0700), Anup Patel wrote:

The sbi_init() already prints SBI version before detecting
various SBI extensions so we don't need to print SBI version
for all detected SBI extensions.

Signed-off-by: Anup Patel 
---
 arch/riscv/kernel/sbi.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index f4a7db3d309e..c0dcebdd30ec 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -577,19 +577,19 @@ void __init sbi_init(void)
sbi_get_firmware_id(), sbi_get_firmware_version());
if (sbi_probe_extension(SBI_EXT_TIME) > 0) {
__sbi_set_timer = __sbi_set_timer_v02;
-   pr_info("SBI v0.2 TIME extension detected\n");
+   pr_info("SBI TIME extension detected\n");
} else {
__sbi_set_timer = __sbi_set_timer_v01;
}
if (sbi_probe_extension(SBI_EXT_IPI) > 0) {
__sbi_send_ipi  = __sbi_send_ipi_v02;
-   pr_info("SBI v0.2 IPI extension detected\n");
+   pr_info("SBI IPI extension detected\n");
} else {
__sbi_send_ipi  = __sbi_send_ipi_v01;
}
if (sbi_probe_extension(SBI_EXT_RFENCE) > 0) {
__sbi_rfence= __sbi_rfence_v02;
-   pr_info("SBI v0.2 RFENCE extension detected\n");
+   pr_info("SBI RFENCE extension detected\n");
} else {
__sbi_rfence= __sbi_rfence_v01;
}


Thanks.  I'm just putting this one on for-next so you don't have to carry
around the diff.

[PATCH] RISC-V: kasan: Declare kasan_shallow_populate() static

[Palmer Dabbelt]

From: Palmer Dabbelt 

Without this I get a missing prototype warning.

Reported-by: kernel test robot 
Fixes: e178d670f251 ("riscv/kasan: add KASAN_VMALLOC support")
Cc: sta...@vger.kernel.org
Signed-off-by: Palmer Dabbelt 
---
 arch/riscv/mm/kasan_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 5c35e0f71e88..4f85c6d0ddf8 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -155,7 +155,7 @@ static void __init kasan_populate(void *start, void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
 }
 
-void __init kasan_shallow_populate(void *start, void *end)
+static void __init kasan_shallow_populate(void *start, void *end)
 {
unsigned long vaddr = (unsigned long)start & PAGE_MASK;
unsigned long vend = PAGE_ALIGN((unsigned long)end);
-- 
2.31.0.rc2.261.g7f71774620-goog

Re: [PATCH 0/3] Move kernel mapping outside the linear mapping

[Palmer Dabbelt]

On Sat, 13 Mar 2021 01:26:47 PST (-0800), a...@ghiti.fr wrote:

Hi Palmer,

Le 3/9/21 à 9:54 PM, Palmer Dabbelt a écrit :

On Thu, 25 Feb 2021 00:04:50 PST (-0800), a...@ghiti.fr wrote:

I decided to split sv48 support in small series to ease the review.

This patchset pushes the kernel mapping (modules and BPF too) to the last
4GB of the 64bit address space, this allows to:
- implement relocatable kernel (that will come later in another
  patchset) that requires to move the kernel mapping out of the linear
  mapping to avoid to copy the kernel at a different physical address.
- have a single kernel that is not relocatable (and then that avoids the
  performance penalty imposed by PIC kernel) for both sv39 and sv48.

The first patch implements this behaviour, the second patch introduces a
documentation that describes the virtual address space layout of the
64bit
kernel and the last patch is taken from my sv48 series where I simply
added
the dump of the modules/kernel/BPF mapping.

I removed the Reviewed-by on the first patch since it changed enough from
last time and deserves a second look.

Alexandre Ghiti (3):
  riscv: Move kernel mapping outside of linear mapping
  Documentation: riscv: Add documentation that describes the VM layout
  riscv: Prepare ptdump for vm layout dynamic addresses

 Documentation/riscv/index.rst   |  1 +
 Documentation/riscv/vm-layout.rst   | 61 ++
 arch/riscv/boot/loader.lds.S    |  3 +-
 arch/riscv/include/asm/page.h   | 18 ++-
 arch/riscv/include/asm/pgtable.h    | 37 +
 arch/riscv/include/asm/set_memory.h |  1 +
 arch/riscv/kernel/head.S    |  3 +-
 arch/riscv/kernel/module.c  |  6 +--
 arch/riscv/kernel/setup.c   |  3 ++
 arch/riscv/kernel/vmlinux.lds.S |  3 +-
 arch/riscv/mm/fault.c   | 13 +
 arch/riscv/mm/init.c    | 81 +++--
 arch/riscv/mm/kasan_init.c  |  9 
 arch/riscv/mm/physaddr.c    |  2 +-
 arch/riscv/mm/ptdump.c  | 67 +++-
 15 files changed, 258 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/riscv/vm-layout.rst


This generally looks good, but I'm getting a bunch of checkpatch
warnings and some conflicts, do you mind fixing those up (and including
your other kasan patch, as that's likely to conflict)?



I fixed a few checkpatch warnings and rebased on top of for-next but had
not conflicts.

I have just sent the v2.


Thanks.  These (and the second patch of the one I just put on fixes) are
for-next things, so I'm not going to get a look at them tonight because I want
to make sure we don't have any more fixes outstanding.

Re: [PATCH v3 1/2] riscv: Ensure page table writes are flushed when initializing KASAN vmalloc

[Palmer Dabbelt]

On Sat, 13 Mar 2021 00:45:04 PST (-0800), a...@ghiti.fr wrote:

Make sure that writes to kernel page table during KASAN vmalloc
initialization are made visible by adding a sfence.vma.

Signed-off-by: Alexandre Ghiti 
Reviewed-by: Palmer Dabbelt 
---
 arch/riscv/mm/kasan_init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 1b968855d389..57bf4ae09361 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -187,6 +187,8 @@ void __init kasan_shallow_populate(void *start, void *end)
}
vaddr += PAGE_SIZE;
}
+
+   local_flush_tlb_all();
 }

 void __init kasan_init(void)


Thanks, this is on fixes.

Re: [PATCH] RISC-V: Fix out-of-bounds accesses in init_resources()

[Palmer Dabbelt]

On Fri, 12 Mar 2021 07:46:34 PST (-0800), ge...@linux-m68k.org wrote:

init_resources() allocates an array of resources, based on the current
total number of memory regions and reserved memory regions.  However,
allocating this array using memblock_alloc() might increase the number
of reserved memory regions.  If that happens, populating the array later
based on the new number of regions will cause out-of-bounds writes
beyond the end of the allocated array.

Fix this by allocating one more entry, which may or may not be used.

Fixes: 797f0375dd2ef5cd ("RISC-V: Do not allocate memblock while iterating reserved 
memblocks")
Signed-off-by: Geert Uytterhoeven 
---
Tested on vexriscv, which works now using L1_CACHE_SHIFT = 6, too.

This issue may show up during early boot as:

Unable to handle kernel paging request at virtual address c808
Oops [#1]
CPU: 0 PID: 0 Comm: swapper Not tainted 
5.11.0-orangecrab-00023-g7c4fc8e3e982-dirty #137
epc: c04d6660 ra : c04d6560 sp : c05ddf70
 gp : c0678bc0 tp : c05e5b40 t0 : c800
 t1 : 0003 t2 :  s0 : c05ddfc0
 s1 : c800 a0 :  a1 : c7e0
 a2 : 0005 a3 : 0001 a4 : 000c
 a5 :  a6 : c04fe000 a7 : 000c
 s2 : c04fe098 s3 : 00a0 s4 : c760
 s5 : c04fe0dc s6 : 8200 s7 : c059f1d4
 s8 : 81000200 s9 : c059f1f0 s10: 8200
 s11: c059f1d4 t3 : 405dbb60 t4 : c05e6f08
 t5 : 81000200 t6 : 40501000
status: 0100 badaddr: c808 cause: 000f
random: get_random_bytes called from print_oops_end_marker+0x38/0x7c with 
crng_init=0
---[ end trace  ]---

or much later as:

Unable to handle kernel paging request at virtual address 69726573
---
 arch/riscv/kernel/setup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index e85bacff1b5075ee..f8f15332caa20263 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -147,7 +147,8 @@ static void __init init_resources(void)
bss_res.end = __pa_symbol(__bss_stop) - 1;
bss_res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;

-   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt) * 
sizeof(*mem_res);
+   /* + 1 as memblock_alloc() might increase memblock.reserved.cnt */
+   mem_res_sz = (memblock.memory.cnt + memblock.reserved.cnt + 1) * 
sizeof(*mem_res);
mem_res = memblock_alloc(mem_res_sz, SMP_CACHE_BYTES);
if (!mem_res)
panic("%s: Failed to allocate %zu bytes\n", __func__, 
mem_res_sz);


Thanks, this is on fixes.

Re: [RFC PATCH v1 0/3] IPI and remote TBL flush improvement

[Palmer Dabbelt]

On Thu, 11 Mar 2021 08:47:09 PST (-0800), Anup Patel wrote:

This series primarily does two things:
1. Allows RISC-V IPI provider to specificy whether IPI operations are
   suitable for remote TLB flush (PATCH1)
2. Improve remote TLB flush to use IPIs whenever possible (PATCH2)
3. Allow irqchip drivers to handle IPIs from chained IRQ handlers (PATCH3)


IIUC this last one isn't technically used in both forms, as we don't have any
drivers that behave that way yet?  I'm OK taking it, under the assumption it
makes keeping the out-of-tree driver for the draft interrupt controller easier,
but I was wrong then it's probably out of order so I figured I'd check.

Aside from that this generally LGTM.  We are making quite a bit of mess in
here, but I don't really see a way around that as we need to support the old
hardware.  We can always do a cleanup when the specifications settle down.

Oddly enough this did come up in IRC recently and there may be some new bits in
the CLINT on the FU740 that allow S-mode SW interrupts to show up directly --
there's at least a "delegate supervisor software interrupt" bit now, but the
manual only calls out machine mode as being able to set it (though IIUC it's
memory mapped, so not sure how that would be enforced).  Not saying we need
that in order to take the last patch, but if it is possible it's probably worth
giving it a shot when the boards show up.


This series also a preparatory series for upcoming RISC-V advanced
interrupt architecture (AIA) support.

These patches can be found in riscv_ipi_imp_v1 branch at
https://github.com/avpatel/linux

Anup Patel (3):
  RISC-V: IPI provider should specify if we can use IPI for remote FENCE
  RISC-V: Use IPIs for remote TLB flush when possible
  RISC-V: Add handle_IPI_noregs() for irqchip drivers

 arch/riscv/include/asm/smp.h  | 19 +-
 arch/riscv/kernel/sbi.c   |  2 +-
 arch/riscv/kernel/smp.c   | 30 +++
 arch/riscv/mm/cacheflush.c|  2 +-
 arch/riscv/mm/tlbflush.c  | 62 ---
 drivers/clocksource/timer-clint.c |  2 +-
 6 files changed, 91 insertions(+), 26 deletions(-)

Re: [PATCH] ftrace: Fix spelling mistake "disabed" -> "disabled"

[Palmer Dabbelt]

On Thu, 11 Mar 2021 01:40:22 PST (-0800), colin.k...@canonical.com wrote:

From: Colin Ian King 

There is a spelling mistake in a comment, fix it.

Signed-off-by: Colin Ian King 
---
 arch/csky/kernel/probes/ftrace.c  | 2 +-
 arch/riscv/kernel/probes/ftrace.c | 2 +-
 arch/x86/kernel/kprobes/ftrace.c  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/csky/kernel/probes/ftrace.c b/arch/csky/kernel/probes/ftrace.c
index ae2b1c7b3b5c..ef2bb9bd9605 100644
--- a/arch/csky/kernel/probes/ftrace.c
+++ b/arch/csky/kernel/probes/ftrace.c
@@ -9,7 +9,7 @@ int arch_check_ftrace_location(struct kprobe *p)
return 0;
 }

-/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+/* Ftrace callback handler for kprobes -- called under preepmt disabled */
 void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
   struct ftrace_ops *ops, struct ftrace_regs *fregs)
 {
diff --git a/arch/riscv/kernel/probes/ftrace.c 
b/arch/riscv/kernel/probes/ftrace.c
index 2dfb33fdac74..17ca5e923bb0 100644
--- a/arch/riscv/kernel/probes/ftrace.c
+++ b/arch/riscv/kernel/probes/ftrace.c
@@ -2,7 +2,7 @@

 #include 

-/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+/* Ftrace callback handler for kprobes -- called under preepmt disabled */
 void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
   struct ftrace_ops *ops, struct ftrace_regs *fregs)
 {
diff --git a/arch/x86/kernel/kprobes/ftrace.c b/arch/x86/kernel/kprobes/ftrace.c
index 373e5fa3ce1f..51c7f5271aee 100644
--- a/arch/x86/kernel/kprobes/ftrace.c
+++ b/arch/x86/kernel/kprobes/ftrace.c
@@ -12,7 +12,7 @@

 #include "common.h"

-/* Ftrace callback handler for kprobes -- called under preepmt disabed */
+/* Ftrace callback handler for kprobes -- called under preepmt disabled */
 void kprobe_ftrace_handler(unsigned long ip, unsigned long parent_ip,
   struct ftrace_ops *ops, struct ftrace_regs *fregs)
 {


Thanks, this is on fixes.

Re: [PATCH] Insert SFENCE.VMA in function set_pte_at for RISCV

[Palmer Dabbelt]

On Tue, 09 Mar 2021 22:22:46 PST (-0800), l...@jiuyang.me wrote:

From: Jiuyang Liu 

This patch inserts SFENCE.VMA after modifying PTE based on RISC-V
specification.

arch/riscv/include/asm/pgtable.h:
1. implement pte_user, pte_global and pte_leaf to check correspond
attribute of a pte_t.

2. insert SFENCE.VMA in set_pte_at based on RISC-V Volume 2, Privileged
Spec v. 20190608 page 66 and 67:
If software modifies a non-leaf PTE, it should execute SFENCE.VMA with
rs1=x0. If any PTE along the traversal path had its G bit set, rs2 must
be x0; otherwise, rs2 should be set to the ASID for which the
translation is being modified.
If software modifies a leaf PTE, it should execute SFENCE.VMA with rs1
set to a virtual address within the page. If any PTE along the traversal
path had its G bit set, rs2 must be x0; otherwise, rs2 should be set to
the ASID for which the translation is being modified.

arch/riscv/include/asm/tlbflush.h:
1. implement local_flush_tlb_asid to flush tlb with asid.

Signed-off-by: Jiuyang Liu 
---
 arch/riscv/include/asm/pgtable.h  | 28 
 arch/riscv/include/asm/tlbflush.h |  8 
 2 files changed, 36 insertions(+)

diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index ebf817c1bdf4..95f6546ddb5b 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -222,6 +222,16 @@ static inline int pte_write(pte_t pte)
return pte_val(pte) & _PAGE_WRITE;
 }

+static inline int pte_user(pte_t pte)
+{
+   return pte_val(pte) & _PAGE_USER;
+}
+
+static inline int pte_global(pte_t pte)
+{
+   return pte_val(pte) & _PAGE_GLOBAL;
+}
+
 static inline int pte_exec(pte_t pte)
 {
return pte_val(pte) & _PAGE_EXEC;
@@ -248,6 +258,11 @@ static inline int pte_special(pte_t pte)
return pte_val(pte) & _PAGE_SPECIAL;
 }

+static inline int pte_leaf(pte_t pte)
+{
+   return pte_val(pte) & (_PAGE_READ | _PAGE_WRITE | _PAGE_EXEC);
+}
+
 /* static inline pte_t pte_rdprotect(pte_t pte) */

 static inline pte_t pte_wrprotect(pte_t pte)
@@ -358,6 +370,18 @@ static inline void set_pte_at(struct mm_struct *mm,
flush_icache_pte(pteval);

set_pte(ptep, pteval);
+
+   if (pte_present(pteval)) {
+   if (pte_leaf(pteval)) {
+   local_flush_tlb_page(addr);
+   } else {
+   if (pte_global(pteval))
+   local_flush_tlb_all();
+   else
+   local_flush_tlb_asid();
+
+   }
+   }
 }

 static inline void pte_clear(struct mm_struct *mm,
diff --git a/arch/riscv/include/asm/tlbflush.h 
b/arch/riscv/include/asm/tlbflush.h
index 394cfbccdcd9..4b25f51f163d 100644
--- a/arch/riscv/include/asm/tlbflush.h
+++ b/arch/riscv/include/asm/tlbflush.h
@@ -21,6 +21,14 @@ static inline void local_flush_tlb_page(unsigned long addr)
 {
__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory");
 }
+
+static unsigned long asid;
+static inline void local_flush_tlb_asid(void)
+{
+   asid = csr_read(CSR_SATP) | (SATP_ASID_MASK << SATP_ASID_SHIFT);
+   __asm__ __volatile__ ("sfence.vma x0, %0" : : "r" (asid) : "memory");
+}
+
 #else /* CONFIG_MMU */
 #define local_flush_tlb_all()  do { } while (0)
 #define local_flush_tlb_page(addr) do { } while (0)


We're trying to avoid this sort of thing, instead relying on the generic kernel
functionality to batch up page table modifications before we issue the fences.
If you're seeing some specific issue then I'd be happy to try and sort out a
fix for it, but this is a bit heavy-handed to use as anything but a last
resort.

Re: [PATCH v5] RISC-V: enable XIP

[Palmer Dabbelt]

On Wed, 10 Mar 2021 01:22:35 PST (-0800), vitaly.w...@konsulko.com wrote:

Introduce XIP (eXecute In Place) support for RISC-V platforms.
It allows code to be executed directly from non-volatile storage
directly addressable by the CPU, such as QSPI NOR flash which can
be found on many RISC-V platforms. This makes way for significant
optimization of RAM footprint. The XIP kernel is not compressed
since it has to run directly from flash, so it will occupy more
space on the non-volatile storage to The physical flash address
used to link the kernel object files and for storing it has to
be known at compile time and is represented by a Kconfig option.

XIP on RISC-V will currently only work on MMU-enabled kernels.

Signed-off-by: Vitaly Wool 

---
Changes in v2:
- dedicated macro for XIP address fixup when MMU is not enabled yet
  o both for 32-bit and 64-bit RISC-V
- SP is explicitly set to a safe place in RAM before __copy_data call
- removed redundant alignment requirements in vmlinux-xip.lds.S
- changed long -> uintptr_t typecast in __XIP_FIXUP macro.
Changes in v3:
- rebased against latest for-next
- XIP address fixup macro now takes an argument
- SMP related fixes
Changes in v4:
- rebased against the current for-next
- less #ifdef's in C/ASM code
- dedicated XIP_FIXUP_OFFSET assembler macro in head.S
- C-specific definitions moved into #ifndef __ASSEMBLY__
- Fixed multi-core boot
Changes in v5:
- fixed build error for non-XIP kernels

 arch/riscv/Kconfig  |  44 +-
 arch/riscv/Makefile |   8 +-
 arch/riscv/boot/Makefile|  13 +++
 arch/riscv/include/asm/pgtable.h|  65 --
 arch/riscv/kernel/cpu_ops_sbi.c |  12 ++-
 arch/riscv/kernel/head.S|  59 -
 arch/riscv/kernel/head.h|   3 +
 arch/riscv/kernel/setup.c   |   8 +-
 arch/riscv/kernel/vmlinux-xip.lds.S | 132 
 arch/riscv/kernel/vmlinux.lds.S |   6 ++
 arch/riscv/mm/init.c| 100 +++--
 11 files changed, 432 insertions(+), 18 deletions(-)
 create mode 100644 arch/riscv/kernel/vmlinux-xip.lds.S

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85d626b8ce5e..59fb945a900e 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -438,7 +438,7 @@ config EFI_STUB

 config EFI
bool "UEFI runtime support"
-   depends on OF
+   depends on OF && !XIP_KERNEL
select LIBFDT
select UCS2_STRING
select EFI_PARAMS_FROM_FDT
@@ -462,11 +462,51 @@ config STACKPROTECTOR_PER_TASK
def_bool y
depends on STACKPROTECTOR && CC_HAVE_STACKPROTECTOR_TLS

+config XIP_KERNEL
+   bool "Kernel Execute-In-Place from ROM"
+   depends on MMU
+   help
+ Execute-In-Place allows the kernel to run from non-volatile storage
+ directly addressable by the CPU, such as NOR flash. This saves RAM
+ space since the text section of the kernel is not loaded from flash
+ to RAM.  Read-write sections, such as the data section and stack,
+ are still copied to RAM.  The XIP kernel is not compressed since
+ it has to run directly from flash, so it will take more space to
+ store it.  The flash address used to link the kernel object files,
+ and for storing it, is configuration dependent. Therefore, if you
+ say Y here, you must know the proper physical address where to
+ store the kernel image depending on your own flash memory usage.
+
+ Also note that the make target becomes "make xipImage" rather than
+ "make zImage" or "make Image".  The final kernel binary to put in
+ ROM memory will be arch/riscv/boot/xipImage.
+
+ If unsure, say N.
+
+config XIP_PHYS_ADDR
+   hex "XIP Kernel Physical Location"
+   depends on XIP_KERNEL
+   default "0x2100"
+   help
+ This is the physical address in your flash memory the kernel will
+ be linked for and stored to.  This address is dependent on your
+ own flash usage.
+
+config XIP_PHYS_RAM_BASE
+   hex "Platform Physical RAM address"
+   depends on XIP_KERNEL
+   default "0x8000"
+   help
+ This is the physical address of RAM in the system. It has to be
+ explicitly specified to run early relocations of read-write data
+ from flash to RAM.
+
 endmenu

 config BUILTIN_DTB
-   def_bool n
+   bool
depends on OF
+   default y if XIP_KERNEL

 menu "Power management options"

diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 1368d943f1f3..8fcbec03974d 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -82,7 +82,11 @@ CHECKFLAGS += -D__riscv -D__riscv_xlen=$(BITS)

 # Default target when executing plain make
 boot   := arch/riscv/boot
+ifeq ($(CONFIG_XIP_KERNEL),y)
+KBUILD_IMAGE := $(boot)/xipImage
+else
 KBUILD_IMAGE   := $(boot)/Image.gz
+endif

 head-y := arch/riscv/kernel/head.

Re: [PATCH 2/2] riscv: Enable generic clockevent broadcast

[Palmer Dabbelt]

On Sat, 06 Mar 2021 18:24:46 PST (-0800), guo...@kernel.org wrote:

From: Guo Ren 

When percpu-timers are stopped by deep power saving mode, we
need system timer help to broadcast IPI_TIMER.

This is first introduced by broken x86 hardware, where the local apic
timer stops in C3 state. But many other architectures(powerpc, mips,
arm, hexagon, openrisc, sh) have supported the infrastructure to
deal with Power Management issues.

Signed-off-by: Guo Ren 
Cc: Arnd Bergmann 
Cc: Thomas Gleixner 
Cc: Daniel Lezcano 
Cc: Anup Patel 
Cc: Atish Patra 
Cc: Palmer Dabbelt 
Cc: Greentime Hu 
---
 arch/riscv/Kconfig  |  2 ++
 arch/riscv/kernel/smp.c | 16 
 2 files changed, 18 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85d626b8ce5e..8637e7344abe 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -28,6 +28,7 @@ config RISCV
select ARCH_HAS_SET_DIRECT_MAP
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU
+   select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
@@ -39,6 +40,7 @@ config RISCV
select EDAC_SUPPORT
select GENERIC_ARCH_TOPOLOGY if SMP
select GENERIC_ATOMIC64 if !64BIT
+   select GENERIC_CLOCKEVENTS_BROADCAST if SMP
select GENERIC_EARLY_IOREMAP
select GENERIC_GETTIMEOFDAY if HAVE_GENERIC_VDSO
select GENERIC_IOREMAP
diff --git a/arch/riscv/kernel/smp.c b/arch/riscv/kernel/smp.c
index ea028d9e0d24..8325d33411d8 100644
--- a/arch/riscv/kernel/smp.c
+++ b/arch/riscv/kernel/smp.c
@@ -9,6 +9,7 @@
  */

 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,6 +28,7 @@ enum ipi_message_type {
IPI_CALL_FUNC,
IPI_CPU_STOP,
IPI_IRQ_WORK,
+   IPI_TIMER,
IPI_MAX
 };

@@ -176,6 +178,12 @@ void handle_IPI(struct pt_regs *regs)
irq_work_run();
}

+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+   if (ops & (1 << IPI_TIMER)) {
+   stats[IPI_TIMER]++;
+   tick_receive_broadcast();
+   }
+#endif
BUG_ON((ops >> IPI_MAX) != 0);

/* Order data access and bit testing. */
@@ -192,6 +200,7 @@ static const char * const ipi_names[] = {
[IPI_CALL_FUNC] = "Function call interrupts",
[IPI_CPU_STOP]  = "CPU stop interrupts",
[IPI_IRQ_WORK]  = "IRQ work interrupts",
+   [IPI_TIMER] = "Timer broadcast interrupts",
 };

 void show_ipi_stats(struct seq_file *p, int prec)
@@ -217,6 +226,13 @@ void arch_send_call_function_single_ipi(int cpu)
send_ipi_single(cpu, IPI_CALL_FUNC);
 }

+#ifdef CONFIG_GENERIC_CLOCKEVENTS_BROADCAST
+void tick_broadcast(const struct cpumask *mask)
+{
+   send_ipi_mask(mask, IPI_TIMER);
+}
+#endif
+
 void smp_send_stop(void)
 {
unsigned long timeout;


Thanks, this is on for-next.

Re: [PATCH 2/4] clocksource: riscv: Using CPUHP_AP_ONLINE_DYN

[Palmer Dabbelt]

On Mon, 01 Mar 2021 06:28:20 PST (-0800), guo...@kernel.org wrote:

From: Guo Ren 

Remove RISC-V clocksource custom definitions in hotplug.h:
 - CPUHP_AP_RISCV_TIMER_STARTING

For coding convention.

Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Arnd Bergmann 
Cc: Linus Torvalds 
Cc: Anup Patel 
Cc: Christoph Hellwig 
Cc: Palmer Dabbelt 
Tested-by: Guo Ren 
Signed-off-by: Guo Ren 
Link: 
https://lore.kernel.org/lkml/CAHk-=wjM+kCsKqNdb=c0hKsv=J7-3Q1zmM15vp6_=8s5xfg...@mail.gmail.com/
---
 drivers/clocksource/timer-riscv.c | 4 ++--
 include/linux/cpuhotplug.h| 1 -
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/clocksource/timer-riscv.c 
b/drivers/clocksource/timer-riscv.c
index c51c5ed..43aee27 100644
--- a/drivers/clocksource/timer-riscv.c
+++ b/drivers/clocksource/timer-riscv.c
@@ -150,10 +150,10 @@ static int __init riscv_timer_init_dt(struct device_node 
*n)
return error;
}

-   error = cpuhp_setup_state(CPUHP_AP_RISCV_TIMER_STARTING,
+   error = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
 "clockevents/riscv/timer:starting",
 riscv_timer_starting_cpu, riscv_timer_dying_cpu);
-   if (error)
+   if (error < 0)
pr_err("cpu hp setup state failed for RISCV timer [%d]\n",
   error);
return error;
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index 14f49fd..f60538b 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -130,7 +130,6 @@ enum cpuhp_state {
CPUHP_AP_MARCO_TIMER_STARTING,
CPUHP_AP_MIPS_GIC_TIMER_STARTING,
CPUHP_AP_ARC_TIMER_STARTING,
-   CPUHP_AP_RISCV_TIMER_STARTING,
CPUHP_AP_CLINT_TIMER_STARTING,
CPUHP_AP_CSKY_TIMER_STARTING,
CPUHP_AP_HYPERV_TIMER_STARTING,


Acked-by: Palmer Dabbelt 

Just like the previous one.  Presumably CLINT is ours as well?

Thanks!

Re: [PATCH 1/4] irqchip: riscv: Using CPUHP_AP_ONLINE_DYN

[Palmer Dabbelt]

On Mon, 01 Mar 2021 06:28:19 PST (-0800), guo...@kernel.org wrote:

From: Guo Ren 

Remove RISC-V irqchip custom definitions in hotplug.h:
 - CPUHP_AP_IRQ_RISCV_STARTING
 - CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING

For coding convention.

Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: Arnd Bergmann 
Cc: Linus Torvalds 
Cc: Palmer Dabbelt 
Cc: Anup Patel 
Cc: Atish Patra 
Cc: Christoph Hellwig 
Tested-by: Guo Ren 
Signed-off-by: Guo Ren 
Link: 
https://lore.kernel.org/lkml/CAHk-=wjM+kCsKqNdb=c0hKsv=J7-3Q1zmM15vp6_=8s5xfg...@mail.gmail.com/
---
 drivers/irqchip/irq-riscv-intc.c  | 2 +-
 drivers/irqchip/irq-sifive-plic.c | 2 +-
 include/linux/cpuhotplug.h| 2 --
 3 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/drivers/irqchip/irq-riscv-intc.c b/drivers/irqchip/irq-riscv-intc.c
index 8017f6d..2c37f3a 100644
--- a/drivers/irqchip/irq-riscv-intc.c
+++ b/drivers/irqchip/irq-riscv-intc.c
@@ -125,7 +125,7 @@ static int __init riscv_intc_init(struct device_node *node,
return rc;
}

-   cpuhp_setup_state(CPUHP_AP_IRQ_RISCV_STARTING,
+   cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
  "irqchip/riscv/intc:starting",
  riscv_intc_cpu_starting,
  riscv_intc_cpu_dying);
diff --git a/drivers/irqchip/irq-sifive-plic.c 
b/drivers/irqchip/irq-sifive-plic.c
index 6f432d2..f499f1b 100644
--- a/drivers/irqchip/irq-sifive-plic.c
+++ b/drivers/irqchip/irq-sifive-plic.c
@@ -375,7 +375,7 @@ static int __init plic_init(struct device_node *node,
 */
handler = this_cpu_ptr(&plic_handlers);
if (handler->present && !plic_cpuhp_setup_done) {
-   cpuhp_setup_state(CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING,
+   cpuhp_setup_state(CPUHP_AP_ONLINE_DYN,
  "irqchip/sifive/plic:starting",
  plic_starting_cpu, plic_dying_cpu);
plic_cpuhp_setup_done = true;
diff --git a/include/linux/cpuhotplug.h b/include/linux/cpuhotplug.h
index f14adb8..14f49fd 100644
--- a/include/linux/cpuhotplug.h
+++ b/include/linux/cpuhotplug.h
@@ -103,8 +103,6 @@ enum cpuhp_state {
CPUHP_AP_IRQ_ARMADA_XP_STARTING,
CPUHP_AP_IRQ_BCM2836_STARTING,
CPUHP_AP_IRQ_MIPS_GIC_STARTING,
-   CPUHP_AP_IRQ_RISCV_STARTING,
-   CPUHP_AP_IRQ_SIFIVE_PLIC_STARTING,
CPUHP_AP_ARM_MVEBU_COHERENCY,
CPUHP_AP_MICROCODE_LOADER,
CPUHP_AP_PERF_X86_AMD_UNCORE_STARTING,


Acked-by: Palmer Dabbelt 

I'm going to assume this is going in through an irqchip tree, but LMK if you
want me to take it via mine.  This isn't really my sort of thing, so I'd prefer
at least an Ack.

Thanks!

Re: [PATCH] riscv: fix bugon.cocci warnings

[Palmer Dabbelt]

On Sun, 28 Feb 2021 03:10:22 PST (-0800), julia.law...@inria.fr wrote:

From: kernel test robot 

Use BUG_ON instead of a if condition followed by BUG.

Generated by: scripts/coccinelle/misc/bugon.cocci

Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
CC: Guo Ren 
Reported-by: kernel test robot 
Signed-off-by: kernel test robot 
Signed-off-by: Julia Lawall 
---

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   5695e51619745d4fe3ec2506a2f0cd982c5e27a4
commit: c22b0bcb1dd024cb9caad9230e3a387d8b061df5 riscv: Add kprobes supported
:: branch date: 3 hours ago
:: commit date: 6 weeks ago

 kprobes.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/arch/riscv/kernel/probes/kprobes.c
+++ b/arch/riscv/kernel/probes/kprobes.c
@@ -256,8 +256,7 @@ int __kprobes kprobe_fault_handler(struc
 * normal page fault.
 */
regs->epc = (unsigned long) cur->addr;
-   if (!instruction_pointer(regs))
-   BUG();
+   BUG_ON(!instruction_pointer(regs));

if (kcb->kprobe_status == KPROBE_REENTER)
restore_previous_kprobe(kcb);


Thanks, this is on fixes.

Re: [PATCH 0/9] riscv: misc cleanup

[Palmer Dabbelt]

On Fri, 05 Mar 2021 03:33:23 PST (-0800), sunnany...@huawei.com wrote:

Fix some compilation warnings,improve code style

Nanyong Sun (9):
  riscv: traps: Fix no prototype warnings
  riscv: irq: Fix no prototype warning
  riscv: sbi: Fix comment of __sbi_set_timer_v01
  riscv: ptrace: Fix no prototype warnings
  riscv: time: Fix no prototype for time_init
  riscv: syscall_table: Reduce W=1 compilation warnings noise
  riscv: process: Fix no prototype for show_regs
  riscv: ftrace: Use ftrace_get_regs helper
  riscv: process: Fix no prototype for arch_dup_task_struct

 arch/riscv/include/asm/asm-prototypes.h | 16 
 arch/riscv/include/asm/irq.h|  2 ++
 arch/riscv/include/asm/processor.h  |  1 +
 arch/riscv/include/asm/ptrace.h |  5 +
 arch/riscv/include/asm/timex.h  |  2 ++
 arch/riscv/kernel/Makefile  |  1 +
 arch/riscv/kernel/probes/ftrace.c   | 16 +---
 arch/riscv/kernel/process.c |  1 +
 arch/riscv/kernel/sbi.c |  2 +-
 arch/riscv/kernel/time.c|  1 +
 arch/riscv/kernel/traps.c   |  1 +
 11 files changed, 40 insertions(+), 8 deletions(-)


Thanks.  I fixed the checkpatch warning, these are all on fixes.

Re: [PATCH 1/9] riscv: traps: Fix no prototype warnings

[Palmer Dabbelt]

On Fri, 05 Mar 2021 03:33:24 PST (-0800), sunnany...@huawei.com wrote:

Fix all W=1 compilation warnings:'no previous prototype for' in 
arch/riscv/kernel/traps.c:
arch/riscv/kernel/traps.c:96:15: warning: no previous prototype for 
‘do_trap_unknown’ [-Wmissing-prototypes]
   96 | DO_ERROR_INFO(do_trap_unknown,
  |   ^~~
arch/riscv/kernel/traps.c:91:27: note: in definition of macro ‘DO_ERROR_INFO’
   91 | asmlinkage __visible void name(struct pt_regs *regs)   \
  |   ^~~~
arch/riscv/kernel/traps.c:98:15: warning: no previous prototype for 
‘do_trap_insn_misaligned’ [-Wmissing-prototypes]
   98 | DO_ERROR_INFO(do_trap_insn_misaligned,
  |   ^~~
arch/riscv/kernel/traps.c:91:27: note: in definition of macro ‘DO_ERROR_INFO’
   91 | asmlinkage __visible void name(struct pt_regs *regs)   \
  |   ^~~~
arch/riscv/kernel/traps.c:100:15: warning: no previous prototype for 
‘do_trap_insn_fault’ [-Wmissing-prototypes]
...

Reported-by: Hulk Robot 
Signed-off-by: Nanyong Sun 
---
 arch/riscv/include/asm/asm-prototypes.h | 16 
 arch/riscv/kernel/traps.c   |  1 +
 2 files changed, 17 insertions(+)

diff --git a/arch/riscv/include/asm/asm-prototypes.h 
b/arch/riscv/include/asm/asm-prototypes.h
index 27e005fca584..6d81abf5d9f8 100644
--- a/arch/riscv/include/asm/asm-prototypes.h
+++ b/arch/riscv/include/asm/asm-prototypes.h
@@ -9,4 +9,20 @@ long long __lshrti3(long long a, int b);
 long long __ashrti3(long long a, int b);
 long long __ashlti3(long long a, int b);

+
+#define DECLARE_DO_ERROR_INFO(name)asmlinkage void name(struct pt_regs 
*regs);


This triggers checkpatch.


+
+DECLARE_DO_ERROR_INFO(do_trap_unknown)
+DECLARE_DO_ERROR_INFO(do_trap_insn_misaligned)
+DECLARE_DO_ERROR_INFO(do_trap_insn_fault)
+DECLARE_DO_ERROR_INFO(do_trap_insn_illegal)
+DECLARE_DO_ERROR_INFO(do_trap_load_fault)
+DECLARE_DO_ERROR_INFO(do_trap_load_misaligned)
+DECLARE_DO_ERROR_INFO(do_trap_store_misaligned)
+DECLARE_DO_ERROR_INFO(do_trap_store_fault)
+DECLARE_DO_ERROR_INFO(do_trap_ecall_u)
+DECLARE_DO_ERROR_INFO(do_trap_ecall_s)
+DECLARE_DO_ERROR_INFO(do_trap_ecall_m)
+DECLARE_DO_ERROR_INFO(do_trap_break)
+
 #endif /* _ASM_RISCV_PROTOTYPES_H */
diff --git a/arch/riscv/kernel/traps.c b/arch/riscv/kernel/traps.c
index 3ed2c23601a0..0879b5df11b9 100644
--- a/arch/riscv/kernel/traps.c
+++ b/arch/riscv/kernel/traps.c
@@ -17,6 +17,7 @@
 #include 
 #include 

+#include 
 #include 
 #include 
 #include 

Re: [PATCH 2/6] mm: Generalize SYS_SUPPORTS_HUGETLBFS (rename as ARCH_SUPPORTS_HUGETLBFS)

[Palmer Dabbelt]

On Tue, 09 Mar 2021 00:33:06 PST (-0800), anshuman.khand...@arm.com wrote:

SYS_SUPPORTS_HUGETLBFS config has duplicate definitions on platforms that
subscribe it. Instead, just make it a generic option which can be selected
on applicable platforms. Also rename it as ARCH_SUPPORTS_HUGETLBFS instead.
This reduces code duplication and makes it cleaner.

Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Thomas Bogendoerfer 
Cc: "James E.J. Bottomley" 
Cc: Helge Deller 
Cc: Michael Ellerman 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: Alexander Viro 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-m...@vger.kernel.org
Cc: linux-par...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: linux-ri...@lists.infradead.org
Cc: linux...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Anshuman Khandual 
---
 arch/arm/Kconfig   | 5 +
 arch/arm64/Kconfig | 4 +---
 arch/mips/Kconfig  | 6 +-
 arch/parisc/Kconfig| 5 +
 arch/powerpc/Kconfig   | 3 ---
 arch/powerpc/platforms/Kconfig.cputype | 6 +++---
 arch/riscv/Kconfig | 5 +
 arch/sh/Kconfig| 5 +
 fs/Kconfig | 5 -
 9 files changed, 13 insertions(+), 31 deletions(-)


[...]


diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 85d626b8ce5e..69954db3aca9 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -30,6 +30,7 @@ config RISCV
select ARCH_HAS_STRICT_KERNEL_RWX if MMU
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT
+   select ARCH_SUPPORTS_HUGETLBFS if MMU
select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
select ARCH_WANT_FRAME_POINTERS
select ARCH_WANT_HUGE_PMD_SHARE if 64BIT
@@ -165,10 +166,6 @@ config ARCH_WANT_GENERAL_HUGETLB
 config ARCH_SUPPORTS_UPROBES
def_bool y

-config SYS_SUPPORTS_HUGETLBFS
-   depends on MMU
-   def_bool y
-
 config STACKTRACE_SUPPORT
def_bool y


Acked-by: Palmer Dabbelt 

Re: [PATCH 1/1] RISC-V: correct enum sbi_ext_rfence_fid

[Palmer Dabbelt]

On Tue, 09 Mar 2021 11:28:39 PST (-0800), ati...@atishpatra.org wrote:

On Mon, Mar 8, 2021 at 2:55 AM Anup Patel  wrote:


On Mon, Mar 8, 2021 at 1:19 PM Atish Patra  wrote:
>
> On Sat, Mar 6, 2021 at 4:12 AM Anup Patel  wrote:
> >
> > On Sat, Mar 6, 2021 at 11:19 AM Heinrich Schuchardt  
wrote:
> > >
> > > The constants in enum sbi_ext_rfence_fid should match the SBI
> > > specification. See
> > > 
https://github.com/riscv/riscv-sbi-doc/blob/master/riscv-sbi.adoc#78-function-listing
> > >
> > > | Function Name   | FID | EID
> > > | sbi_remote_fence_i  |   0 | 0x52464E43
> > > | sbi_remote_sfence_vma   |   1 | 0x52464E43
> > > | sbi_remote_sfence_vma_asid  |   2 | 0x52464E43
> > > | sbi_remote_hfence_gvma_vmid |   3 | 0x52464E43
> > > | sbi_remote_hfence_gvma  |   4 | 0x52464E43
> > > | sbi_remote_hfence_vvma_asid |   5 | 0x52464E43
> > > | sbi_remote_hfence_vvma  |   6 | 0x52464E43
> > >
> > > Fixes: ecbacc2a3efd ("RISC-V: Add SBI v0.2 extension definitions")
> > > Reported-by: Sean Anderson 
> > > Signed-off-by: Heinrich Schuchardt 
> >


Reviewed-by: Atish Patra 


> > Good catch.
> >
> > I guess we never saw any issues because these calls are only used by
> > KVM RISC-V which is not merged yet. Further for KVM RISC-V, the HFENCE
> > instruction is emulated as flush everything on FPGA, QEMU, and Spike so
> > we did not notice any issue with KVM RISC-V too.
> >
>
> OpenSBI & Xvisor also define the same order as Linux kernel. The
> existing order(in Linux kernel)
> makes more sense w.r.to Lexicographic order as well.
>
> Should we just fix the spec instead ?

I would not recommend that because RFENCE is part of the released SBI v0.2 spec.



Fair enough.


Yes, agreed.  It's very important that we don't change the specs we said are 
frozen, that would be a huge mess.


This is on fixes.

Thanks!




We have to be more careful in software to follow the spec correctly.



Agreed. Apologies for the slip up.


Regards,
Anup

>
> > Looks good to me.
> >
> > Reviewed-by: Anup Patel 
> >
> > Regards,
> > Anup
> >
> > > ---
> > >  arch/riscv/include/asm/sbi.h | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
> > > index 99895d9c3bdd..d7027411dde8 100644
> > > --- a/arch/riscv/include/asm/sbi.h
> > > +++ b/arch/riscv/include/asm/sbi.h
> > > @@ -51,10 +51,10 @@ enum sbi_ext_rfence_fid {
> > > SBI_EXT_RFENCE_REMOTE_FENCE_I = 0,
> > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
> > > SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
> > > -   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > > SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA_VMID,
> > > -   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > > +   SBI_EXT_RFENCE_REMOTE_HFENCE_GVMA,
> > > SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA_ASID,
> > > +   SBI_EXT_RFENCE_REMOTE_HFENCE_VVMA,
> > >  };
> > >
> > >  enum sbi_ext_hsm_fid {
> > > --
> > > 2.30.1
> > >
> > >
> > > ___
> > > linux-riscv mailing list
> > > linux-ri...@lists.infradead.org
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> >
> > ___
> > linux-riscv mailing list
> > linux-ri...@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-riscv
>
>
>
> --
> Regards,
> Atish

Re: [PATCH v2] riscv: Return -EFAULT if copy_{to,from}_user() failed in signal.c

[Palmer Dabbelt]

On Fri, 05 Mar 2021 23:52:29 PST (-0800), yangtie...@loongson.cn wrote:

copy_{to,from}_user() returns the amount left to copy, it should return
-EFAULT error code if copy {to,from} user failed, just like the return
value is an error code when {put,get}_user() failed, this is to make the
return value consistent, no function change.

Signed-off-by: Tiezhu Yang 
---
 arch/riscv/kernel/signal.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/kernel/signal.c b/arch/riscv/kernel/signal.c
index 65942b3..c76d877 100644
--- a/arch/riscv/kernel/signal.c
+++ b/arch/riscv/kernel/signal.c
@@ -39,7 +39,7 @@ static long restore_fp_state(struct pt_regs *regs,

err = __copy_from_user(¤t->thread.fstate, state, sizeof(*state));
if (unlikely(err))
-   return err;
+   return -EFAULT;

fstate_restore(current, regs);

@@ -67,7 +67,7 @@ static long save_fp_state(struct pt_regs *regs,
fstate_save(current, regs);
err = __copy_to_user(state, ¤t->thread.fstate, sizeof(*state));
if (unlikely(err))
-   return err;
+   return -EFAULT;

/* We support no other extension state at this time. */
for (i = 0; i < ARRAY_SIZE(sc_fpregs->q.reserved); i++) {
@@ -87,8 +87,12 @@ static long restore_sigcontext(struct pt_regs *regs,
struct sigcontext __user *sc)
 {
long err;
+
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_from_user(regs, &sc->sc_regs, sizeof(sc->sc_regs));
+   if (unlikely(err))
+   return -EFAULT;
+
/* Restore the floating-point state. */
if (has_fpu)
err |= restore_fp_state(regs, &sc->sc_fpregs);
@@ -140,8 +144,12 @@ static long setup_sigcontext(struct rt_sigframe __user 
*frame,
 {
struct sigcontext __user *sc = &frame->uc.uc_mcontext;
long err;
+
/* sc_regs is structured the same as the start of pt_regs */
err = __copy_to_user(&sc->sc_regs, regs, sizeof(sc->sc_regs));
+   if (unlikely(err))
+   return -EFAULT;
+
/* Save the floating-point state. */
if (has_fpu)
err |= save_fp_state(regs, &sc->sc_fpregs);


I don't really see any benefit to this way of doing it over what's there: these 
are only used within this file, and the caller is just doing this return 
conversion already.  If anything I find the current code easier to understand, 
as error juggling is always one of the trickier things to get right and I 
always find it easier to reason about code that's just passing through errors.


If you have some new user of this code where it makes more sense to do it this 
way then I'd be happy to take a look, but this as it stands doesn't really look 
better.

Re: [PATCH] riscv: kasan: remove unneeded semicolon

[Palmer Dabbelt]

On Mon, 01 Mar 2021 22:36:48 PST (-0800), jiapeng.ch...@linux.alibaba.com wrote:

Fix the following coccicheck warnings:

./arch/riscv/mm/kasan_init.c:217:2-3: Unneeded semicolon.

Reported-by: Abaci Robot 
Signed-off-by: Jiapeng Chong 
---
 arch/riscv/mm/kasan_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 3fc18f4..e202cdb 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -214,7 +214,7 @@ void __init kasan_init(void)
break;

kasan_populate(kasan_mem_to_shadow(start), 
kasan_mem_to_shadow(end));
-   };
+   }

for (i = 0; i < PTRS_PER_PTE; i++)
set_pte(&kasan_early_shadow_pte[i],


Looks like this one has already been fixed, thanks though!

Re: [PATCH v4] RISC-V: Use SBI SRST extension when available

[Palmer Dabbelt]

On Mon, 01 Mar 2021 03:58:33 PST (-0800), Anup Patel wrote:

The SBI SRST extension provides a standard way to poweroff and
reboot the system irrespective to whether Linux RISC-V S-mode
is running natively (HS-mode) or inside Guest/VM (VS-mode).

The SBI SRST extension is available in latest SBI v0.3-draft
specification at: https://github.com/riscv/riscv-sbi-doc.

This patch extends Linux RISC-V SBI implementation to detect
and use SBI SRST extension.

Signed-off-by: Anup Patel 
---
 arch/riscv/include/asm/sbi.h | 16 ++
 arch/riscv/kernel/sbi.c  | 41 +---
 2 files changed, 54 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 99895d9c3bdd..8add0209c9c7 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -27,6 +27,7 @@ enum sbi_ext_id {
SBI_EXT_IPI = 0x735049,
SBI_EXT_RFENCE = 0x52464E43,
SBI_EXT_HSM = 0x48534D,
+   SBI_EXT_SRST = 0x53525354,
 };

 enum sbi_ext_base_fid {
@@ -70,6 +71,21 @@ enum sbi_hsm_hart_status {
SBI_HSM_HART_STATUS_STOP_PENDING,
 };

+enum sbi_ext_srst_fid {
+   SBI_EXT_SRST_RESET = 0,
+};
+
+enum sbi_srst_reset_type {
+   SBI_SRST_RESET_TYPE_SHUTDOWN = 0,
+   SBI_SRST_RESET_TYPE_COLD_REBOOT,
+   SBI_SRST_RESET_TYPE_WARM_REBOOT,
+};
+
+enum sbi_srst_reset_reason {
+   SBI_SRST_RESET_REASON_NONE = 0,
+   SBI_SRST_RESET_REASON_SYS_FAILURE,
+};
+
 #define SBI_SPEC_VERSION_DEFAULT   0x1
 #define SBI_SPEC_VERSION_MAJOR_SHIFT   24
 #define SBI_SPEC_VERSION_MAJOR_MASK0x7f
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index f4a7db3d309e..49155588e56c 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -7,6 +7,7 @@

 #include 
 #include 
+#include 
 #include 
 #include 

@@ -501,6 +502,32 @@ int sbi_remote_hfence_vvma_asid(const unsigned long 
*hart_mask,
 }
 EXPORT_SYMBOL(sbi_remote_hfence_vvma_asid);

+static void sbi_srst_reset(unsigned long type, unsigned long reason)
+{
+   sbi_ecall(SBI_EXT_SRST, SBI_EXT_SRST_RESET, type, reason,
+ 0, 0, 0, 0);
+   pr_warn("%s: type=0x%lx reason=0x%lx failed\n",
+   __func__, type, reason);
+}
+
+static int sbi_srst_reboot(struct notifier_block *this,
+  unsigned long mode, void *cmd)
+{
+   sbi_srst_reset((mode == REBOOT_WARM || mode == REBOOT_SOFT) ?
+  SBI_SRST_RESET_TYPE_WARM_REBOOT :
+  SBI_SRST_RESET_TYPE_COLD_REBOOT,
+  SBI_SRST_RESET_REASON_NONE);
+   return NOTIFY_DONE;
+}
+
+static struct notifier_block sbi_srst_reboot_nb;
+
+static void sbi_srst_power_off(void)
+{
+   sbi_srst_reset(SBI_SRST_RESET_TYPE_SHUTDOWN,
+  SBI_SRST_RESET_REASON_NONE);
+}
+
 /**
  * sbi_probe_extension() - Check if an SBI extension ID is supported or not.
  * @extid: The extension ID to be probed.
@@ -577,22 +604,30 @@ void __init sbi_init(void)
sbi_get_firmware_id(), sbi_get_firmware_version());
if (sbi_probe_extension(SBI_EXT_TIME) > 0) {
__sbi_set_timer = __sbi_set_timer_v02;
-   pr_info("SBI v0.2 TIME extension detected\n");
+   pr_info("SBI TIME extension detected\n");
} else {
__sbi_set_timer = __sbi_set_timer_v01;
}
if (sbi_probe_extension(SBI_EXT_IPI) > 0) {
__sbi_send_ipi  = __sbi_send_ipi_v02;
-   pr_info("SBI v0.2 IPI extension detected\n");
+   pr_info("SBI IPI extension detected\n");


These aren't really part of the reset stuff and should be split into a separate 
patch.



} else {
__sbi_send_ipi  = __sbi_send_ipi_v01;
}
if (sbi_probe_extension(SBI_EXT_RFENCE) > 0) {
__sbi_rfence= __sbi_rfence_v02;
-   pr_info("SBI v0.2 RFENCE extension detected\n");
+   pr_info("SBI RFENCE extension detected\n");
} else {
__sbi_rfence= __sbi_rfence_v01;
}
+   if (sbi_probe_extension(SBI_EXT_SRST) > 0 &&
+   sbi_minor_version() >= 3) {
+   pr_info("SBI SRST extension detected\n");
+   pm_power_off = sbi_srst_power_off;
+   sbi_srst_reboot_nb.notifier_call = sbi_srst_reboot;
+   sbi_srst_reboot_nb.priority = 192;
+   register_restart_handler(&sbi_srst_reboot_nb);
+   }
} else {
__sbi_set_timer = __sbi_set_timer_v01;
__sbi_send_ipi  = __sbi_send_ipi_v01;


This is fine, but I don't want to take things for draft SBI versions until 
they're at least tagged.

Re: [PATCH 0/3] Move kernel mapping outside the linear mapping

[Palmer Dabbelt]

On Thu, 25 Feb 2021 00:04:50 PST (-0800), a...@ghiti.fr wrote:

I decided to split sv48 support in small series to ease the review.

This patchset pushes the kernel mapping (modules and BPF too) to the last
4GB of the 64bit address space, this allows to:
- implement relocatable kernel (that will come later in another
  patchset) that requires to move the kernel mapping out of the linear
  mapping to avoid to copy the kernel at a different physical address.
- have a single kernel that is not relocatable (and then that avoids the
  performance penalty imposed by PIC kernel) for both sv39 and sv48.

The first patch implements this behaviour, the second patch introduces a
documentation that describes the virtual address space layout of the 64bit
kernel and the last patch is taken from my sv48 series where I simply added
the dump of the modules/kernel/BPF mapping.

I removed the Reviewed-by on the first patch since it changed enough from
last time and deserves a second look.

Alexandre Ghiti (3):
  riscv: Move kernel mapping outside of linear mapping
  Documentation: riscv: Add documentation that describes the VM layout
  riscv: Prepare ptdump for vm layout dynamic addresses

 Documentation/riscv/index.rst   |  1 +
 Documentation/riscv/vm-layout.rst   | 61 ++
 arch/riscv/boot/loader.lds.S|  3 +-
 arch/riscv/include/asm/page.h   | 18 ++-
 arch/riscv/include/asm/pgtable.h| 37 +
 arch/riscv/include/asm/set_memory.h |  1 +
 arch/riscv/kernel/head.S|  3 +-
 arch/riscv/kernel/module.c  |  6 +--
 arch/riscv/kernel/setup.c   |  3 ++
 arch/riscv/kernel/vmlinux.lds.S |  3 +-
 arch/riscv/mm/fault.c   | 13 +
 arch/riscv/mm/init.c| 81 +++--
 arch/riscv/mm/kasan_init.c  |  9 
 arch/riscv/mm/physaddr.c|  2 +-
 arch/riscv/mm/ptdump.c  | 67 +++-
 15 files changed, 258 insertions(+), 50 deletions(-)
 create mode 100644 Documentation/riscv/vm-layout.rst


This generally looks good, but I'm getting a bunch of checkpatch warnings and 
some conflicts, do you mind fixing those up (and including your other kasan 
patch, as that's likely to conflict)?

Re: [PATCH v2] riscv: Improve KASAN_VMALLOC support

[Palmer Dabbelt]

On Fri, 26 Feb 2021 10:01:54 PST (-0800), a...@ghiti.fr wrote:

When KASAN vmalloc region is populated, there is no userspace process and
the page table in use is swapper_pg_dir, so there is no need to read
SATP. Then we can use the same scheme used by kasan_populate_p*d
functions to go through the page table, which harmonizes the code.

In addition, make use of set_pgd that goes through all unused page table
levels, contrary to p*d_populate functions, which makes this function work
whatever the number of page table levels.

And finally, make sure the writes to swapper_pg_dir are visible using
an sfence.vma.


So I think this is actually a bug: without the fence we could get a 
kasan-related fault at any point (as the mappings might not be visible yet), 
and if we get one when inside do_page_fault() (or while holding a lock it 
wants) we'll end up deadlocking against ourselves.  That'll probably never 
happen in practice, but it'd still be good to get the fence onto fixes.  The 
rest are cleanups, they're for for-next (and should probably be part of your 
sv48 series, if you need to re-spin it -- I'll look at that next).


LMK if you want to split this up, or if you want me to do it.  Either way,

Reviewed-by: Palmer Dabbelt 

Thanks!


Signed-off-by: Alexandre Ghiti 
---

Changes in v2:
- Quiet kernel test robot warnings about missing prototypes by declaring
  the introduced functions as static.

 arch/riscv/mm/kasan_init.c | 61 +-
 1 file changed, 20 insertions(+), 41 deletions(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index e3d91f334b57..aaa3bdc0ffc0 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -11,18 +11,6 @@
 #include 
 #include 

-static __init void *early_alloc(size_t size, int node)
-{
-   void *ptr = memblock_alloc_try_nid(size, size,
-   __pa(MAX_DMA_ADDRESS), MEMBLOCK_ALLOC_ACCESSIBLE, node);
-
-   if (!ptr)
-   panic("%pS: Failed to allocate %zu bytes align=%zx nid=%d 
from=%llx\n",
-   __func__, size, size, node, (u64)__pa(MAX_DMA_ADDRESS));
-
-   return ptr;
-}
-
 extern pgd_t early_pg_dir[PTRS_PER_PGD];
 asmlinkage void __init kasan_early_init(void)
 {
@@ -155,38 +143,29 @@ static void __init kasan_populate(void *start, void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
 }

-void __init kasan_shallow_populate(void *start, void *end)
+static void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned 
long end)
 {
-   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
-   unsigned long vend = PAGE_ALIGN((unsigned long)end);
-   unsigned long pfn;
-   int index;
+   unsigned long next;
void *p;
-   pud_t *pud_dir, *pud_k;
-   pgd_t *pgd_dir, *pgd_k;
-   p4d_t *p4d_dir, *p4d_k;
-
-   while (vaddr < vend) {
-   index = pgd_index(vaddr);
-   pfn = csr_read(CSR_SATP) & SATP_PPN;
-   pgd_dir = (pgd_t *)pfn_to_virt(pfn) + index;
-   pgd_k = init_mm.pgd + index;
-   pgd_dir = pgd_offset_k(vaddr);
-   set_pgd(pgd_dir, *pgd_k);
-
-   p4d_dir = p4d_offset(pgd_dir, vaddr);
-   p4d_k  = p4d_offset(pgd_k, vaddr);
-
-   vaddr = (vaddr + PUD_SIZE) & PUD_MASK;
-   pud_dir = pud_offset(p4d_dir, vaddr);
-   pud_k = pud_offset(p4d_k, vaddr);
-
-   if (pud_present(*pud_dir)) {
-   p = early_alloc(PAGE_SIZE, NUMA_NO_NODE);
-   pud_populate(&init_mm, pud_dir, p);
+   pgd_t *pgd_k = pgd_offset_k(vaddr);
+
+   do {
+   next = pgd_addr_end(vaddr, end);
+   if (pgd_page_vaddr(*pgd_k) == (unsigned 
long)lm_alias(kasan_early_shadow_pmd)) {
+   p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+   set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
}
-   vaddr += PAGE_SIZE;
-   }
+   } while (pgd_k++, vaddr = next, vaddr != end);
+}
+
+static void __init kasan_shallow_populate(void *start, void *end)
+{
+   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
+   unsigned long vend = PAGE_ALIGN((unsigned long)end);
+
+   kasan_shallow_populate_pgd(vaddr, vend);
+
+   local_flush_tlb_all();
 }

 void __init kasan_init(void)

Re: [PATCH] Documentation/admin-guide: kernel-parameters: correct the architectures for numa_balancing

[Palmer Dabbelt]

On Tue, 02 Mar 2021 00:41:59 PST (-0800), song.bao@hisilicon.com wrote:

X86 isn't the only architecture supporting NUMA_BALANCING. ARM64, PPC,
S390 and RISCV also support it:

arch$ git grep NUMA_BALANCING
arm64/Kconfig:  select ARCH_SUPPORTS_NUMA_BALANCING
arm64/configs/defconfig:CONFIG_NUMA_BALANCING=y
arm64/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
powerpc/configs/powernv_defconfig:CONFIG_NUMA_BALANCING=y
powerpc/configs/ppc64_defconfig:CONFIG_NUMA_BALANCING=y
powerpc/configs/pseries_defconfig:CONFIG_NUMA_BALANCING=y
powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
powerpc/include/asm/book3s/64/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */
powerpc/include/asm/book3s/64/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
powerpc/include/asm/book3s/64/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */
powerpc/include/asm/nohash/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
powerpc/include/asm/nohash/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */
powerpc/platforms/Kconfig.cputype:  select ARCH_SUPPORTS_NUMA_BALANCING
riscv/Kconfig:  select ARCH_SUPPORTS_NUMA_BALANCING
riscv/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
s390/Kconfig:   select ARCH_SUPPORTS_NUMA_BALANCING
s390/configs/debug_defconfig:CONFIG_NUMA_BALANCING=y
s390/configs/defconfig:CONFIG_NUMA_BALANCING=y
s390/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
x86/Kconfig:select ARCH_SUPPORTS_NUMA_BALANCING if X86_64
x86/include/asm/pgtable.h:#ifdef CONFIG_NUMA_BALANCING
x86/include/asm/pgtable.h:#endif /* CONFIG_NUMA_BALANCING */

On the other hand, setup_numabalancing() is implemented in mm/mempolicy.c
which doesn't depend on architectures.

Cc: Mel Gorman 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: "Paul E. McKenney" 
Cc: Randy Dunlap 
Cc: Andrew Morton 
Cc: Thomas Gleixner 
Cc: Mauro Carvalho Chehab 
Cc: Viresh Kumar 
Cc: Mike Kravetz 
Cc: Peter Zijlstra 
Signed-off-by: Barry Song 
---
 Documentation/admin-guide/kernel-parameters.rst | 1 +
 Documentation/admin-guide/kernel-parameters.txt | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index 1132796a8d96..24302cad174a 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -140,6 +140,7 @@ parameter is applicable::
PPT Parallel port support is enabled.
PS2 Appropriate PS/2 support is enabled.
RAM RAM disk support is enabled.
+   RISCV   RISCV architecture is enabled.
RDT Intel Resource Director Technology.
S390S390 architecture is enabled.
SCSIAppropriate SCSI support is enabled.
diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 04545725f187..371a02ae1e21 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -3472,7 +3472,8 @@

nr_uarts=   [SERIAL] maximum number of UARTs to be registered.

-   numa_balancing= [KNL,X86] Enable or disable automatic NUMA balancing.
+   numa_balancing= [KNL,ARM64,PPC,RISCV,S390,X86] Enable or disable 
automatic
+   NUMA balancing.
Allowed values are enable and disable

numa_zonelist_order= [KNL, BOOT] Select zonelist order for NUMA.


Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

[GIT PULL] RISC-V Patches for the 5.12 Merge Window, Part 2

[Palmer Dabbelt]

merged tag 'riscv-for-linus-5.12-mw0'
The following changes since commit 8b83369ddcb3fb9cab5c1088987ce477565bb630:

  Merge tag 'riscv-for-linus-5.12-mw0' of 
git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux (2021-02-26 10:28:35 
-0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.12-mw1

for you to fetch changes up to dd2d082b57602156e0c587ddb5ba04d0d624a6df:

  riscv: Cleanup setup_bootmem() (2021-02-26 21:25:17 -0800)


RISC-V Patches for the 5.12 Merge Window, Part 2

I have a pair of patches that slipped through the cracks:

* CPU hotplug has been enabled in the defconfigs
* Some cleanups to setup_bootmem.

There's also a single fix

* Force NUMA to depend on SMP.  This fixes some randconfig build
  failures.


Anup Patel (1):
  RISC-V: Enable CPU Hotplug in defconfigs

Kefeng Wang (1):
  riscv: Cleanup setup_bootmem()

Palmer Dabbelt (1):
  RISC-V: Make NUMA depend on SMP

 arch/riscv/Kconfig|  1 +
 arch/riscv/configs/defconfig  |  1 +
 arch/riscv/configs/rv32_defconfig |  1 +
 arch/riscv/mm/init.c  | 21 ++---
 4 files changed, 5 insertions(+), 19 deletions(-)

Re: [PATCH] RISC-V: Enable CPU Hotplug in defconfigs

[Palmer Dabbelt]

On Mon, 08 Feb 2021 21:46:20 PST (-0800), Anup Patel wrote:

The CPU hotplug support has been tested on QEMU, Spike, and SiFive
Unleashed so let's enable it by default in RV32 and RV64 defconfigs.

Signed-off-by: Anup Patel 
---
 arch/riscv/configs/defconfig  | 1 +
 arch/riscv/configs/rv32_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 8c3d1e451703..6c0625aa96c7 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -17,6 +17,7 @@ CONFIG_BPF_SYSCALL=y
 CONFIG_SOC_SIFIVE=y
 CONFIG_SOC_VIRT=y
 CONFIG_SMP=y
+CONFIG_HOTPLUG_CPU=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
diff --git a/arch/riscv/configs/rv32_defconfig 
b/arch/riscv/configs/rv32_defconfig
index 2c2cda6cc1c5..8dd02b842fef 100644
--- a/arch/riscv/configs/rv32_defconfig
+++ b/arch/riscv/configs/rv32_defconfig
@@ -18,6 +18,7 @@ CONFIG_SOC_SIFIVE=y
 CONFIG_SOC_VIRT=y
 CONFIG_ARCH_RV32I=y
 CONFIG_SMP=y
+CONFIG_HOTPLUG_CPU=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y


Sorry about that.  I missed a handful of things, I'll send this out tomorrow.

Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA

[Palmer Dabbelt]

On Fri, 26 Feb 2021 19:41:40 PST (-0800), hu...@google.com wrote:

On Fri, 26 Feb 2021, Palmer Dabbelt wrote:

On Fri, 26 Feb 2021 17:31:40 PST (-0800), hu...@google.com wrote:
> On Fri, 26 Feb 2021, Andrew Morton wrote:
> > On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt 
> > wrote:
> > > From: Palmer Dabbelt 
> > >
> > > This is only useful under CONFIG_NUMA.  IIUC skipping the check is the
> > > right thing to do here, as without CONFIG_NUMA there will never be any
> > > large node distances on non-NUMA systems.
> > >
> > > I expected this to manifest as a link failure under (!CONFIG_NUMA &&
> > > CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that.  I
> > > think the reference is just getting pruned before it's checked, but I
> > > didn't get that from reading the code so I'm worried I'm missing
> > > something.
> > >
> > > Either way, this is necessary to guard the definition of
> > > node_reclaim_distance with CONFIG_NUMA.
> > >
> > > Signed-off-by: Palmer Dabbelt 
> > > ---
> > >  mm/khugepaged.c | 2 ++
> > >  1 file changed, 2 insertions(+)
> > >
> > > diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> > > index a7d6cb912b05..b1bf191c3a54 100644
> > > --- a/mm/khugepaged.c
> > > +++ b/mm/khugepaged.c
> > > @@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid)
> > >  for (i = 0; i < MAX_NUMNODES; i++) {
> > >  if (!khugepaged_node_load[i])
> > >  continue;
> > > +#ifdef CONFIG_NUMA
> > >  if (node_distance(nid, i) > node_reclaim_distance)
> > >  return true;
> > > +#endif
> > >  }
> > >  return false;
> > >  }
> >
> > This makes the entire loop a no-op.  Perhaps Kirill can help take a
> > look at removing unnecessary code in khugepaged.c when CONFIG_NUMA=n?
>
> First lines of khugepaged_scan_abort() say
>if (!node_reclaim_mode)
>return false;
>
> And include/linux/swap.h says
> #ifdef CONFIG_NUMA
> extern int node_reclaim_mode;
> extern int sysctl_min_unmapped_ratio;
> extern int sysctl_min_slab_ratio;
> #else
> #define node_reclaim_mode 0
> #endif
>
> So, no need for an #ifdef CONFIG_NUMA inside khugepaged_scan_abort().

Ah, thanks, I hadn't seen that.  That certainly explains the lack of an
undefined reference.

That said: do we generally rely on DCE to prune references to undefined
symbols?  This particular one seems like it'd get reliably deleted, but it
seems like a fragile thing to do in general.  This kind of stuff would
certainly make some code easier to write, though.


Yes, the kernel build very much depends on the optimizer eliminating
dead code, in many many places.  We do prefer to keep the #ifdefs to
the header files as much as possible.


OK, makes sense.  Thanks!


I don't really care all that much, though, as I was just sending this along
due to some build failure report from a user that I couldn't reproduce.  It
looked like they had some out-of-tree stuff, so in this case I'm fine on
fixing this being their problem.


I didn't see your 2/2 at the time; but wouldn't be surprised if that
needs 1/2, to avoid an error on undeclared node_reclaim_distance before
the optimizer comes into play.  If so, best just to drop 2/2 too.


Ya, definitely.  Sorry for the noise!

Re: [PATCH] RISC-V: Make NUMA depend on SMP

[Palmer Dabbelt]

On Fri, 26 Feb 2021 17:03:53 PST (-0800), wangkefeng.w...@huawei.com wrote:


On 2021/2/27 4:25, Palmer Dabbelt wrote:

From: Palmer Dabbelt 

In theory these are orthogonal, but in practice all NUMA systems are
SMP.  NUMA && !SMP doesn't build, everyone else is coupling them, and I
don't really see any value in supporting that configuration.

Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
Suggested-by: Andrew Morton 
Suggested-by: Atish Patra 
Signed-off-by: Palmer Dabbelt 


Reported-and-Tested-by:  Kefeng Wang 


Ah, thanks, I forged I'd said no to this earlier ;)





---
This is on fixes.
---
  arch/riscv/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a998babc1237..85d626b8ce5e 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -314,6 +314,7 @@ endchoice
  # Common NUMA Features
  config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+   depends on SMP
select GENERIC_ARCH_NUMA
select OF_NUMA
select ARCH_SUPPORTS_NUMA_BALANCING

Re: [PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA

[Palmer Dabbelt]

On Fri, 26 Feb 2021 17:31:40 PST (-0800), hu...@google.com wrote:

On Fri, 26 Feb 2021, Andrew Morton wrote:

On Fri, 26 Feb 2021 12:17:20 -0800 Palmer Dabbelt  wrote:
> From: Palmer Dabbelt 
>
> This is only useful under CONFIG_NUMA.  IIUC skipping the check is the
> right thing to do here, as without CONFIG_NUMA there will never be any
> large node distances on non-NUMA systems.
>
> I expected this to manifest as a link failure under (!CONFIG_NUMA &&
> CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that.  I
> think the reference is just getting pruned before it's checked, but I
> didn't get that from reading the code so I'm worried I'm missing
> something.
>
> Either way, this is necessary to guard the definition of
> node_reclaim_distance with CONFIG_NUMA.
>
> Signed-off-by: Palmer Dabbelt 
> ---
>  mm/khugepaged.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/mm/khugepaged.c b/mm/khugepaged.c
> index a7d6cb912b05..b1bf191c3a54 100644
> --- a/mm/khugepaged.c
> +++ b/mm/khugepaged.c
> @@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid)
>for (i = 0; i < MAX_NUMNODES; i++) {
>if (!khugepaged_node_load[i])
>continue;
> +#ifdef CONFIG_NUMA
>if (node_distance(nid, i) > node_reclaim_distance)
>return true;
> +#endif
>}
>return false;
>  }

This makes the entire loop a no-op.  Perhaps Kirill can help take a
look at removing unnecessary code in khugepaged.c when CONFIG_NUMA=n?


First lines of khugepaged_scan_abort() say
if (!node_reclaim_mode)
return false;

And include/linux/swap.h says
#ifdef CONFIG_NUMA
extern int node_reclaim_mode;
extern int sysctl_min_unmapped_ratio;
extern int sysctl_min_slab_ratio;
#else
#define node_reclaim_mode 0
#endif

So, no need for an #ifdef CONFIG_NUMA inside khugepaged_scan_abort().


Ah, thanks, I hadn't seen that.  That certainly explains the lack of an 
undefined reference.


That said: do we generally rely on DCE to prune references to undefined 
symbols?  This particular one seems like it'd get reliably deleted, but it 
seems like a fragile thing to do in general.  This kind of stuff would 
certainly make some code easier to write, though.


I don't really care all that much, though, as I was just sending this along due 
to some build failure report from a user that I couldn't reproduce.  It looked 
like they had some out-of-tree stuff, so in this case I'm fine on fixing this 
being their problem.

[PATCH] RISC-V: Make NUMA depend on SMP

[Palmer Dabbelt]

From: Palmer Dabbelt 

In theory these are orthogonal, but in practice all NUMA systems are
SMP.  NUMA && !SMP doesn't build, everyone else is coupling them, and I
don't really see any value in supporting that configuration.

Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
Suggested-by: Andrew Morton 
Suggested-by: Atish Patra 
Signed-off-by: Palmer Dabbelt 
---
This is on fixes.
---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index a998babc1237..85d626b8ce5e 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -314,6 +314,7 @@ endchoice
 # Common NUMA Features
 config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+   depends on SMP
select GENERIC_ARCH_NUMA
select OF_NUMA
select ARCH_SUPPORTS_NUMA_BALANCING
-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH 2/2] topology: Guard node_reclaim_distance with CONFIFG_NUMA

[Palmer Dabbelt]

From: Palmer Dabbelt 

This is only defined (and useful) for CONFIG_NUMA, but isn't
conditionally declared.  This makes users a bit more of a headache to
track down.

Signed-off-by: Palmer Dabbelt 
---
 include/linux/topology.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/topology.h b/include/linux/topology.h
index 7634cd737061..15f02281bdf0 100644
--- a/include/linux/topology.h
+++ b/include/linux/topology.h
@@ -73,7 +73,9 @@ int arch_update_cpu_topology(void);
  * *improves* if allowed to reclaim memory and load balance tasks
  * between NUMA nodes 2-hops apart.
  */
+#ifdef CONFIG_NUMA
 extern int __read_mostly node_reclaim_distance;
+#endif
 
 #ifndef PENALTY_FOR_NODE_WITH_CPUS
 #define PENALTY_FOR_NODE_WITH_CPUS (1)
-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH 1/2] mm: Guard a use of node_reclaim_distance with CONFIFG_NUMA

[Palmer Dabbelt]

From: Palmer Dabbelt 

This is only useful under CONFIG_NUMA.  IIUC skipping the check is the
right thing to do here, as without CONFIG_NUMA there will never be any
large node distances on non-NUMA systems.

I expected this to manifest as a link failure under (!CONFIG_NUMA &&
CONFIG_TRANSPARENT_HUGE_PAGES), but I'm not actually seeing that.  I
think the reference is just getting pruned before it's checked, but I
didn't get that from reading the code so I'm worried I'm missing
something.

Either way, this is necessary to guard the definition of
node_reclaim_distance with CONFIG_NUMA.

Signed-off-by: Palmer Dabbelt 
---
 mm/khugepaged.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/khugepaged.c b/mm/khugepaged.c
index a7d6cb912b05..b1bf191c3a54 100644
--- a/mm/khugepaged.c
+++ b/mm/khugepaged.c
@@ -819,8 +819,10 @@ static bool khugepaged_scan_abort(int nid)
for (i = 0; i < MAX_NUMNODES; i++) {
if (!khugepaged_node_load[i])
continue;
+#ifdef CONFIG_NUMA
if (node_distance(nid, i) > node_reclaim_distance)
return true;
+#endif
}
return false;
 }
-- 
2.30.1.766.gb4fecdf3b7-goog

[GIT PULL] RISC-V Patches for the 5.12 Merge Window

[Palmer Dabbelt]

ies
  dt-bindings: add resets property to dw-apb-timer
  riscv: Update Canaan Kendryte K210 device tree
  riscv: Add SiPeed MAIX BiT board device tree
  riscv: Add SiPeed MAIX DOCK board device tree
  riscv: Add SiPeed MAIX GO board device tree
  riscv: Add SiPeed MAIXDUINO board device tree
  riscv: Add Kendryte KD233 board device tree
  riscv: Update Canaan Kendryte K210 defconfig
  riscv: Add Canaan Kendryte K210 SD card defconfig

Eric Lin (2):
  riscv/mm: Introduce a die_kernel_fault() helper function
  riscv/mm: Prevent kernel module to access user memory without uaccess 
routines

Greentime Hu (1):
  riscv: Add support pte_protnone and pmd_protnone if CONFIG_NUMA_BALANCING

Guo Ren (9):
  riscv: Fixup compile error BUILD_BUG_ON failed
  riscv: Fixup wrong ftrace remove cflag
  riscv: Fixup patch_text panic in ftrace
  riscv: Using PATCHABLE_FUNCTION_ENTRY instead of MCOUNT
  riscv: Add kprobes supported
  riscv: Add KPROBES_ON_FTRACE supported
  riscv: Add uprobes supported
  riscv: Add support for function error injection
  riscv: Enable per-task stack canaries

Kefeng Wang (8):
  riscv: Cleanup sbi function stubs when RISCV_SBI disabled
  riscv: Add machine name to kernel boot log and stack dump output
  riscv: Add dump stack in show_regs
  riscv: Improve __show_regs
  initrd: Add the preprocessor guard in initrd.h
  initramfs: Provide a common initrd reserve function
  riscv: Covert to reserve_initrd_mem()
  riscv: Remove unnecessary declaration

Nylon Chen (1):
  riscv/kasan: add KASAN_VMALLOC support

Palmer Dabbelt (2):
  RISC-V: probes: Treat the instruction stream as host-endian
  soc: canaan: Sort the Makefile alphabetically

Patrick Stählin (1):
  RISC-V: Implement ptrace regs and stack API

Randy Dunlap (1):
  arch_numa: fix common code printing of phys_addr_t

Tobias Klauser (1):
  riscv: Disable KSAN_SANITIZE for vDSO

Vitaly Wool (1):
  riscv: add BUILTIN_DTB support for MMU-enabled targets

Yash Shah (8):
  dt-bindings: riscv: Update l2 cache DT documentation to add support for 
SiFive FU740
  RISC-V: sifive_l2_cache: Update L2 cache driver to support SiFive FU740
  dt-bindings: riscv: Update DT binding docs to support SiFive FU740 SoC
  dt-bindings: pwm: Update DT binding docs to support SiFive FU740 SoC
  dt-bindings: gpio: Update DT binding docs to support SiFive FU740 SoC
  riscv: dts: add initial support for the SiFive FU740-C000 SoC
  dt-bindings: riscv: Update YAML doc to support SiFive HiFive Unmatched 
board
  riscv: dts: add initial board data for the SiFive HiFive Unmatched

tangchunyou (1):
  arch/riscv:fix typo in a comment in arch/riscv/kernel/image-vars.h

 .../devicetree/bindings/gpio/sifive,gpio.yaml  |   29 +-
 .../interrupt-controller/sifive,plic-1.0.0.yaml|   13 +-
 .../bindings/mfd/canaan,k210-sysctl.yaml   |  109 +++
 .../bindings/pinctrl/canaan,k210-fpioa.yaml|  171 
 .../devicetree/bindings/pwm/pwm-sifive.yaml|9 +-
 .../devicetree/bindings/reset/canaan,k210-rst.yaml |   40 +
 .../devicetree/bindings/riscv/canaan.yaml  |   47 +
 Documentation/devicetree/bindings/riscv/cpus.yaml  |8 +
 .../devicetree/bindings/riscv/sifive-l2-cache.yaml |   34 +-
 .../devicetree/bindings/riscv/sifive.yaml  |   17 +-
 .../devicetree/bindings/serial/sifive-serial.yaml  |1 +
 .../devicetree/bindings/timer/sifive,clint.yaml|   12 +-
 .../bindings/timer/snps,dw-apb-timer.yaml  |3 +
 MAINTAINERS|   23 +
 arch/arm64/Kconfig |1 +
 arch/arm64/include/asm/numa.h  |   48 +-
 arch/arm64/kernel/acpi_numa.c  |   12 -
 arch/arm64/mm/Makefile |1 -
 arch/arm64/mm/init.c   |4 +-
 arch/riscv/Kconfig |   48 +-
 arch/riscv/Kconfig.socs|   33 +-
 arch/riscv/Makefile|   14 +-
 arch/riscv/boot/dts/Makefile   |2 +-
 arch/riscv/boot/dts/canaan/Makefile|5 +
 arch/riscv/boot/dts/canaan/canaan_kd233.dts|  152 +++
 arch/riscv/boot/dts/canaan/k210.dtsi   |  459 +
 arch/riscv/boot/dts/canaan/k210_generic.dts|   46 +
 arch/riscv/boot/dts/canaan/sipeed_maix_bit.dts |  209 
 arch/riscv/boot/dts/canaan/sipeed_maix_dock.dts|  211 
 arch/riscv/boot/dts/canaan/sipeed_maix_go.dts  |  219 +
 arch/riscv/boot/dts/canaan/sipeed_maixduino.dts|  184 
 arch/riscv/boot/dts/kendryte/Makefile  |4 -
 arch/riscv/boot/dts/kendryte/k210.dts  |   23 -
 arch/riscv/boot/dts/kendryte/k210.dtsi |  125 ---
 arch/riscv/boot/dts/sifive/Makefile|3 +-
 arch/r

Re: [PATCH 2/2] Documentation: features: refresh feature list

[Palmer Dabbelt]

On Thu, 25 Feb 2021 06:27:18 PST (-0800), a...@kernel.org wrote:

From: Arnd Bergmann 

Run the update script to document the recent feature additions
on riscv, mips and csky.

Fixes: c109f42450ec ("csky: Add kmemleak support")
Fixes: 8b3165e54566 ("MIPS: Enable GCOV")
Fixes: 1ddc96bd42da ("MIPS: kernel: Support extracting off-line stack traces from 
user-space with perf")
Fixes: 74784081aac8 ("riscv: Add uprobes supported")
Fixes: 829adda597fe ("riscv: Add KPROBES_ON_FTRACE supported")
Fixes: c22b0bcb1dd0 ("riscv: Add kprobes supported")
Fixes: dcdc7a53a890 ("RISC-V: Implement ptrace regs and stack API")


For the RISC-V stuff

Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

Thanks!


Signed-off-by: Arnd Bergmann 
---
 Documentation/features/debug/gcov-profile-all/arch-support.txt  | 2 +-
 Documentation/features/debug/kmemleak/arch-support.txt  | 2 +-
 Documentation/features/debug/kprobes-on-ftrace/arch-support.txt | 2 +-
 Documentation/features/debug/kprobes/arch-support.txt   | 2 +-
 Documentation/features/debug/kretprobes/arch-support.txt| 2 +-
 Documentation/features/debug/uprobes/arch-support.txt   | 2 +-
 Documentation/features/perf/kprobes-event/arch-support.txt  | 2 +-
 Documentation/features/perf/perf-regs/arch-support.txt  | 2 +-
 Documentation/features/perf/perf-stackdump/arch-support.txt | 2 +-
 Documentation/features/sched/numa-balancing/arch-support.txt| 2 +-
 10 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt 
b/Documentation/features/debug/gcov-profile-all/arch-support.txt
index 416c70345946..b39c1a5de3f3 100644
--- a/Documentation/features/debug/gcov-profile-all/arch-support.txt
+++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt
@@ -16,7 +16,7 @@
 |ia64: | TODO |
 |m68k: | TODO |
 |  microblaze: |  ok  |
-|mips: | TODO |
+|mips: |  ok  |
 |   nds32: | TODO |
 |   nios2: | TODO |
 |openrisc: | TODO |
diff --git a/Documentation/features/debug/kmemleak/arch-support.txt 
b/Documentation/features/debug/kmemleak/arch-support.txt
index 915185634611..e9ac415f8aec 100644
--- a/Documentation/features/debug/kmemleak/arch-support.txt
+++ b/Documentation/features/debug/kmemleak/arch-support.txt
@@ -10,7 +10,7 @@
 | arc: |  ok  |
 | arm: |  ok  |
 |   arm64: |  ok  |
-|csky: | TODO |
+|csky: |  ok  |
 |   h8300: | TODO |
 | hexagon: | TODO |
 |ia64: | TODO |
diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt 
b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
index aade7816cb87..96156e8802a7 100644
--- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
+++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt
@@ -22,7 +22,7 @@
 |openrisc: | TODO |
 |  parisc: |  ok  |
 | powerpc: |  ok  |
-|   riscv: | TODO |
+|   riscv: |  ok  |
 |s390: |  ok  |
 |  sh: | TODO |
 |   sparc: | TODO |
diff --git a/Documentation/features/debug/kprobes/arch-support.txt 
b/Documentation/features/debug/kprobes/arch-support.txt
index 4b663c124d1c..ee95ed61909a 100644
--- a/Documentation/features/debug/kprobes/arch-support.txt
+++ b/Documentation/features/debug/kprobes/arch-support.txt
@@ -22,7 +22,7 @@
 |openrisc: | TODO |
 |  parisc: |  ok  |
 | powerpc: |  ok  |
-|   riscv: | TODO |
+|   riscv: |  ok  |
 |s390: |  ok  |
 |  sh: |  ok  |
 |   sparc: |  ok  |
diff --git a/Documentation/features/debug/kretprobes/arch-support.txt 
b/Documentation/features/debug/kretprobes/arch-support.txt
index 5449bb808442..612cb97d47b8 100644
--- a/Documentation/features/debug/kretprobes/arch-support.txt
+++ b/Documentation/features/debug/kretprobes/arch-support.txt
@@ -22,7 +22,7 @@
 |openrisc: | TODO |
 |  parisc: |  ok  |
 | powerpc: |  ok  |
-|   riscv: | TODO |
+|   riscv: |  ok  |
 |s390: |  ok  |
 |  sh: |  ok  |
 |   sparc: |  ok  |
diff --git a/Documentation/features/debug/uprobes/arch-support.txt 
b/Documentation/features/debug/uprobes/arch-support.txt
index 2820177787e1..8bd5548a4485 100644
--- a/Documentation/features/debug/uprobes/arch-support.txt
+++ b/Documentation/features/debug/uprobes/arch-support.txt
@@ -22,7 +22,7 @@
 |openrisc: | TODO |
 |  parisc: | TODO |
 | powerpc: |  ok  |
-|   riscv: | TODO |
+|   riscv: |  ok  |
 |s390: |  ok  |
 |  sh: | TODO |
 |   sparc: |  ok  |
diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt 
b/Documentation/features/perf/kprobe

Re: [PATCH] riscv: Add KASAN_VMALLOC support

[Palmer Dabbelt]

On Wed, 24 Feb 2021 23:48:13 PST (-0800), a...@ghiti.fr wrote:

Le 2/25/21 à 2:42 AM, Alexandre Ghiti a écrit :

Populate the top-level of the kernel page table to implement KASAN_VMALLOC,
lower levels are filled dynamically upon memory allocation at runtime.

Co-developed-by: Nylon Chen 
Signed-off-by: Nylon Chen 
Co-developed-by: Nick Hu 
Signed-off-by: Nick Hu 
Signed-off-by: Alexandre Ghiti 
---
  arch/riscv/Kconfig |  1 +
  arch/riscv/mm/kasan_init.c | 35 ++-
  2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 8eadd1cbd524..3832a537c5d6 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -57,6 +57,7 @@ config RISCV
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_JUMP_LABEL_RELATIVE
select HAVE_ARCH_KASAN if MMU && 64BIT
+   select HAVE_ARCH_KASAN_VMALLOC if MMU && 64BIT
select HAVE_ARCH_KGDB
select HAVE_ARCH_KGDB_QXFER_PKT
select HAVE_ARCH_MMAP_RND_BITS if MMU
diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 719b6e4d6075..171569df4334 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -142,6 +142,31 @@ static void __init kasan_populate(void *start, void *end)
memset(start, KASAN_SHADOW_INIT, end - start);
  }

+void __init kasan_shallow_populate_pgd(unsigned long vaddr, unsigned long end)
+{
+   unsigned long next;
+   void *p;
+   pgd_t *pgd_k = pgd_offset_k(vaddr);
+
+   do {
+   next = pgd_addr_end(vaddr, end);
+   if (pgd_page_vaddr(*pgd_k) == (unsigned 
long)lm_alias(kasan_early_shadow_pmd)) {
+   p = memblock_alloc(PAGE_SIZE, PAGE_SIZE);
+   set_pgd(pgd_k, pfn_pgd(PFN_DOWN(__pa(p)), PAGE_TABLE));
+   }
+   } while (pgd_k++, vaddr = next, vaddr != end);
+}
+
+void __init kasan_shallow_populate(void *start, void *end)
+{
+   unsigned long vaddr = (unsigned long)start & PAGE_MASK;
+   unsigned long vend = PAGE_ALIGN((unsigned long)end);
+
+   kasan_shallow_populate_pgd(vaddr, vend);
+
+   local_flush_tlb_all();
+}
+
  void __init kasan_init(void)
  {
phys_addr_t _start, _end;
@@ -149,7 +174,15 @@ void __init kasan_init(void)

kasan_populate_early_shadow((void *)KASAN_SHADOW_START,
(void *)kasan_mem_to_shadow((void *)
-   VMALLOC_END));
+   VMEMMAP_END));
+   if (IS_ENABLED(CONFIG_KASAN_VMALLOC))
+   kasan_shallow_populate(
+   (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+   (void *)kasan_mem_to_shadow((void *)VMALLOC_END));
+   else
+   kasan_populate_early_shadow(
+   (void *)kasan_mem_to_shadow((void *)VMALLOC_START),
+   (void *)kasan_mem_to_shadow((void *)VMALLOC_END));

for_each_mem_range(i, &_start, &_end) {
void *start = (void *)_start;



Palmer, this commit should replace (if everyone agrees) Nylon and Nick's
Commit e178d670f251 ("riscv/kasan: add KASAN_VMALLOC support") that is
already in for-next.


Sorry, but it's way too late to be rebasing things.  I can get trying to have
the history clean, but in this case we're better off having this as an explicit
fix patch -- changing hashes this late in the process messes with all the
testing.

I'm not sure what the issue actually is, so it'd be great if you could send the
fix patch.  If not then LMK and I'll try to figure out what's going on.  Either
way, having the fix will make sure this gets tested properly as whatever's
going on isn't failing for me.

Re: [PATCH] soc: canaan: Sort the Makefile alphabetically

[Palmer Dabbelt]

On Mon, 22 Feb 2021 18:31:43 PST (-0800), Damien Le Moal wrote:

On 2021/02/23 11:19, Palmer Dabbelt wrote:
From: Palmer Dabbelt 

The rest of these are alphabetically sorted, and leaving it this way
causes a merge conflict.

Signed-off-by: Palmer Dabbelt 

---

I missed this when reviewing these patches, but happened across it when
test merging from Linus' tree.  It goes back a way so I'm hesitant to
rebase this one out just for cleanliness, but if I have to go back that
far before sending the merge window PR I'll squash it in.
---
 drivers/soc/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index fa7071246546..34b23645be14 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_ACTIONS)  += actions/
 obj-y  += aspeed/
 obj-$(CONFIG_ARCH_AT91)+= atmel/
 obj-y  += bcm/
+obj-$(CONFIG_SOC_CANAAN)   += canaan/
 obj-$(CONFIG_ARCH_DOVE)+= dove/
 obj-$(CONFIG_MACH_DOVE)+= dove/
 obj-y  += fsl/
@@ -29,4 +30,3 @@ obj-$(CONFIG_ARCH_U8500)  += ux500/
 obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
 obj-y  += xilinx/
 obj-$(CONFIG_ARCH_ZX)  += zte/
-obj-$(CONFIG_SOC_CANAAN)   += canaan/


Yes. Should have sent that... Thanks.

Reviewed-by: Damien Le Moal 


No problem, it's on for-next.

Re: [PATCH 0/4] Kasan improvements and fixes

[Palmer Dabbelt]

On Sun, 21 Feb 2021 05:42:08 PST (-0800), a...@ghiti.fr wrote:

Hi,

Le 2/8/21 à 2:30 PM, Alexandre Ghiti a écrit :

This small series contains some improvements for the riscv KASAN code:

- it brings a better readability of the code (patch 1/2)
- it fixes oversight regarding page table population which I uncovered
   while working on my sv48 patchset (patch 3)
- it helps to have better performance by using hugepages when possible
   (patch 4)

Alexandre Ghiti (4):
   riscv: Improve kasan definitions
   riscv: Use KASAN_SHADOW_INIT define for kasan memory initialization
   riscv: Improve kasan population function
   riscv: Improve kasan population by using hugepages when possible

  arch/riscv/include/asm/kasan.h |  22 +-
  arch/riscv/mm/kasan_init.c | 119 -
  2 files changed, 108 insertions(+), 33 deletions(-)



I'm cc-ing linux-arch and linux-mm to get more chance to have reviewers
on this series.


Sorry about that, I must have missed these.  For some reason I remember having
read the big one, so I'm not sure what happened.  They're on for-next.

Thanks!

Re: [PATCH] riscv: Pass virtual addresses to kasan_mem_to_shadow

[Palmer Dabbelt]

On Mon, 22 Feb 2021 00:07:34 PST (-0800), a...@ghiti.fr wrote:

kasan_mem_to_shadow translates virtual addresses to kasan shadow
addresses whereas for_each_mem_range returns physical addresses: it is
then required to use __va on those addresses before passing them to
kasan_mem_to_shadow.

Fixes: b10d6bca8720 ("arch, drivers: replace for_each_membock() with 
for_each_mem_range()")
Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/mm/kasan_init.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index 4b9149f963d3..6d3b88f2c566 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -148,8 +148,8 @@ void __init kasan_init(void)
(void *)kasan_mem_to_shadow((void *)VMALLOC_END));

for_each_mem_range(i, &_start, &_end) {
-   void *start = (void *)_start;
-   void *end = (void *)_end;
+   void *start = (void *)__va(_start);
+   void *end = (void *)__va(_end);

if (start >= end)
break;


Thanks, but unless I'm missing something this is already in Linus' tree as
c25a053e1577 ("riscv: Fix KASAN memory mapping.").

[PATCH] soc: canaan: Sort the Makefile alphabetically

[Palmer Dabbelt]

From: Palmer Dabbelt 

The rest of these are alphabetically sorted, and leaving it this way
causes a merge conflict.

Signed-off-by: Palmer Dabbelt 

---

I missed this when reviewing these patches, but happened across it when
test merging from Linus' tree.  It goes back a way so I'm hesitant to
rebase this one out just for cleanliness, but if I have to go back that
far before sending the merge window PR I'll squash it in.
---
 drivers/soc/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index fa7071246546..34b23645be14 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_ARCH_ACTIONS)  += actions/
 obj-y  += aspeed/
 obj-$(CONFIG_ARCH_AT91)+= atmel/
 obj-y  += bcm/
+obj-$(CONFIG_SOC_CANAAN)   += canaan/
 obj-$(CONFIG_ARCH_DOVE)+= dove/
 obj-$(CONFIG_MACH_DOVE)+= dove/
 obj-y  += fsl/
@@ -29,4 +30,3 @@ obj-$(CONFIG_ARCH_U8500)  += ux500/
 obj-$(CONFIG_PLAT_VERSATILE)   += versatile/
 obj-y  += xilinx/
 obj-$(CONFIG_ARCH_ZX)  += zte/
-obj-$(CONFIG_SOC_CANAAN)   += canaan/
-- 
2.30.0.617.g56c4b15f3c-goog

Re: [PATCH] RISC-V: Add a non-void return for sbi v02 functions

[Palmer Dabbelt]

On Mon, 22 Feb 2021 14:38:28 PST (-0800), ati...@atishpatra.org wrote:

On Mon, Feb 22, 2021 at 12:23 PM Guenter Roeck  wrote:


On Wed, Feb 03, 2021 at 09:26:43PM -0800, Atish Patra wrote:
> SBI v0.2 functions can return an error code from SBI implementation.
> We are already processing the SBI error code and coverts it to the Linux
> error code.
>
> Propagate to the error code to the caller as well. As of now, kvm is the
> only user of these error codes.
>
> Signed-off-by: Atish Patra 
> ---
...
>  #else /* CONFIG_RISCV_SBI */
> -static inline void sbi_remote_fence_i(const unsigned long *hart_mask) {}
> +static inline int sbi_remote_fence_i(const unsigned long *hart_mask) {}

Error log:
In file included from arch/riscv/kernel/setup.c:29:
arch/riscv/include/asm/sbi.h: In function 'sbi_remote_fence_i':
arch/riscv/include/asm/sbi.h:150:1: error: no return statement in function 
returning non-void



Sorry for the oversight. The return statement is missing.

@Palmer Dabbelt : Can you fix it in for-next or should I send a v2 ?


I just fixed it up.

Re: riscv+KASAN does not boot

[Palmer Dabbelt]

On Fri, 19 Feb 2021 10:53:43 PST (-0800), dvyu...@google.com wrote:

On Fri, Feb 19, 2021 at 6:01 PM Alex Ghiti  wrote:


Hi Dmitry,

Le 2/18/21 à 6:36 AM, Dmitry Vyukov a écrit :
> On Thu, Feb 18, 2021 at 8:54 AM Alex Ghiti  wrote:
>>
>> Hi Dmitry,
>>
>>> On Wed, Feb 17, 2021 at 5:36 PM Alex Ghiti  wrote:

 Le 2/16/21 à 11:42 PM, Dmitry Vyukov a écrit :
> On Tue, Feb 16, 2021 at 9:42 PM Alex Ghiti  wrote:
>>
>> Hi Dmitry,
>>
>> Le 2/16/21 à 6:25 AM, Dmitry Vyukov a écrit :
>>> On Tue, Feb 16, 2021 at 12:17 PM Dmitry Vyukov  
wrote:

 On Fri, Jan 29, 2021 at 9:11 AM Dmitry Vyukov  
wrote:
>> I was fixing KASAN support for my sv48 patchset so I took a look at 
your
>> issue: I built a kernel on top of the branch riscv/fixes using
>> 
https://github.com/google/syzkaller/blob/269d24e857a757d09a898086a2fa6fa5d827c3e1/dashboard/config/linux/upstream-riscv64-kasan.config
>> and Buildroot 2020.11. I have the warnings regarding the use of
>> __virt_to_phys on wrong addresses (but that's normal since this 
function
>> is used in virt_addr_valid) but not the segfaults you describe.
>
> Hi Alex,
>
> Let me try to rebuild buildroot image. Maybe there was something wrong
> with my build, though, I did 'make clean' before doing. But at the
> same time it worked back in June...
>
> Re WARNINGs, they indicate kernel bugs. I am working on setting up a
> syzbot instance on riscv. If there a WARNING during boot then the
> kernel will be marked as broken. No further testing will happen.
> Is it a mis-use of WARN_ON? If so, could anybody please remove it or
> replace it with pr_err.


 Hi,

 I've localized one issue with riscv/KASAN:
 KASAN breaks VDSO and that's I think the root cause of weird faults I
 saw earlier. The following patch fixes it.
 Could somebody please upstream this fix? I don't know how to add/run
 tests for this.
 Thanks

 diff --git a/arch/riscv/kernel/vdso/Makefile 
b/arch/riscv/kernel/vdso/Makefile
 index 0cfd6da784f84..cf3a383c1799d 100644
 --- a/arch/riscv/kernel/vdso/Makefile
 +++ b/arch/riscv/kernel/vdso/Makefile
 @@ -35,6 +35,7 @@ CFLAGS_REMOVE_vgettimeofday.o = $(CC_FLAGS_FTRACE) 
-Os
  # Disable gcov profiling for VDSO code
  GCOV_PROFILE := n
  KCOV_INSTRUMENT := n
 +KASAN_SANITIZE := n

  # Force dependency
  $(obj)/vdso.o: $(obj)/vdso.so
>>
>> What's weird is that I don't have any issue without this patch with the
>> following config whereas it indeed seems required for KASAN. But when
>> looking at the segfaults you got earlier, the segfault address is 0xbb0
>> and the cause is an instruction page fault: this address is the PLT base
>> address in vdso.so and an instruction page fault would mean that someone
>> tried to jump at this address, which is weird. At first sight, that does
>> not seem related to your patch above, but clearly I may be wrong.
>>
>> Tobias, did you observe the same segfaults as Dmitry ?
>
>
> I noticed that not all buildroot images use VDSO, it seems to be
> dependent on libc settings (at least I think I changed it in the
> past).

 Ok, I used uClibc but then when using glibc, I have the same segfaults,
 only when KASAN is enabled. And your patch fixes the problem. I will try
 to take a look later to better understand the problem.

> I also booted an image completely successfully including dhcpd/sshd
> start, but then my executable crashed in clock_gettime. The executable
> was build on linux/amd64 host with "riscv64-linux-gnu-gcc -static"
> (10.2.1).
>
>
>>> Second issue I am seeing seems to be related to text segment size.
>>> I check out v5.11 and use this config:
>>> https://gist.github.com/dvyukov/6af25474d455437577a84213b0cc9178
>>
>> This config gave my laptop a hard time ! Finally I was able to boot
>> correctly to userspace, but I realized I used my sv48 branch...Either I
>> fixed your issue along the way or I can't reproduce it, I'll give it a
>> try tomorrow.
>
> Where is your branch? I could also test in my setup on your branch.
>

 You can find my branch int/alex/riscv_kernel_end_of_address_space_v2
 here: https://github.com/AlexGhiti/riscv-linux.git
>>>
>>> No, it does not work for me.
>>>
>>> Source is on b61ab6c98de021398cd7734ea5fc3655e51e70f2 (HEAD,
>>> int/alex/riscv_kernel_end_of_address_space_v2)
>>> Config is 
https://gist.githubusercontent.com/dvyukov/6af25474d455437577a84213b0cc9178/raw/55b116522c14a8a98a7626d76df740d54f648ce5/gistfile1.txt
>>>
>>> riscv64-linux-gnu-gcc -v
>>> gcc version 10.2.1 202101

Re: [PATCH] RISC-V: Enable CPU Hotplug in defconfigs

[Palmer Dabbelt]

On Mon, 08 Feb 2021 21:46:20 PST (-0800), Anup Patel wrote:

The CPU hotplug support has been tested on QEMU, Spike, and SiFive
Unleashed so let's enable it by default in RV32 and RV64 defconfigs.

Signed-off-by: Anup Patel 
---
 arch/riscv/configs/defconfig  | 1 +
 arch/riscv/configs/rv32_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
index 8c3d1e451703..6c0625aa96c7 100644
--- a/arch/riscv/configs/defconfig
+++ b/arch/riscv/configs/defconfig
@@ -17,6 +17,7 @@ CONFIG_BPF_SYSCALL=y
 CONFIG_SOC_SIFIVE=y
 CONFIG_SOC_VIRT=y
 CONFIG_SMP=y
+CONFIG_HOTPLUG_CPU=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y
diff --git a/arch/riscv/configs/rv32_defconfig 
b/arch/riscv/configs/rv32_defconfig
index 2c2cda6cc1c5..8dd02b842fef 100644
--- a/arch/riscv/configs/rv32_defconfig
+++ b/arch/riscv/configs/rv32_defconfig
@@ -18,6 +18,7 @@ CONFIG_SOC_SIFIVE=y
 CONFIG_SOC_VIRT=y
 CONFIG_ARCH_RV32I=y
 CONFIG_SMP=y
+CONFIG_HOTPLUG_CPU=y
 CONFIG_JUMP_LABEL=y
 CONFIG_MODULES=y
 CONFIG_MODULE_UNLOAD=y


Thanks, this is on for-next.

Re: [PATCH] Revert "dts: phy: add GPIO number and active state used for phy reset"

[Palmer Dabbelt]

On Wed, 10 Feb 2021 04:47:34 PST (-0800), sch...@linux-m68k.org wrote:

On Feb 04 2021, Palmer Dabbelt wrote:


From: Palmer Dabbelt 

VSC8541 phys need a special reset sequence, which the driver doesn't
currentlny support.  As a result enabling the reset via GPIO essentially
guarnteees that the device won't work correctly.

This reverts commit a0fa9d727043da2238432471e85de0bdb8a8df65.

Fixes: a0fa9d727043 ("dts: phy: add GPIO number and active state used for phy 
reset")
Cc: sta...@vger.kernel.org
Signed-off-by: Palmer Dabbelt 


This fixes ethernet on the HiFive Unleashed with 5.10.12.


Thanks for testing.  Looks like I forgot to reply, but it's in Linus' tree and 
should end up in stable.

[GIT PULL] A Single RISC-V Fix for 5.11-rc8 (or 5.11)

[Palmer Dabbelt]

The following changes since commit 92bf22614b21a2706f4993b278017e437f7785b3:

  Linux 5.11-rc7 (2021-02-07 13:57:38 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.11-rc8

for you to fetch changes up to 3da3cc1b5f47115b16b5ffeeb4bf09ec331b0164:

  Revert "dts: phy: add GPIO number and active state used for phy reset" 
(2021-02-10 16:06:14 -0800)


A Single RISC-V Fix for 5.11-rc8 (or 5.11)

I have a single fix this week:

* The removal of the GPIO reset method for the Ethernet phy on the
  HiFive Unleashed.  This returns to relying on the bootloader's phy
  reset sequence, which we'll have to cintune doing until we can sort
  out how to get the Linux phy driver to perform the special reset
  dance required for this phy.

--------
Palmer Dabbelt (1):
  Revert "dts: phy: add GPIO number and active state used for phy reset"

 arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 -
 1 file changed, 1 deletion(-)

Re: [PATCH] selftests/vDSO: fix ABI selftest on riscv

[Palmer Dabbelt]

On Mon, 08 Feb 2021 15:37:24 PST (-0800), sk...@linuxfoundation.org wrote:

On 2/5/21 12:57 AM, Tobias Klauser wrote:

On 2021-02-05 at 08:06:37 +0100, Palmer Dabbelt  wrote:

On Thu, 04 Feb 2021 06:50:42 PST (-0800), tklau...@distanz.ch wrote:


[...]


Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 


Thank you!


Not sure if you want this through the RISC-V tree, so I'm leaving it out for
now and assuming it'll go through a kselftest tree.


Either way is fine for me.



Thank you. Applied to linux-kselftest next for 5.12-rc1


Thanks!

[GIT PULL] RISC-V Fixes for 5.11-rc7

[Palmer Dabbelt]

The following changes since commit 1048ba83fb1c00cd24172e23e8263972f6b5d9ac:

  Linux 5.11-rc6 (2021-01-31 13:50:09 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.11-rc7

for you to fetch changes up to de5f4b8f634beacf667e6eff334522601dd03b59:

  RISC-V: Define MAXPHYSMEM_1GB only for RV32 (2021-02-02 18:36:42 -0800)


RISC-V Fixes for 5.11-rc7

I have a handful of fixes for this week:

* A fix to avoid evalating the VA twice in virt_addr_valid, which fixes
  some WARNs under DEBUG_VIRTUAL.
* Two fixes related to STRICT_KERNEL_RWX: one that fixes some
  permissions when strict is disabled, and one to fix some alignment
  issues when strict is enabled.
* A fix to disallow the selection of MAXPHYSMEM_2GB on RV32, which isn't
  valid any more but may still show up in some oldconfigs.

We still have the HiFive Unleashed ethernet phy reset regression, so
there will likely be something coming next week.


Alexandre Ghiti (1):
  riscv: virt_addr_valid must check the address belongs to linear mapping

Atish Patra (2):
  RISC-V: Fix .init section permission update
  RISC-V: Define MAXPHYSMEM_1GB only for RV32

Sebastien Van Cauwenberghe (1):
  riscv: Align on L1_CACHE_BYTES when STRICT_KERNEL_RWX

 arch/riscv/Kconfig  | 2 ++
 arch/riscv/include/asm/page.h   | 5 -
 arch/riscv/include/asm/set_memory.h | 6 +++---
 arch/riscv/kernel/setup.c   | 4 +++-
 4 files changed, 12 insertions(+), 5 deletions(-)

Re: [PATCH] RISC-V: Add a non-void return for sbi v02 functions

[Palmer Dabbelt]

On Wed, 03 Feb 2021 21:26:43 PST (-0800), Atish Patra wrote:

SBI v0.2 functions can return an error code from SBI implementation.
We are already processing the SBI error code and coverts it to the Linux
error code.

Propagate to the error code to the caller as well. As of now, kvm is the
only user of these error codes.

Signed-off-by: Atish Patra 
---
 arch/riscv/include/asm/sbi.h | 10 +-
 arch/riscv/kernel/sbi.c  | 32 
 2 files changed, 21 insertions(+), 21 deletions(-)

diff --git a/arch/riscv/include/asm/sbi.h b/arch/riscv/include/asm/sbi.h
index 1b26ec8e6a15..3e7141a7d11f 100644
--- a/arch/riscv/include/asm/sbi.h
+++ b/arch/riscv/include/asm/sbi.h
@@ -116,13 +116,13 @@ int sbi_console_getchar(void);
 void sbi_set_timer(uint64_t stime_value);
 void sbi_shutdown(void);
 void sbi_clear_ipi(void);
-void sbi_send_ipi(const unsigned long *hart_mask);
-void sbi_remote_fence_i(const unsigned long *hart_mask);
-void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+int sbi_send_ipi(const unsigned long *hart_mask);
+int sbi_remote_fence_i(const unsigned long *hart_mask);
+int sbi_remote_sfence_vma(const unsigned long *hart_mask,
   unsigned long start,
   unsigned long size);

-void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid);
@@ -163,7 +163,7 @@ static inline unsigned long sbi_minor_version(void)

 int sbi_err_map_linux_errno(int err);
 #else /* CONFIG_RISCV_SBI */
-static inline void sbi_remote_fence_i(const unsigned long *hart_mask) {}
+static inline int sbi_remote_fence_i(const unsigned long *hart_mask) {}
 static inline void sbi_init(void) {}
 #endif /* CONFIG_RISCV_SBI */
 #endif /* _ASM_RISCV_SBI_H */
diff --git a/arch/riscv/kernel/sbi.c b/arch/riscv/kernel/sbi.c
index 8d60b2ebcad3..f904af48635d 100644
--- a/arch/riscv/kernel/sbi.c
+++ b/arch/riscv/kernel/sbi.c
@@ -352,7 +352,7 @@ static int __sbi_rfence_v02(int fid, const unsigned long 
*hart_mask,
  * sbi_set_timer() - Program the timer for next timer event.
  * @stime_value: The value after which next timer event should fire.
  *
- * Return: None
+ * Return: None.
  */
 void sbi_set_timer(uint64_t stime_value)
 {
@@ -363,11 +363,11 @@ void sbi_set_timer(uint64_t stime_value)
  * sbi_send_ipi() - Send an IPI to any hart.
  * @hart_mask: A cpu mask containing all the target harts.
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_send_ipi(const unsigned long *hart_mask)
+int sbi_send_ipi(const unsigned long *hart_mask)
 {
-   __sbi_send_ipi(hart_mask);
+   return __sbi_send_ipi(hart_mask);
 }
 EXPORT_SYMBOL(sbi_send_ipi);

@@ -375,12 +375,12 @@ EXPORT_SYMBOL(sbi_send_ipi);
  * sbi_remote_fence_i() - Execute FENCE.I instruction on given remote harts.
  * @hart_mask: A cpu mask containing all the target harts.
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_remote_fence_i(const unsigned long *hart_mask)
+int sbi_remote_fence_i(const unsigned long *hart_mask)
 {
-   __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
-hart_mask, 0, 0, 0, 0);
+   return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_FENCE_I,
+   hart_mask, 0, 0, 0, 0);
 }
 EXPORT_SYMBOL(sbi_remote_fence_i);

@@ -391,14 +391,14 @@ EXPORT_SYMBOL(sbi_remote_fence_i);
  * @start: Start of the virtual address
  * @size: Total size of the virtual address range.
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_remote_sfence_vma(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma(const unsigned long *hart_mask,
   unsigned long start,
   unsigned long size)
 {
-   __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
-hart_mask, start, size, 0, 0);
+   return __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA,
+   hart_mask, start, size, 0, 0);
 }
 EXPORT_SYMBOL(sbi_remote_sfence_vma);

@@ -411,15 +411,15 @@ EXPORT_SYMBOL(sbi_remote_sfence_vma);
  * @size: Total size of the virtual address range.
  * @asid: The value of address space identifier (ASID).
  *
- * Return: None
+ * Return: 0 on success, appropriate linux error code otherwise.
  */
-void sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
+int sbi_remote_sfence_vma_asid(const unsigned long *hart_mask,
unsigned long start,
unsigned long size,
unsigned long asid)
 {
-   __sbi_rfence(SBI_EXT_RFENCE_REMOTE_SFENCE_VMA_ASID,
-hart_mask, start, size, asid, 0);
+   return __sbi_rfence(SBI_EXT_RFENCE_R

Re: [PATCH] selftests/vDSO: fix ABI selftest on riscv

[Palmer Dabbelt]

On Thu, 04 Feb 2021 06:50:42 PST (-0800), tklau...@distanz.ch wrote:

Only older versions of the RISC-V GCC toolchain define __riscv__. Check
for __riscv as well, which is used by newer GCC toolchains. Also set
VDSO_32BIT based on __riscv_xlen.

Before (on riscv64):

$ ./vdso_test_abi
[vDSO kselftest] VDSO_VERSION: LINUX_4
Could not find __vdso_gettimeofday
Could not find __vdso_clock_gettime
Could not find __vdso_clock_getres
clock_id: CLOCK_REALTIME [PASS]
Could not find __vdso_clock_gettime
Could not find __vdso_clock_getres
clock_id: CLOCK_BOOTTIME [PASS]
Could not find __vdso_clock_gettime
Could not find __vdso_clock_getres
clock_id: CLOCK_TAI [PASS]
Could not find __vdso_clock_gettime
Could not find __vdso_clock_getres
clock_id: CLOCK_REALTIME_COARSE [PASS]
Could not find __vdso_clock_gettime
Could not find __vdso_clock_getres
clock_id: CLOCK_MONOTONIC [PASS]
Could not find __vdso_clock_gettime
Could not find __vdso_clock_getres
clock_id: CLOCK_MONOTONIC_RAW [PASS]
Could not find __vdso_clock_gettime
Could not find __vdso_clock_getres
clock_id: CLOCK_MONOTONIC_COARSE [PASS]
Could not find __vdso_time

After (on riscv32):

$ ./vdso_test_abi
[vDSO kselftest] VDSO_VERSION: LINUX_4.15
The time is 1612449376.015086
The time is 1612449376.18340784
The resolution is 0 1
clock_id: CLOCK_REALTIME [PASS]
The time is 774.842586182
The resolution is 0 1
clock_id: CLOCK_BOOTTIME [PASS]
The time is 1612449376.22536565
The resolution is 0 1
clock_id: CLOCK_TAI [PASS]
The time is 1612449376.20885172
The resolution is 0 400
clock_id: CLOCK_REALTIME_COARSE [PASS]
The time is 774.845491269
The resolution is 0 1
clock_id: CLOCK_MONOTONIC [PASS]
The time is 774.849534200
The resolution is 0 1
clock_id: CLOCK_MONOTONIC_RAW [PASS]
The time is 774.842139684
The resolution is 0 400
clock_id: CLOCK_MONOTONIC_COARSE [PASS]
Could not find __vdso_time

Signed-off-by: Tobias Klauser 
---
 tools/testing/selftests/vDSO/vdso_config.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/vDSO/vdso_config.h 
b/tools/testing/selftests/vDSO/vdso_config.h
index 6a6fe8d4ff55..6188b16827d1 100644
--- a/tools/testing/selftests/vDSO/vdso_config.h
+++ b/tools/testing/selftests/vDSO/vdso_config.h
@@ -47,10 +47,12 @@
 #elif defined(__x86_64__)
 #define VDSO_VERSION   0
 #define VDSO_NAMES 1
-#elif defined(__riscv__)
+#elif defined(__riscv__) || defined(__riscv)
 #define VDSO_VERSION   5
 #define VDSO_NAMES 1
+#if __riscv_xlen == 32
 #define VDSO_32BIT 1
+#endif
 #else /* nds32 */
 #define VDSO_VERSION   4
 #define VDSO_NAMES 1


Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

Not sure if you want this through the RISC-V tree, so I'm leaving it out for
now and assuming it'll go through a kselftest tree.

Thanks!

Re: [PATCH -next] RISCV: Add some depends for NUMA

[Palmer Dabbelt]

On Wed, 03 Feb 2021 06:23:43 PST (-0800), wangkefeng.w...@huawei.com wrote:

The numa feature is useless for riscv32 platform(MAXPHYSMEM_1GB if 32bit),


I'm not convinced of that.  There's no reason NUMA shouldn't work on 32-bit, it
doesn't depend on having a large amount of memory just having non-uniform
memory.  I could buy the argument that build a 32-bit NUMA system would be
wacky, but IIUC it works now and I don't see any reason to throw that away.


and it should depends on SMP feature, this also fix the build error,


I can buy that CONFIG_NUMA doesn't really make sense without CONFIG_SMP, as
there's not a whole lot to do, but I also don't see any reason from disallowing
users from picking it.  arm64 allows !SMP && NUMA, and I don't see any reason
it wouldn't work just as well for us.


  riscv64-buildroot-linux-gnu-ld: mm/page_alloc.o: in function `.L0 ':
  page_alloc.c:(.text+0x4808): undefined reference to `node_reclaim_distance'


The only instance of node_reclaim_distance I see in mm/page_alloc.c is already
guarded with CONFIG_NUMA, but the definition of node_reclaim_distance isn't.
I'll send out some patches to add the guard which might make sorting this out
earlier, but I don't see it fixing any failures.


Fixes: 4f0e8eef772e ("riscv: Add numa support for riscv64 platform")
Signed-off-by: Kefeng Wang 
---
 arch/riscv/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 22fa17898d29..ac7f5801bd82 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -312,6 +312,8 @@ endchoice
 # Common NUMA Features
 config NUMA
bool "NUMA Memory Allocation and Scheduler Support"
+   depends on SMP
+   depends on 64BIT
select GENERIC_ARCH_NUMA
select OF_NUMA
select ARCH_SUPPORTS_NUMA_BALANCING

Re: [PATCH v5] RISC-V: Implement ASID allocator

[Palmer Dabbelt]

On Wed, 03 Feb 2021 01:49:07 PST (-0800), Anup Patel wrote:

Currently, we do local TLB flush on every MM switch. This is very harsh on
performance because we are forcing page table walks after every MM switch.

This patch implements ASID allocator for assigning an ASID to a MM context.
The number of ASIDs are limited in HW so we create a logical entity named
CONTEXTID for assigning to MM context. The lower bits of CONTEXTID are ASID
and upper bits are VERSION number. The number of usable ASID bits supported
by HW are detected at boot-time by writing 1s to ASID bits in SATP CSR.

We allocate new CONTEXTID on first MM switch for a MM context where the
ASID is allocated from an ASID bitmap and VERSION is provide by an atomic
counter. At time of allocating new CONTEXTID, if we run out of available
ASIDs then:
1. We flush the ASID bitmap
2. Increment current VERSION atomic counter
3. Re-allocate ASID from ASID bitmap
4. Flush TLB on all CPUs
5. Try CONTEXTID re-assignment on all CPUs

Please note that we don't use ASID #0 because it is used at boot-time by
all CPUs for initial MM context. Also, newly created context is always
assigned CONTEXTID #0 (i.e. VERSION #0 and ASID #0) which is an invalid
context in our implementation.

Using above approach, we have virtually infinite CONTEXTIDs on-top-of
limited number of HW ASIDs. This approach is inspired from ASID allocator
used for Linux ARM/ARM64 but we have adapted it for RISC-V. Overall, this
ASID allocator helps us reduce rate of local TLB flushes on every CPU
thereby increasing performance.

This patch is tested on QEMU virt machine, Spike and SiFive Unleashed
board. On QEMU virt machine, we see some (3-5% approx) performance
improvement with SW emulated TLBs provided by QEMU. Unfortunately,
the ASID bits of the SATP CSR are not implemented on Spike and SiFive
Unleashed board so we don't see any change in performance. On real HW
having all ASID bits implemented, the performance gains will be much
more due improved sharing of TLB among different processes.

Signed-off-by: Anup Patel 
Reviewed-by: Palmer Dabbelt 
---
Changes since v4:
- Rebased on Linux-5.11-rc6
- Used lockdep_assert_held() in __new_context() and __flush_context()

Changes since v3:
- Rebased on Linux-5.11-rc4. The previous v3 patch (almost 2 years back)
  was based on Linux-5.1-rc2
- Updated implementation to consider NoMMU kernel
- Converted use_asid_allocator boolean flag into static key
- Improved boot-time print in asids_init() to show number of ASID bits
- Access SATP CSR by number instead of old CSR name "sptbr"

Changes since v2:
- Move to lazy TLB flushing because we get slow path warnings if we
  use flush_tlb_all()
- Don't set ASID bits to all 1s in head.s. Instead just do it on
  boot CPU calling asids_init() for determining number of HW ASID bits
- Make CONTEXT version comparison more readable in set_mm_asid()
- Fix typo in __flush_context()

Changes since v1:
- We adapt good aspects from Gary Guo's ASID allocator implementation
  and provide due credit to him by adding his SoB.
- Track ASIDs active during context flush and mark them as reserved
- Set ASID bits to all 1s to simplify number of ASID bit detection
- Use atomic_long_t instead of atomic64_t for being 32bit friendly
- Use unsigned long instead of u64 for being 32bit friendly
- Use flush_tlb_all() instead of lazy local_tlb_flush_all() at time
  of context flush

This patch is based on Linux-5.11-rc6 and can be found in the
riscv_asid_allocator_v5 branch of https://github.com/avpatel/linux.git
---
 arch/riscv/include/asm/csr.h |   6 +
 arch/riscv/include/asm/mmu.h |   2 +
 arch/riscv/include/asm/mmu_context.h |  10 +
 arch/riscv/mm/context.c  | 265 ++-
 4 files changed, 279 insertions(+), 4 deletions(-)

diff --git a/arch/riscv/include/asm/csr.h b/arch/riscv/include/asm/csr.h
index cec462e198ce..caadfc1d7487 100644
--- a/arch/riscv/include/asm/csr.h
+++ b/arch/riscv/include/asm/csr.h
@@ -41,10 +41,16 @@
 #define SATP_PPN   _AC(0x003F, UL)
 #define SATP_MODE_32   _AC(0x8000, UL)
 #define SATP_MODE  SATP_MODE_32
+#define SATP_ASID_BITS 9
+#define SATP_ASID_SHIFT22
+#define SATP_ASID_MASK _AC(0x1FF, UL)
 #else
 #define SATP_PPN   _AC(0x0FFF, UL)
 #define SATP_MODE_39   _AC(0x8000, UL)
 #define SATP_MODE  SATP_MODE_39
+#define SATP_ASID_BITS 16
+#define SATP_ASID_SHIFT44
+#define SATP_ASID_MASK _AC(0x, UL)
 #endif

 /* Exception cause high bit - is an interrupt if set */
diff --git a/arch/riscv/include/asm/mmu.h b/arch/riscv/include/asm/mmu.h
index dabcf2cfb3dc..0099dc116168 100644
--- a/arch/riscv/include/asm/mmu.h
+++ b/arch/riscv/include/asm/mmu.h
@@ -12,6 +12,8 @@
 typedef struct {
 #ifndef CONFIG_MMU
unsigned long   end_brk;
+#else
+   atomic_long_t id;
 #endif
void *vdso;
 #ifdef CONFIG_SMP
diff --git a/arch/riscv/include/asm/mmu_context.h 
b/arch/r

[PATCH] Revert "dts: phy: add GPIO number and active state used for phy reset"

[Palmer Dabbelt]

From: Palmer Dabbelt 

VSC8541 phys need a special reset sequence, which the driver doesn't
currentlny support.  As a result enabling the reset via GPIO essentially
guarnteees that the device won't work correctly.

This reverts commit a0fa9d727043da2238432471e85de0bdb8a8df65.

Fixes: a0fa9d727043 ("dts: phy: add GPIO number and active state used for phy 
reset")
Cc: sta...@vger.kernel.org
Signed-off-by: Palmer Dabbelt 
---
 arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts 
b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
index 24d75a146e02..60846e88ae4b 100644
--- a/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
+++ b/arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts
@@ -90,7 +90,6 @@ ð0 {
phy0: ethernet-phy@0 {
compatible = "ethernet-phy-id0007.0771";
reg = <0>;
-   reset-gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
};
 };
 
-- 
2.30.0.478.g8a0d178c01-goog

Re: [PATCH v2 0/3] fix macb phy probe failure if phy-reset is not handled

[Palmer Dabbelt]

On Thu, 04 Feb 2021 02:16:54 PST (-0800), sch...@linux-m68k.org wrote:

On Jan 13 2021, Palmer Dabbelt wrote:


On Tue, 10 Nov 2020 07:22:09 PST (-0800), sagar.ka...@sifive.com wrote:

HiFive Unleashed is having VSC8541-01 ethernet phy device and requires a
specific reset sequence of 0-1-0-1 in order to use it in unmanaged mode.
This series addresses a corner case where phy reset is not handled by boot
stages prior to linux.
Somewhat similar unreliable phy probe failure was reported and discussed
here [1].
The macb driver fails to detect the ethernet phy device if the bootloader
doesn't provide a proper reset sequence to the phy device or the phy itself
is in some invalid state. Currently, the FSBL or u-boot-spl is resetting
the phy device, and so there is no issue observed in the linux network
setup.

The series is based on linux-5.10-rc5.
Patch 1: Add the OUI to the phy dt node to fix issue of missing mdio device
Patch 2 and 3:
Resetting phy needs GPIO support so add to dt and defconfig.

[1] https://lkml.org/lkml/2018/11/29/154

To reproduce the issue:
Using FSBL:
1. Comment out VSC8541 reset sequence in fsbl/main.c
   from within the freedom-u540-c000-bootloader.
2. Build and flash fsbl.bin to micro sdcard.

Using u-boot:
1. Comment out VSC8541 reset sequence in board/sifive/fu540/spl.c
   from mainline u-boot source code.
2. Build and flash u-boot binaries to micro sdcard.

Boot the board and bootlog will show network setup failure messages as:

[  1.069474] libphy: MACB_mii_bus: probed
[  1.073092] mdio_bus 1009.ethernet-: MDIO device at address 0
   is missing
.
[  1.979252] macb 1009.ethernet eth0: Could not attach PHY (-19)

3. Now apply the series build, and boot kernel.
4. MACB and VSC8541 driver get successfully probed and the network is set
   without any failure.


So irrespective of whether the prior stages handle the phy reset sequence,
the probing is successful in both the cases of cold boot and warm boot.

Change History:
===
V2:
-Rebased v1 on linux kernel v5.10-rc3.

V1:
-Ignore 4th patch as suggested and so removed it from the series.
-Verified this series on 5.7-rc5.

V0: Base RFC patch. Verified on 5.7-rc2

Sagar Shrikant Kadam (3):
  dts: phy: fix missing mdio device and probe failure of vsc8541-01
device
  dts: phy: add GPIO number and active state used for phy reset
  riscv: defconfig: enable gpio support for HiFive Unleashed

 arch/riscv/boot/dts/sifive/hifive-unleashed-a00.dts | 2 ++
 arch/riscv/configs/defconfig| 2 ++
 2 files changed, 4 insertions(+)


David pointed out I missed these, they're on fixes.  Thanks!


This is now on 5.10.12, and breaks ethernet on the Hifive Unleashed:

[   12.777976] macb 1009.ethernet: Registered clk switch 
'sifive-gemgxl-mgmt'
[   12.784559] macb 1009.ethernet: GEM doesn't support hardware ptp.
[   12.791629] libphy: MACB_mii_bus: probed
[   12.919728] MACsec IEEE 802.1AE
[   12.984676] macb 1009.ethernet eth0: Cadence GEM rev 0x10070109 at 
0x1009 irq 16 (70:b3:d5:92:f1:07)
[   14.030319] Microsemi VSC8541 SyncE 1009.ethernet-:00: 
phy_poll_reset failed: -110
[   14.038986] macb 1009.ethernet eth0: Could not attach PHY (-110)


Sorry about that.  Looks like we forgot to add the special reset sequence to
the VSC8541, which the driver doesn't yet support (there's a thread about it,
but I guess I forgot to clean up the patch).  IIUC this should manifest on
master as well, so my guess is that nobody is testing the HiFive Unleashed any
more (probably a bad sign).

I'll send out a revert.  I looked at the GPIO driver and can't tell if it's
twiddling GPIO lines when probed, in which case just enabling the GPIO would
break the ethernet.  Hopefully we're OK with the GPIO driver enabled.

Thanks for testing this.

Re: [RFC PATCH 00/12] Introduce sv48 support without relocable kernel

[Palmer Dabbelt]

On Sat, 30 Jan 2021 01:33:20 PST (-0800), a...@ghiti.fr wrote:

Hi Palmer,

On 1/4/21 2:58 PM, Alexandre Ghiti wrote:

This patchset, contrary to the previous versions, allows to have a single
kernel for sv39 and sv48 without being relocatable.

The idea comes from Arnd Bergmann who suggested to do the same as x86,
that is mapping the kernel to the end of the address space, which allows
the kernel to be linked at the same address for both sv39 and sv48 and
then does not require to be relocated at runtime.

This is an RFC because I need to at least rebase a few commits and add
documentation. The most interesting patches where I expect feedbacks are
1/12, 2/12 and 8/12. Note that moving the kernel out of the linear
mapping and sv48 support can be separate patchsets, I share them together
today to show that it works (this patchset is rebased on top of v5.10).

If we agree about the overall idea, I'll rebase my relocatable patchset
on top of that and then KASLR implementation from Zong will be greatly
simplified since moving the kernel out of the linear mapping will avoid
to copy the kernel physically.

This implements sv48 support at runtime. The kernel will try to
boot with 4-level page table and will fallback to 3-level if the HW does not
support it. Folding the 4th level into a 3-level page table has almost no
cost at runtime.

Finally, the user can now ask for sv39 explicitly by using the device-tree
which will reduce memory footprint and reduce the number of memory accesses
in case of TLB miss.

Alexandre Ghiti (12):
   riscv: Move kernel mapping outside of linear mapping
   riscv: Protect the kernel linear mapping
   riscv: Get rid of compile time logic with MAX_EARLY_MAPPING_SIZE
   riscv: Allow to dynamically define VA_BITS
   riscv: Simplify MAXPHYSMEM config
   riscv: Prepare ptdump for vm layout dynamic addresses
   asm-generic: Prepare for riscv use of pud_alloc_one and pud_free
   riscv: Implement sv48 support
   riscv: Allow user to downgrade to sv39 when hw supports sv48
   riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo
   riscv: Explicit comment about user virtual address space size
   riscv: Improve virtual kernel memory layout dump

  arch/riscv/Kconfig  |  34 +--
  arch/riscv/boot/loader.lds.S|   3 +-
  arch/riscv/include/asm/csr.h|   3 +-
  arch/riscv/include/asm/fixmap.h |   3 +
  arch/riscv/include/asm/page.h   |  33 ++-
  arch/riscv/include/asm/pgalloc.h|  40 +++
  arch/riscv/include/asm/pgtable-64.h | 104 ++-
  arch/riscv/include/asm/pgtable.h|  68 +++--
  arch/riscv/include/asm/sparsemem.h  |   6 +-
  arch/riscv/kernel/cpu.c |  23 +-
  arch/riscv/kernel/head.S|   6 +-
  arch/riscv/kernel/module.c  |   4 +-
  arch/riscv/kernel/vmlinux.lds.S |   3 +-
  arch/riscv/mm/context.c |   2 +-
  arch/riscv/mm/init.c| 376 
  arch/riscv/mm/physaddr.c|   2 +-
  arch/riscv/mm/ptdump.c  |  56 +++-
  drivers/firmware/efi/libstub/efi-stub.c |   2 +-
  include/asm-generic/pgalloc.h   |  24 +-
  include/linux/sizes.h   |   3 +-
  20 files changed, 648 insertions(+), 147 deletions(-)



Any thought about the idea ? Is it going in the right direction ? I have
fixed quite a few things since I posted this so don't bother giving this
patchset a full review.


My only real issue was the relocation stuff, which appears to be fixed.  I 
haven't had the time to look at the patches, but it wouldn't hurt to send 
another revision.  The best bet might be to just wait until 5.11 and send on 
top of that, it's too late for this one anyway and that'll be a stable base to 
test from.

Re: [PATCH] riscv: kasan: remove unneeded semicolon

[Palmer Dabbelt]

On Mon, 01 Feb 2021 21:51:59 PST (-0800), yang@linux.alibaba.com wrote:

Eliminate the following coccicheck warning:
./arch/riscv/mm/kasan_init.c:103:2-3: Unneeded semicolon

Reported-by: Abaci Robot 
Signed-off-by: Yang Li 
---
 arch/riscv/mm/kasan_init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/mm/kasan_init.c b/arch/riscv/mm/kasan_init.c
index a8a2ffd..fac437a 100644
--- a/arch/riscv/mm/kasan_init.c
+++ b/arch/riscv/mm/kasan_init.c
@@ -100,7 +100,7 @@ void __init kasan_init(void)
break;

populate(kasan_mem_to_shadow(start), kasan_mem_to_shadow(end));
-   };
+   }

for (i = 0; i < PTRS_PER_PTE; i++)
set_pte(&kasan_early_shadow_pte[i],


Thanks, this is on fixes.

Re: [PATCH 1/3] RISC-V: Fix .init section permission update

[Palmer Dabbelt]

On Fri, 29 Jan 2021 11:00:36 PST (-0800), Atish Patra wrote:

.init section permission should only updated to non-execute if
STRICT_KERNEL_RWX is enabled. Otherwise, this will lead to a kernel hang.

Fixes: 19a00869028f ("RISC-V: Protect all kernel sections including init early")

Suggested-by: Geert Uytterhoeven 
Reported-by: Geert Uytterhoeven 
Signed-off-by: Atish Patra 
---
 arch/riscv/kernel/setup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/setup.c b/arch/riscv/kernel/setup.c
index 3fa3f26dde85..c7c0655dd45b 100644
--- a/arch/riscv/kernel/setup.c
+++ b/arch/riscv/kernel/setup.c
@@ -293,6 +293,8 @@ void free_initmem(void)
unsigned long init_begin = (unsigned long)__init_begin;
unsigned long init_end = (unsigned long)__init_end;

-   set_memory_rw_nx(init_begin, (init_end - init_begin) >> PAGE_SHIFT);
+   if (IS_ENABLED(CONFIG_STRICT_KERNEL_RWX))
+   set_memory_rw_nx(init_begin, (init_end - init_begin) >> 
PAGE_SHIFT);
+
free_initmem_default(POISON_FREE_INITMEM);
 }


Thanks, this is on fixes.

Re: [PATCH 3/3] RISC-V: Define MAXPHYSMEM_1GB only for RV32

[Palmer Dabbelt]

On Fri, 29 Jan 2021 11:00:38 PST (-0800), Atish Patra wrote:

MAXPHYSMEM_1GB option was added for RV32 because RV32 only supports 1GB
of maximum physical memory. This lead to few compilation errors reported
by kernel test robot which created the following configuration combination
which are not useful but can be configured.

1. MAXPHYSMEM_1GB & RV64
2, MAXPHYSMEM_2GB & RV32

Fixes: e557793799c5 ("RISC-V: Fix maximum allowed phsyical memory for RV32")

Fix this by restricting MAXPHYSMEM_1GB for RV32 and MAXPHYSMEM_2GB only for
RV64.

Reported-by: Randy Dunlap 
Acked-by: Randy Dunlap 
Tested-by: Geert Uytterhoeven 
Signed-off-by: Atish Patra 
---
 arch/riscv/Kconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index e9e2c1f0a690..e0a34eb5ed3b 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -252,8 +252,10 @@ choice
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY

config MAXPHYSMEM_1GB
+   depends on 32BIT
bool "1GiB"
config MAXPHYSMEM_2GB
+   depends on 64BIT && CMODEL_MEDLOW
bool "2GiB"
config MAXPHYSMEM_128GB
depends on 64BIT && CMODEL_MEDANY


Ah, I guess here's the patch :).  This is on fixes.

Thanks!

Re: Kconfig-induced build errors: CONFIG_PAGE_OFFSET

[Palmer Dabbelt]

On Tue, 02 Feb 2021 18:27:42 PST (-0800), Palmer Dabbelt wrote:

On Fri, 29 Jan 2021 05:52:51 PST (-0800), ge...@linux-m68k.org wrote:

Hi Atish,

On Thu, Jan 28, 2021 at 9:09 PM Atish Patra  wrote:

On Wed, Jan 27, 2021 at 7:18 PM Randy Dunlap  wrote:
> I took a riscv-32 .config from kernel test robot (it was for a clang build)
> and did a "make olddefconfig" (using gcc tools) and got build errors
> due to this config item from arch/riscv/Kconfig;
>
>
> config PAGE_OFFSET
> hex
> default 0xC000 if 32BIT && MAXPHYSMEM_1GB
> default 0x8000 if 64BIT && !MMU
> default 0x8000 if 64BIT && MAXPHYSMEM_2GB
> default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
>
> PAGE_OFFSET is undefined for the case of 32BIT && MAXPHYSMEM_2GB.

Because, RV32 doesn't support 2GB physical memory yet.

The compilation errors can be fixed by not allowing MAXPHYSMEM_2GB for RV32 and
MAXPHYSMEM_1GB for RV64. How about this ?

--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -253,8 +253,10 @@ choice
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY

config MAXPHYSMEM_1GB
+   depends on 32BIT
bool "1GiB"
config MAXPHYSMEM_2GB
+   depends on 64BIT && CMODEL_MEDLOW
bool "2GiB"
config MAXPHYSMEM_128GB
depends on 64BIT && CMODEL_MEDANY


Thanks, works fine on litex-vexriscv.
Tested-by: Geert Uytterhoeven 


Atish: did I miss an actual patch?  I just see diff here.


Never mind, I found it.  Thanks!

Re: [PATCH 2/3] riscv: Align on L1_CACHE_BYTES when STRICT_KERNEL_RWX

[Palmer Dabbelt]

On Fri, 29 Jan 2021 11:00:37 PST (-0800), Atish Patra wrote:

From: Sebastien Van Cauwenberghe 

Allows the sections to be aligned on smaller boundaries and
therefore results in a smaller kernel image size.

Signed-off-by: Sebastien Van Cauwenberghe 
Reviewed-by: Atish Patra 
---
 arch/riscv/include/asm/set_memory.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/riscv/include/asm/set_memory.h 
b/arch/riscv/include/asm/set_memory.h
index 211eb8244a45..8b80c80c7f1a 100644
--- a/arch/riscv/include/asm/set_memory.h
+++ b/arch/riscv/include/asm/set_memory.h
@@ -32,14 +32,14 @@ bool kernel_page_present(struct page *page);

 #endif /* __ASSEMBLY__ */

-#ifdef CONFIG_ARCH_HAS_STRICT_KERNEL_RWX
+#ifdef CONFIG_STRICT_KERNEL_RWX
 #ifdef CONFIG_64BIT
 #define SECTION_ALIGN (1 << 21)
 #else
 #define SECTION_ALIGN (1 << 22)
 #endif
-#else /* !CONFIG_ARCH_HAS_STRICT_KERNEL_RWX */
+#else /* !CONFIG_STRICT_KERNEL_RWX */
 #define SECTION_ALIGN L1_CACHE_BYTES
-#endif /* CONFIG_ARCH_HAS_STRICT_KERNEL_RWX */
+#endif /* CONFIG_STRICT_KERNEL_RWX */

 #endif /* _ASM_RISCV_SET_MEMORY_H */


Thanks, this is on fixes.

Re: [PATCH] riscv: virt_addr_valid must check the address belongs to linear mapping

[Palmer Dabbelt]

On Fri, 29 Jan 2021 09:31:05 PST (-0800), a...@ghiti.fr wrote:

virt_addr_valid macro checks that a virtual address is valid, ie that
the address belongs to the linear mapping and that the corresponding
 physical page exists.

Add the missing check that ensures the virtual address belongs to the
linear mapping, otherwise __virt_to_phys, when compiled with
CONFIG_DEBUG_VIRTUAL enabled, raises a WARN that is interpreted as a
kernel bug by syzbot.

Signed-off-by: Alexandre Ghiti 
---
 arch/riscv/include/asm/page.h | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index 2d50f76efe48..64a675c5c30a 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -135,7 +135,10 @@ extern phys_addr_t __phys_addr_symbol(unsigned long x);

 #endif /* __ASSEMBLY__ */

-#define virt_addr_valid(vaddr) (pfn_valid(virt_to_pfn(vaddr)))
+#define virt_addr_valid(vaddr) ({  
\
+   unsigned long _addr = (unsigned long)vaddr; 
\
+   (unsigned long)(_addr) >= PAGE_OFFSET && pfn_valid(virt_to_pfn(_addr)); 
 \
+})

 #define VM_DATA_DEFAULT_FLAGS  VM_DATA_FLAGS_NON_EXEC


Thanks, this is on fixes.

Re: [PATCH v4] RISC-V: Implement ASID allocator

[Palmer Dabbelt]

has no direct mechanism for instruction cache
@@ -58,10 +314,7 @@ void switch_mm(struct mm_struct *prev, struct mm_struct 
*next,
cpumask_clear_cpu(cpu, mm_cpumask(prev));
cpumask_set_cpu(cpu, mm_cpumask(next));

-#ifdef CONFIG_MMU
-   csr_write(CSR_SATP, virt_to_pfn(next->pgd) | SATP_MODE);
-   local_flush_tlb_all();
-#endif
+   set_mm(next, cpu);

flush_icache_deferred(next);
 }


So I know we'd said before that we weren't going to take this until there's 
hardware, but I think the QEMU support is good enough -- I don't really care if 
the ISA says this might change, it's been in there for long enough.


Aside from the assertions

Reviewed-by: Palmer Dabbelt 

LMK if you're going to send a v5 or you want me to just fix it up.

Thanks!

Re: Kconfig-induced build errors: CONFIG_PAGE_OFFSET

[Palmer Dabbelt]

On Fri, 29 Jan 2021 05:52:51 PST (-0800), ge...@linux-m68k.org wrote:

Hi Atish,

On Thu, Jan 28, 2021 at 9:09 PM Atish Patra  wrote:

On Wed, Jan 27, 2021 at 7:18 PM Randy Dunlap  wrote:
> I took a riscv-32 .config from kernel test robot (it was for a clang build)
> and did a "make olddefconfig" (using gcc tools) and got build errors
> due to this config item from arch/riscv/Kconfig;
>
>
> config PAGE_OFFSET
> hex
> default 0xC000 if 32BIT && MAXPHYSMEM_1GB
> default 0x8000 if 64BIT && !MMU
> default 0x8000 if 64BIT && MAXPHYSMEM_2GB
> default 0xffe0 if 64BIT && MAXPHYSMEM_128GB
>
> PAGE_OFFSET is undefined for the case of 32BIT && MAXPHYSMEM_2GB.

Because, RV32 doesn't support 2GB physical memory yet.

The compilation errors can be fixed by not allowing MAXPHYSMEM_2GB for RV32 and
MAXPHYSMEM_1GB for RV64. How about this ?

--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -253,8 +253,10 @@ choice
default MAXPHYSMEM_128GB if 64BIT && CMODEL_MEDANY

config MAXPHYSMEM_1GB
+   depends on 32BIT
bool "1GiB"
config MAXPHYSMEM_2GB
+   depends on 64BIT && CMODEL_MEDLOW
bool "2GiB"
config MAXPHYSMEM_128GB
depends on 64BIT && CMODEL_MEDANY


Thanks, works fine on litex-vexriscv.
Tested-by: Geert Uytterhoeven 


Atish: did I miss an actual patch?  I just see diff here.

Re: [PATCH] arch_numa: fix common code printing of phys_addr_t

[Palmer Dabbelt]

On Mon, 01 Feb 2021 19:51:07 PST (-0800), rdun...@infradead.org wrote:

On 2/1/21 7:36 PM, Palmer Dabbelt wrote:

On Wed, 27 Jan 2021 19:55:33 PST (-0800), rdun...@infradead.org wrote:

Fix build warnings in the arch_numa common code:

../include/linux/kern_levels.h:5:18: warning: format '%Lx' expects argument of 
type 'long long unsigned int', but argument 3 has type 'phys_addr_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/base/arch_numa.c:360:56: note: format string is defined here
  360 |    pr_warn("Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
../drivers/base/arch_numa.c:435:39: note: format string is defined here
  435 |  pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start, end - 1);

Fixes: ae3c107cd8be ("numa: Move numa implementation to common code")
Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Atish Patra 
Cc: Palmer Dabbelt 
---
 drivers/base/arch_numa.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

--- linux-next-20210125.orig/drivers/base/arch_numa.c
+++ linux-next-20210125/drivers/base/arch_numa.c
@@ -355,11 +355,12 @@ static int __init numa_register_nodes(vo
 /* Check that valid nid is set to memblks */
 for_each_mem_region(mblk) {
 int mblk_nid = memblock_get_region_node(mblk);
+    phys_addr_t start = mblk->base;
+    phys_addr_t end = mblk->base + mblk->size - 1;

 if (mblk_nid == NUMA_NO_NODE || mblk_nid >= MAX_NUMNODES) {
-    pr_warn("Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
-    mblk_nid, mblk->base,
-    mblk->base + mblk->size - 1);
+    pr_warn("Warning: invalid memblk node %d [mem %pap-%pap]\n",
+    mblk_nid, &start, &end);
 return -EINVAL;
 }
 }
@@ -427,14 +428,14 @@ out_free_distance:
 static int __init dummy_numa_init(void)
 {
 phys_addr_t start = memblock_start_of_DRAM();
-    phys_addr_t end = memblock_end_of_DRAM();
+    phys_addr_t end = memblock_end_of_DRAM() - 1;
 int ret;

 if (numa_off)
 pr_info("NUMA disabled\n"); /* Forced off on command line. */
-    pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start, end - 1);
+    pr_info("Faking a node at [mem %pap-%pap]\n", &start, &end);

-    ret = numa_add_memblk(0, start, end);
+    ret = numa_add_memblk(0, start, end + 1);
 if (ret) {
 pr_err("NUMA init failed\n");
 return ret;


Thanks, this is on for-next.  Did you, by any chance, find %Lx documented
anywhere?  It's not ISO C and the GCC source code says it's a GNU extension,
but I couldn't find it in the documentation (or even where to add it, which I
guess is how I forgot to send my version fo the patch).


'man sprintf' says this:

   As  a nonstandard extension, the GNU implementations treats ll and L as
   synonyms, so that one can, for example, write llg (as a synonym for the
   standards-compliant  Lg) and Ld (as a synonym for the standards compli-
   ant lld).  Such usage is nonportable.


and linux/lib/vsprintf.c has some handling for it:

if (qualifier == 'L')
spec->type = FORMAT_TYPE_LONG_LONG;

and

case 'L':
if (is_sign)
*va_arg(args, long long *) = val.s;
else
*va_arg(args, unsigned long long *) = val.u;
break;


Does that help?


The manpage does it, I guess I just wasn't reading closely enough. Thanks!

Re: [PATCH] arch_numa: fix common code printing of phys_addr_t

[Palmer Dabbelt]

On Wed, 27 Jan 2021 19:55:33 PST (-0800), rdun...@infradead.org wrote:

Fix build warnings in the arch_numa common code:

../include/linux/kern_levels.h:5:18: warning: format '%Lx' expects argument of 
type 'long long unsigned int', but argument 3 has type 'phys_addr_t' {aka 
'unsigned int'} [-Wformat=]
../drivers/base/arch_numa.c:360:56: note: format string is defined here
  360 |pr_warn("Warning: invalid memblk node %d [mem %#010Lx-%#010Lx]\n",
../drivers/base/arch_numa.c:435:39: note: format string is defined here
  435 |  pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start, end - 1);

Fixes: ae3c107cd8be ("numa: Move numa implementation to common code")
Signed-off-by: Randy Dunlap 
Reported-by: kernel test robot 
Cc: Atish Patra 
Cc: Palmer Dabbelt 
---
 drivers/base/arch_numa.c |   13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

--- linux-next-20210125.orig/drivers/base/arch_numa.c
+++ linux-next-20210125/drivers/base/arch_numa.c
@@ -355,11 +355,12 @@ static int __init numa_register_nodes(vo
/* Check that valid nid is set to memblks */
for_each_mem_region(mblk) {
int mblk_nid = memblock_get_region_node(mblk);
+   phys_addr_t start = mblk->base;
+   phys_addr_t end = mblk->base + mblk->size - 1;

if (mblk_nid == NUMA_NO_NODE || mblk_nid >= MAX_NUMNODES) {
-   pr_warn("Warning: invalid memblk node %d [mem 
%#010Lx-%#010Lx]\n",
-   mblk_nid, mblk->base,
-   mblk->base + mblk->size - 1);
+   pr_warn("Warning: invalid memblk node %d [mem 
%pap-%pap]\n",
+   mblk_nid, &start, &end);
return -EINVAL;
}
}
@@ -427,14 +428,14 @@ out_free_distance:
 static int __init dummy_numa_init(void)
 {
phys_addr_t start = memblock_start_of_DRAM();
-   phys_addr_t end = memblock_end_of_DRAM();
+   phys_addr_t end = memblock_end_of_DRAM() - 1;
int ret;

if (numa_off)
pr_info("NUMA disabled\n"); /* Forced off on command line. */
-   pr_info("Faking a node at [mem %#018Lx-%#018Lx]\n", start, end - 1);
+   pr_info("Faking a node at [mem %pap-%pap]\n", &start, &end);

-   ret = numa_add_memblk(0, start, end);
+   ret = numa_add_memblk(0, start, end + 1);
if (ret) {
pr_err("NUMA init failed\n");
return ret;


Thanks, this is on for-next.  Did you, by any chance, find %Lx documented
anywhere?  It's not ISO C and the GCC source code says it's a GNU extension,
but I couldn't find it in the documentation (or even where to add it, which I
guess is how I forgot to send my version fo the patch).

[GIT PULL] A Single RISC-V Fix for 5.11-rc6

[Palmer Dabbelt]

The following changes since commit 19c329f6808995b142b3966301f217c831e7cf31:

  Linux 5.11-rc4 (2021-01-17 16:37:05 -0800)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git 
tags/riscv-for-linus-5.11-rc6

for you to fetch changes up to 336e8eb2a3cfe2285c314cd85630076da365f6c6:

  riscv: Fixup pfn_valid error with wrong max_mapnr (2021-01-22 20:18:03 -0800)


A Single RISC-V Fix for 5.11-rc6

* A fix to avoid initializing max_mapnr to be too large, which may
  manifest on NUMA systems.


Guo Ren (1):
  riscv: Fixup pfn_valid error with wrong max_mapnr

 arch/riscv/mm/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH v15 03/11] riscv/Kconfig: make direct map manipulation options depend on MMU

[Palmer Dabbelt]

On Sat, 23 Jan 2021 03:00:41 PST (-0800), r...@kernel.org wrote:

On Fri, Jan 22, 2021 at 08:12:30PM -0800, Palmer Dabbelt wrote:

On Wed, 20 Jan 2021 10:06:04 PST (-0800), r...@kernel.org wrote:
> From: Mike Rapoport 
>
> ARCH_HAS_SET_DIRECT_MAP and ARCH_HAS_SET_MEMORY configuration options have
> no meaning when CONFIG_MMU is disabled and there is no point to enable them
> for the nommu case.
>
> Add an explicit dependency on MMU for these options.
>
> Signed-off-by: Mike Rapoport 
> Reported-by: kernel test robot 
> ---
>  arch/riscv/Kconfig | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index d82303dcc6b6..d35ce19ab1fa 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -25,8 +25,8 @@ config RISCV
>select ARCH_HAS_KCOV
>select ARCH_HAS_MMIOWB
>select ARCH_HAS_PTE_SPECIAL
> -  select ARCH_HAS_SET_DIRECT_MAP
> -  select ARCH_HAS_SET_MEMORY
> +  select ARCH_HAS_SET_DIRECT_MAP if MMU
> +  select ARCH_HAS_SET_MEMORY if MMU
>select ARCH_HAS_STRICT_KERNEL_RWX if MMU
>select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
>    select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT

Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

LMK if you want this to go in via the RISC-V tree, otherwise I'm going to
assume it's going in along with the rest of these.  FWIW I see these in other
architectures without the MMU guard.


Except arm, they all always have MMU=y and arm selects only
ARCH_HAS_SET_MEMORY and has empty stubs for those when MMU=n.


OK, maybe I just checked ARM, then.  I was just making sure.


Indeed I might have been over zealous adding ARCH_HAS_SET_MEMORY dependency
on MMU, as riscv also has these stubs, but I thought that making this
explicit is a nice thing.


It seems reasonable to me.

Thanks!

Re: [PATCH] arch/riscv:fix typo in a comment in arch/riscv/kernel/image-vars.h

[Palmer Dabbelt]

On Wed, 20 Jan 2021 17:55:13 PST (-0800), tangchun...@163.com wrote:

From: tangchunyou 

"kerne" -> "kernel"

Signed-off-by: WenZhang 
---
 arch/riscv/kernel/image-vars.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/riscv/kernel/image-vars.h b/arch/riscv/kernel/image-vars.h
index 8c212ef..71a76a6 100644
--- a/arch/riscv/kernel/image-vars.h
+++ b/arch/riscv/kernel/image-vars.h
@@ -3,7 +3,7 @@
  * Copyright (C) 2020 Western Digital Corporation or its affiliates.
  * Linker script variables to be set after section resolution, as
  * ld.lld does not like variables assigned before SECTIONS is processed.
- * Based on arch/arm64/kerne/image-vars.h
+ * Based on arch/arm64/kernel/image-vars.h
  */
 #ifndef __RISCV_KERNEL_IMAGE_VARS_H
 #define __RISCV_KERNEL_IMAGE_VARS_H


Thanks, this is on for-next.

Re: [PATCH v15 03/11] riscv/Kconfig: make direct map manipulation options depend on MMU

[Palmer Dabbelt]

On Wed, 20 Jan 2021 10:06:04 PST (-0800), r...@kernel.org wrote:

From: Mike Rapoport 

ARCH_HAS_SET_DIRECT_MAP and ARCH_HAS_SET_MEMORY configuration options have
no meaning when CONFIG_MMU is disabled and there is no point to enable them
for the nommu case.

Add an explicit dependency on MMU for these options.

Signed-off-by: Mike Rapoport 
Reported-by: kernel test robot 
---
 arch/riscv/Kconfig | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index d82303dcc6b6..d35ce19ab1fa 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -25,8 +25,8 @@ config RISCV
select ARCH_HAS_KCOV
select ARCH_HAS_MMIOWB
select ARCH_HAS_PTE_SPECIAL
-   select ARCH_HAS_SET_DIRECT_MAP
-   select ARCH_HAS_SET_MEMORY
+   select ARCH_HAS_SET_DIRECT_MAP if MMU
+   select ARCH_HAS_SET_MEMORY if MMU
select ARCH_HAS_STRICT_KERNEL_RWX if MMU
select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT


Reviewed-by: Palmer Dabbelt 
Acked-by: Palmer Dabbelt 

LMK if you want this to go in via the RISC-V tree, otherwise I'm going to
assume it's going in along with the rest of these.  FWIW I see these in other
architectures without the MMU guard.

Thanks!