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

Hi Palmer, Le 4/15/21 à 2:00 PM, Alex Ghiti a écrit : Le 4/15/21 à 12:54 AM, Alex Ghiti a écrit : Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit : 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

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

Le 4/16/21 à 12:33 PM, Palmer Dabbelt a écrit : 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

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

Hi Guenter, Le 4/16/21 à 2:51 PM, Guenter Roeck a écrit : On Fri, Apr 09, 2021 at 02:14:58AM -0400, Alexandre Ghiti 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

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

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

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

Le 4/15/21 à 12:54 AM, Alex Ghiti a écrit : Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit : 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

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

Le 4/15/21 à 12:20 AM, Palmer Dabbelt a écrit : 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

Re: [PATCH] implement flush_cache_vmap for RISC-V

Hi, Le 4/12/21 à 3:08 AM, Jisheng Zhang a écrit : Hi Jiuyang, On Mon, 12 Apr 2021 00:05:30 + Jiuyang Liu wrote: This patch implements flush_cache_vmap for RISC-V, since it modifies PTE. Without this patch, SFENCE.VMA won't be added to related codes, which might introduce a bug in the

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

Le 4/13/21 à 2:35 AM, Alexandre Ghiti a écrit : From: Vitaly Wool 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.

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

Le 4/9/21 à 10:42 AM, Vitaly Wool a écrit : On Fri, Apr 9, 2021 at 3:59 PM Mike Rapoport wrote: On Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrote: Also, will that memory properly be exposed in the resource tree as System RAM (e.g., /proc/iomem) ? Otherwise some things

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

Le 4/9/21 à 8:07 AM, David Hildenbrand a écrit : On 09.04.21 13:39, Alex Ghiti wrote: Hi David, Le 4/9/21 à 4:23 AM, David Hildenbrand a écrit : On 09.04.21 09:14, Alex Ghiti wrote: Le 4/9/21 à 2:51 AM, Alexandre Ghiti a écrit : From: Vitaly Wool Introduce XIP (eXecute In Place) support

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

Hi David, Le 4/9/21 à 4:23 AM, David Hildenbrand a écrit : On 09.04.21 09:14, Alex Ghiti wrote: Le 4/9/21 à 2:51 AM, Alexandre Ghiti a écrit : From: Vitaly Wool Introduce XIP (eXecute In Place) support for RISC-V platforms. It allows code to be executed directly from non-volatile storage

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

Le 4/9/21 à 2:51 AM, Alexandre Ghiti a écrit : From: Vitaly Wool 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.

Re: [PATCH] driver: of: Properly truncate command line if too long

Hi Andy, Le 4/6/21 à 6:56 PM, Andy Shevchenko a écrit : On Tuesday, March 16, 2021, Alexandre Ghiti > wrote: In case the command line given by the user is too long, warn about it and truncate it to the last full argument. This is what efi already does in

Re: [PATCH v3 2/5] RISC-V: Add kexec support

Le 4/5/21 à 4:57 AM, Nick Kossifidis a écrit : This patch adds support for kexec on RISC-V. On SMP systems it depends on HOTPLUG_CPU in order to be able to bring up all harts after kexec. It also needs a recent OpenSBI version that supports the HSM extension. I tested it on riscv64 QEMU on

Re: [PATCH v3 4/5] RISC-V: Add kdump support

Hi Nick, Le 4/5/21 à 4:57 AM, Nick Kossifidis a écrit : This patch adds support for kdump, the kernel will reserve a region for the crash kernel and jump there on panic. In order for userspace tools (kexec-tools) to prepare the crash kernel kexec image, we also need to expose some information

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

Le 4/6/21 à 3:54 AM, Vitaly Wool a écrit : On Tue, Apr 6, 2021 at 8:47 AM Alex Ghiti wrote: Hi Vitaly, Le 4/5/21 à 4:34 AM, Vitaly Wool a écrit : On Sun, Apr 4, 2021 at 10:39 AM Vitaly Wool wrote: On Sat, Apr 3, 2021 at 12:00 PM Alex Ghiti wrote: Hi Vitaly, Le 4/1/21 à 7:10 AM

Re: [PATCH] driver: of: Properly truncate command line if too long

Le 4/6/21 à 9:40 AM, Rob Herring a écrit : On Sat, Apr 3, 2021 at 7:09 AM Alex Ghiti wrote: Hi, Le 3/16/21 à 3:38 PM, Alexandre Ghiti a écrit : In case the command line given by the user is too long, warn about it and truncate it to the last full argument. This is what efi already does

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

Hi Vitaly, Le 4/5/21 à 4:34 AM, Vitaly Wool a écrit : On Sun, Apr 4, 2021 at 10:39 AM Vitaly Wool wrote: On Sat, Apr 3, 2021 at 12:00 PM Alex Ghiti wrote: Hi Vitaly, Le 4/1/21 à 7:10 AM, Alex Ghiti a écrit : Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit : Hi Alex, On Thu, Apr 1, 2021 at 10

Re: [PATCH] driver: of: Properly truncate command line if too long

Hi, Le 3/16/21 à 3:38 PM, Alexandre Ghiti a écrit : In case the command line given by the user is too long, warn about it and truncate it to the last full argument. This is what efi already does in commit 80b1bfe1cb2f ("efi/libstub: Don't parse overlong command lines"). Reported-by: Dmitry

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

Hi Vitaly, Le 4/1/21 à 7:10 AM, Alex Ghiti a écrit : Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit : Hi Alex, On Thu, Apr 1, 2021 at 10:11 AM Alex Ghiti wrote: Hi, Le 3/30/21 à 4:04 PM, Alex Ghiti a écrit : Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : On Tue, 30 Mar 2021 11:39:10 PDT

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

Le 4/1/21 à 4:52 AM, Vitaly Wool a écrit : Hi Alex, On Thu, Apr 1, 2021 at 10:11 AM Alex Ghiti wrote: Hi, Le 3/30/21 à 4:04 PM, Alex Ghiti a écrit : Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : On Tue, 30 Mar 2021 11:39:10 PDT (-0700), a...@ghiti.fr wrote: Le 3/30/21 à 2:26 AM

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

Hi, Le 3/30/21 à 4:04 PM, Alex Ghiti a écrit : Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : 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

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

Le 3/30/21 à 3:33 PM, Palmer Dabbelt a écrit : 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:

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

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

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

Hi Jiuyang, Le 3/28/21 à 9:55 PM, Jiuyang Liu a écrit : 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

Re: [PATCH v4 3/5] RISC-V: Initial DTS for Microchip ICICLE board

Hi Atish, Le 3/3/21 à 3:02 PM, Atish Patra a écrit : Add initial DTS for Microchip ICICLE board having only essential devices (clocks, sdhci, ethernet, serial, etc). The device tree is based on the U-Boot patch.

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

Le 3/21/21 à 2:06 PM, Vitaly Wool a écrit : Hey Alex, On Sun, Mar 21, 2021 at 4:11 PM Alex Ghiti wrote: Hi Vitaly, Le 3/10/21 à 4:22 AM, Vitaly Wool a écrit : Introduce XIP (eXecute In Place) support for RISC-V platforms. It allows code to be executed directly from non-volatile storage

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

Hi Vitaly, Le 3/10/21 à 4:22 AM, Vitaly Wool a écrit : 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

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

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

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

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

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

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

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

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,

Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout

Hi Arnd, Le 3/11/21 à 3:42 AM, Arnd Bergmann a écrit : On Wed, Mar 10, 2021 at 8:12 PM Alex Ghiti wrote: Le 3/10/21 à 6:42 AM, Arnd Bergmann a écrit : On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti wrote: Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

Le 3/12/21 à 10:12 AM, Dmitry Vyukov a écrit : On Fri, Mar 12, 2021 at 2:50 PM Ben Dooks wrote: On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:0d7588ab riscv: process: Fix no

Re: [syzbot] BUG: unable to handle kernel access to user memory in schedule_tail

Hi Ben, Le 3/10/21 à 5:24 PM, Ben Dooks a écrit : On 10/03/2021 17:16, Dmitry Vyukov wrote: On Wed, Mar 10, 2021 at 5:46 PM syzbot wrote: Hello, syzbot found the following issue on: HEAD commit:    0d7588ab riscv: process: Fix no prototype for arch_dup_tas.. git tree:

Re: [PATCH v2] riscv: Improve KASAN_VMALLOC support

Le 3/9/21 à 9:37 PM, Palmer Dabbelt a écrit : 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

Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout

Hi Arnd, Le 3/10/21 à 6:42 AM, Arnd Bergmann a écrit : On Thu, Feb 25, 2021 at 12:56 PM Alex Ghiti wrote: Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit : || | |> + ffc0 | -256GB | ffc7 | 32 GB | ka

Re: riscv+KASAN does not boot

Le 3/9/21 à 12:11 PM, Dmitry Vyukov a écrit : On Fri, Feb 19, 2021 at 11:26 PM 'Palmer Dabbelt' via syzkaller wrote: 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

Re: [RFC PATCH 1/8] RISC-V: Enable CPU_IDLE drivers

Hi Anup, Le 2/21/21 à 4:37 AM, Anup Patel a écrit : We force select CPU_PM and provide asm/cpuidle.h so that we can use CPU IDLE drivers for Linux RISC-V kernel. Signed-off-by: Anup Patel --- arch/riscv/Kconfig| 7 +++ arch/riscv/configs/defconfig | 7 +++

Re: [PATCH] riscv: Add KASAN_VMALLOC support

Hi Palmer, Le 2/26/21 à 12:32 AM, Palmer Dabbelt a écrit : 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

Re: [PATCH 2/3] Documentation: riscv: Add documentation that describes the VM layout

Le 2/25/21 à 5:34 AM, David Hildenbrand a écrit : |    |  | |> + ffc0 | -256    GB | ffc7 |   32 GB | kasan +   ffcefee0 | -196    GB | ffcefeff |    2 MB | fixmap +   ffceff00 | -196    GB |

Re: [PATCH] riscv: Add KASAN_VMALLOC support

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:

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Hi Nylon, Le 2/22/21 à 12:13 PM, Alex Ghiti a écrit : Le 2/21/21 à 8:37 PM, Nylon Chen a écrit : Hi Alex, Palmer Sorry I missed this message. On Sun, Feb 21, 2021 at 09:38:04PM +0800, Alex Ghiti wrote: Le 2/13/21 à 5:52 AM, Alex Ghiti a écrit : Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex

Re: [PATCH] riscv: mm: Remove the copy operation of pmd

Le 3/30/20 à 7:53 AM, Chuanhua Han a écrit : Since all processes share the kernel address space, we only need to copy pgd in case of a vmalloc page fault exception, the other levels of page tables are shared, so the operation of copying pmd is unnecessary. Signed-off-by: Chuanhua Han ---

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

Hi Palmer, Le 2/22/21 à 9:58 PM, Palmer Dabbelt a écrit : 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

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Le 2/21/21 à 8:37 PM, Nylon Chen a écrit : Hi Alex, Palmer Sorry I missed this message. On Sun, Feb 21, 2021 at 09:38:04PM +0800, Alex Ghiti wrote: Le 2/13/21 à 5:52 AM, Alex Ghiti a écrit : Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex Ghiti a écrit : Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer

Re: [PATCH] riscv: Get rid of MAX_EARLY_MAPPING_SIZE

Le 2/22/21 à 12:40 AM, Alex Ghiti a écrit : Hi Dmitry, Le 2/21/21 à 10:38 AM, Dmitry Vyukov a écrit : On Sun, Feb 21, 2021 at 3:22 PM Alexandre Ghiti wrote: At early boot stage, we have a whole PGDIR to map the kernel, so there is no need to restrict the early mapping size to 128MB

Re: [PATCH] riscv: Get rid of MAX_EARLY_MAPPING_SIZE

Hi Dmitry, Le 2/21/21 à 10:38 AM, Dmitry Vyukov a écrit : On Sun, Feb 21, 2021 at 3:22 PM Alexandre Ghiti wrote: At early boot stage, we have a whole PGDIR to map the kernel, so there is no need to restrict the early mapping size to 128MB. Removing this define also allows us to simplify some

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

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

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Le 2/13/21 à 5:52 AM, Alex Ghiti a écrit : Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex Ghiti a écrit : Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer Dabbelt a écrit : On Fri, 15 Jan 2021 21:58:35 PST (-0800), nyl...@andestech.com wrote: It references to x86/s390 architecture. >> So, it d

Re: riscv+KASAN does not boot

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

Re: riscv+KASAN does not boot

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

Re: riscv+KASAN does not boot

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

Re: riscv+KASAN does not boot

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

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Hi Nylon, Palmer, Le 2/8/21 à 1:28 AM, Alex Ghiti a écrit : Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer Dabbelt a écrit : On Fri, 15 Jan 2021 21:58:35 PST (-0800), nyl...@andestech.com wrote: It references to x86/s390 architecture. >> So, it doesn't map the early shadow page to cover V

Re: [PATCH] riscv: Improve kasan population by using hugepages when possible

Le 2/2/21 à 3:50 AM, Alex Ghiti a écrit : Hi, Le 2/1/21 à 3:00 AM, Alexandre Ghiti a écrit : Kasan function that populates the shadow regions used to allocate them page by page and did not take advantage of hugepages, so fix this by trying to allocate hugepages of 1GB and fallback to 2MB

Re: [PATCH v2 1/1] riscv/kasan: add KASAN_VMALLOC support

Hi Nylon, Le 1/22/21 à 10:56 PM, Palmer Dabbelt a écrit : On Fri, 15 Jan 2021 21:58:35 PST (-0800), nyl...@andestech.com wrote: It references to x86/s390 architecture. >> So, it doesn't map the early shadow page to cover VMALLOC space. Prepopulate top level page table for the range that would

Re: [PATCH] riscv: Improve kasan population by using hugepages when possible

Hi, Le 2/1/21 à 3:00 AM, Alexandre Ghiti a écrit : Kasan function that populates the shadow regions used to allocate them page by page and did not take advantage of hugepages, so fix this by trying to allocate hugepages of 1GB and fallback to 2MB hugepages or 4K pages in case it fails. This

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

Hi Yang, Le 2/2/21 à 12:51 AM, Yang Li a écrit : 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

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

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

Re: riscv+KASAN does not boot

Hi Dmitry, On 1/18/21 10:43 AM, Dmitry Vyukov wrote: On Mon, Jan 18, 2021 at 4:05 PM Dmitry Vyukov wrote: On Mon, Jan 18, 2021 at 3:53 PM Tobias Klauser wrote: On Thu, Jan 14, 2021 at 5:57 AM Palmer Dabbelt wrote: On Fri, 25 Dec 2020 09:13:23 PST (-0800), dvyu...@google.com wrote: On

Re: [RFC PATCH 01/12] riscv: Move kernel mapping outside of linear mapping

Le 1/6/21 à 1:44 AM, Anup Patel a écrit : On Wed, Jan 6, 2021 at 12:06 PM Alex Ghiti wrote: Hi Anup, Le 1/5/21 à 6:40 AM, Anup Patel a écrit : On Tue, Jan 5, 2021 at 1:29 AM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel and sv48 support. The kernel used

Re: [RFC PATCH 04/12] riscv: Allow to dynamically define VA_BITS

Le 1/5/21 à 7:06 AM, Anup Patel a écrit : On Tue, Jan 5, 2021 at 1:33 AM Alexandre Ghiti wrote: With 4-level page table folding at runtime, we don't know at compile time the size of the virtual address space so we must set VA_BITS dynamically so that sparsemem reserves the right amount of

Re: [RFC PATCH 01/12] riscv: Move kernel mapping outside of linear mapping

Hi Anup, Le 1/5/21 à 6:40 AM, Anup Patel a écrit : On Tue, Jan 5, 2021 at 1:29 AM Alexandre Ghiti 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.

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Le 7/21/20 à 7:36 PM, Palmer Dabbelt a écrit : On Tue, 21 Jul 2020 16:11:02 PDT (-0700), b...@kernel.crashing.org wrote: On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: > > I guess I don't understand why this is necessary at all. > > Specifically: why > > can'

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

sets have imposed a significant performance penalty on all systems). Alex Alex Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit : Hi Palmer, Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit : On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote: This is a preparatory patch for relocata

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Hi Benjamin, Le 7/21/20 à 7:11 PM, Benjamin Herrenschmidt a écrit : On Tue, 2020-07-21 at 14:36 -0400, Alex Ghiti wrote: I guess I don't understand why this is necessary at all. Specifically: why can't we just relocate the kernel within the linear map? That would let the bootloader put

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Let's try to make progress here: I add linux-mm in CC to get feedback on this patch as it blocks sv48 support too. Alex Le 7/9/20 à 7:11 AM, Alex Ghiti a écrit : Hi Palmer, Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit : On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Hi Palmer, Le 7/9/20 à 1:05 AM, Palmer Dabbelt a écrit : On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory.

Re: [PATCH] riscv: Enable ELF-ASLR for riscv

Hi Guo, Le 7/9/20 à 12:38 AM, guo...@kernel.org a écrit : From: Guo Ren Let riscv enable randomizes the stack, heap and binary images of ELF binaries. Seems it's ok at all after qemu & chip test and there is no founded side effect. So just simply select ARCH_HAS_ELF_RANDOMIZE :)

Re: [PATCH v5 0/4] vmalloc kernel mapping and relocatable kernel

Hi Palmer, Le 6/7/20 à 3:59 AM, Alexandre Ghiti a écrit : This patchset originally implemented relocatable kernel support but now also moves the kernel mapping into the vmalloc zone. The first patch explains why

Re: [PATCH v2 0/8] Introduce sv48 support

Hi Palmer, Le 7/1/20 à 2:27 PM, Palmer Dabbelt a écrit : On Wed, 03 Jun 2020 01:10:56 PDT (-0700), a...@ghiti.fr wrote: This patchset 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. The

Re: [PATCH 2/2] riscv: Use PUD/PGDIR entries for linear mapping when possible

Hi Atish, Le 6/22/20 à 3:11 PM, Atish Patra a écrit : On Sun, Jun 21, 2020 at 2:39 AM Alex Ghiti wrote: Hi Atish, Le 6/20/20 à 5:04 AM, Alex Ghiti a écrit : Hi Atish, Le 6/19/20 à 2:16 PM, Atish Patra a écrit : On Thu, Jun 18, 2020 at 9:28 PM Alex Ghiti wrote: Hi Atish, Le 6/18/20 à 8

Re: [PATCH 0/2] PUD/PGDIR entries for linear mapping

Le 6/3/20 à 11:36 AM, Alexandre Ghiti a écrit : This small patchset intends to use PUD/PGDIR entries for linear mapping in order to better utilize TLB. At the moment, only PMD entries can be used since on common platforms (qemu/unleashed), the kernel is loaded at DRAM + 2MB which dealigns

Re: [PATCH v2 5/8] riscv: Implement sv48 support

Hi Nick, Le 6/27/20 à 8:30 AM, Nick Kossifidis a écrit : Στις 2020-06-03 11:11, Alexandre Ghiti έγραψε: By adding a new 4th level of page table, give the possibility to 64bit kernel to address 2^48 bytes of virtual address: in practice, that roughly offers ~160TB of virtual address space to

Re: [PATCH 2/2] riscv: Use PUD/PGDIR entries for linear mapping when possible

Hi Atish, Le 6/20/20 à 5:04 AM, Alex Ghiti a écrit : Hi Atish, Le 6/19/20 à 2:16 PM, Atish Patra a écrit : On Thu, Jun 18, 2020 at 9:28 PM Alex Ghiti wrote: Hi Atish, Le 6/18/20 à 8:47 PM, Atish Patra a écrit : On Wed, Jun 3, 2020 at 8:38 AM Alexandre Ghiti wrote: Improve best_map_size

Re: [PATCH 2/2] riscv: Use PUD/PGDIR entries for linear mapping when possible

Hi Atish, Le 6/19/20 à 2:16 PM, Atish Patra a écrit : On Thu, Jun 18, 2020 at 9:28 PM Alex Ghiti wrote: Hi Atish, Le 6/18/20 à 8:47 PM, Atish Patra a écrit : On Wed, Jun 3, 2020 at 8:38 AM Alexandre Ghiti wrote: Improve best_map_size so that PUD or PGDIR entries are used for linear

Re: [PATCH 2/2] riscv: Use PUD/PGDIR entries for linear mapping when possible

Hi Atish, Le 6/18/20 à 8:47 PM, Atish Patra a écrit : On Wed, Jun 3, 2020 at 8:38 AM Alexandre Ghiti wrote: Improve best_map_size so that PUD or PGDIR entries are used for linear mapping when possible as it allows better TLB utilization. Signed-off-by: Alexandre Ghiti ---

Re: [PATCH v2 0/8] Introduce sv48 support

Hi Palmer, Le 6/3/20 à 4:10 AM, Alexandre Ghiti a écrit : This patchset 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.

Re: mm lock issue while booting Linux on 5.8-rc1 for RISC-V

Le 6/16/20 à 2:07 PM, Palmer Dabbelt a écrit : On Tue, 16 Jun 2020 10:54:51 PDT (-0700), ati...@atishpatra.org wrote: On Tue, Jun 16, 2020 at 3:45 AM Michel Lespinasse wrote: I am also unable to reproduce the issue so far. I wanted to point to a few things in case this helps: - Commit

Re: [PATCH 0/2] PUD/PGDIR entries for linear mapping

Hi Atish, Le 6/12/20 à 1:43 PM, Atish Patra a écrit : On Fri, Jun 12, 2020 at 6:17 AM Alex Ghiti wrote: Le 6/12/20 à 8:59 AM, Alex Ghiti a écrit : Hi Atish, Le 6/11/20 à 1:29 PM, Atish Patra a écrit : On Wed, Jun 10, 2020 at 11:51 PM Alex Ghiti wrote: Hi Atish, Le 6/10/20 à 2:32 PM

Re: [PATCH 0/2] PUD/PGDIR entries for linear mapping

Le 6/12/20 à 8:59 AM, Alex Ghiti a écrit : Hi Atish, Le 6/11/20 à 1:29 PM, Atish Patra a écrit : On Wed, Jun 10, 2020 at 11:51 PM Alex Ghiti  wrote: Hi Atish, Le 6/10/20 à 2:32 PM, Atish Patra a écrit : On Wed, Jun 3, 2020 at 8:36 AM Alexandre Ghiti  wrote: This small patchset intends

Re: [PATCH 0/2] PUD/PGDIR entries for linear mapping

Hi Atish, Le 6/11/20 à 1:29 PM, Atish Patra a écrit : On Wed, Jun 10, 2020 at 11:51 PM Alex Ghiti wrote: Hi Atish, Le 6/10/20 à 2:32 PM, Atish Patra a écrit : On Wed, Jun 3, 2020 at 8:36 AM Alexandre Ghiti wrote: This small patchset intends to use PUD/PGDIR entries for linear mapping

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

Hi Atish, Le 6/11/20 à 5:34 PM, Atish Patra a écrit : On Sun, Jun 7, 2020 at 1:01 AM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory. Therefore,

Re: [PATCH v5 2/4] riscv: Introduce CONFIG_RELOCATABLE

Hi Jerome, Le 6/10/20 à 10:10 AM, Jerome Forissier a écrit : On 6/7/20 9:59 AM, Alexandre Ghiti wrote: [...] +config RELOCATABLE + bool + depends on MMU + help + This builds a kernel as a Position Independent Executable (PIE), + which retains all relocation

Re: [PATCH 0/2] PUD/PGDIR entries for linear mapping

Hi Atish, Le 6/10/20 à 2:32 PM, Atish Patra a écrit : On Wed, Jun 3, 2020 at 8:36 AM Alexandre Ghiti wrote: This small patchset intends to use PUD/PGDIR entries for linear mapping in order to better utilize TLB. At the moment, only PMD entries can be used since on common platforms

Re: [PATCH v4 1/4] riscv: Move kernel mapping to vmalloc zone

Hi Zong, Le 6/3/20 à 10:52 PM, Zong Li a écrit : On Wed, Jun 3, 2020 at 4:01 PM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory. Therefore, we

Re: [PATCH v3 1/3] riscv: Move kernel mapping to vmalloc zone

Hi Zong, Le 5/27/20 à 3:29 AM, Alex Ghiti a écrit : Le 5/27/20 à 2:05 AM, Zong Li a écrit : On Wed, May 27, 2020 at 1:06 AM Alex Ghiti wrote: Hi Zong, Le 5/26/20 à 5:43 AM, Zong Li a écrit : On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote: This is a preparatory patch

Re: [PATCH v3 1/3] riscv: Move kernel mapping to vmalloc zone

Le 5/27/20 à 2:05 AM, Zong Li a écrit : On Wed, May 27, 2020 at 1:06 AM Alex Ghiti wrote: Hi Zong, Le 5/26/20 à 5:43 AM, Zong Li a écrit : On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET

Re: [PATCH v3 1/3] riscv: Move kernel mapping to vmalloc zone

Hi Zong, Le 5/26/20 à 5:43 AM, Zong Li a écrit : On Sun, May 24, 2020 at 4:54 PM Alexandre Ghiti wrote: This is a preparatory patch for relocatable kernel. The kernel used to be linked at PAGE_OFFSET address and used to be loaded physically at the beginning of the main memory. Therefore, we

Re: [PATCH 5/8] riscv: Implement sv48 support

Le 5/25/20 à 2:45 AM, Anup Patel a écrit : On Sun, May 24, 2020 at 2:45 PM Alexandre Ghiti wrote: By adding a new 4th level of page table, give the possibility to 64bit kernel to address 2^48 bytes of virtual address: in practice, that roughly offers ~160TB of virtual address space to

Re: [PATCH 7/8] riscv: Use pgtable_l4_enabled to output mmu type in cpuinfo

Hi Anup, Le 5/25/20 à 2:21 AM, Anup Patel a écrit : On Sun, May 24, 2020 at 2:47 PM Alexandre Ghiti wrote: Now that the mmu type is determined at runtime using SATP characteristic, use the global variable pgtable_l4_enabled to output mmu type of the processor through /proc/cpuinfo instead of

Re: [PATCH 04/10] riscv: Fix print_vm_layout build error if NOMMU

Hi, On 5/10/20 10:19 PM, Kefeng Wang wrote: arch/riscv/mm/init.c: In function ‘print_vm_layout’: arch/riscv/mm/init.c:68:37: error: ‘FIXADDR_START’ undeclared (first use in this function); arch/riscv/mm/init.c:69:20: error: ‘FIXADDR_TOP’ undeclared arch/riscv/mm/init.c:70:37: error:

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/8/19 10:07 PM, Atish Patra wrote: On Tue, 2019-10-08 at 07:58 -0400, Alex Ghiti wrote: On 10/7/19 8:46 PM, Atish Patra wrote: On Mon, 2019-10-07 at 05:11 -0400, Alex Ghiti wrote: On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/7/19 8:46 PM, Atish Patra wrote: On Mon, 2019-10-07 at 05:11 -0400, Alex Ghiti wrote: On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down

Re: [PATCH v11 07/22] riscv: mm: Add p?d_leaf() definitions

On 10/7/19 11:38 AM, Steven Price wrote: walk_page_range() is going to be allowed to walk page tables other than those of user space. For this it needs to know when it has reached a 'leaf' entry in the page tables. This information is provided by the p?d_leaf() functions/macros. For riscv a

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/7/19 5:11 AM, Alex Ghiti wrote: On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat

Re: [PATCH v6 14/14] riscv: Make mmap allocation top-down by default

On 10/4/19 10:12 PM, Atish Patra wrote: On Thu, 2019-08-08 at 02:17 -0400, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp

Re: [PATCH RESEND 0/8] Fix mmap base in bottom-up mmap

On 8/26/19 6:37 PM, Helge Deller wrote: On 26.08.19 09:34, Alexandre Ghiti wrote: On 6/20/19 7:03 AM, Alexandre Ghiti wrote: This series fixes the fallback of the top-down mmap: in case of failure, a bottom-up scheme can be tried as a last resort between the top-down mmap base and the stack,

Re: [PATCH v5 14/14] riscv: Make mmap allocation top-down by default

On 7/30/19 1:51 AM, Alexandre Ghiti wrote: In order to avoid wasting user address space by using bottom-up mmap allocation scheme, prefer top-down scheme when possible. Before: root@qemuriscv64:~# cat /proc/self/maps 0001-00016000 r-xp fe:00 6389 /bin/cat.coreutils

  1   2   >