From: Alex Ghiti <alex@ghiti.fr> To: Guenter Roeck <linux@roeck-us.net> Cc: Jonathan Corbet <corbet@lwn.net>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Arnd Bergmann <arnd@arndb.de>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Alexander Potapenko <glider@google.com>, Dmitry Vyukov <dvyukov@google.com>, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-arch@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4 1/3] riscv: Move kernel mapping outside of linear mapping Date: Sat, 17 Apr 2021 13:23:33 -0400 [thread overview] Message-ID: <8c23ed42-d8c7-70be-71d8-0eb74ace8e67@ghiti.fr> (raw) In-Reply-To: <20210416185139.GA42339@roeck-us.net> 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 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 <arnd@arndb.de> >> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> > > In next-20210416, when booting a riscv32 image in qemu, this patch results in: > > [ 0.000000] Linux version 5.12.0-rc7-next-20210416 (groeck@desktop) (riscv32-linux-gcc (GCC) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Fri Apr 16 10:38:09 PDT 2021 > [ 0.000000] OF: fdt: Ignoring memory block 0x80000000 - 0xa0000000 > [ 0.000000] Machine model: riscv-virtio,qemu > [ 0.000000] earlycon: uart8250 at MMIO 0x10000000 (options '115200') > [ 0.000000] printk: bootconsole [uart8250] enabled > [ 0.000000] efi: UEFI not found. > [ 0.000000] Kernel panic - not syncing: init_resources: Failed to allocate 160 bytes > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.12.0-rc7-next-20210416 #1 > [ 0.000000] Hardware name: riscv-virtio,qemu (DT) > [ 0.000000] Call Trace: > [ 0.000000] [<80005292>] walk_stackframe+0x0/0xce > [ 0.000000] [<809f4db8>] dump_backtrace+0x38/0x46 > [ 0.000000] [<809f4dd4>] show_stack+0xe/0x16 > [ 0.000000] [<809ff1d0>] dump_stack+0x92/0xc6 > [ 0.000000] [<809f4fee>] panic+0x10a/0x2d8 > [ 0.000000] [<80c02b24>] setup_arch+0x2a0/0x4ea > [ 0.000000] [<80c006b0>] start_kernel+0x90/0x628 > [ 0.000000] ---[ end Kernel panic - not syncing: init_resources: Failed to allocate 160 bytes ]--- > > Reverting it fixes the problem. I understand that the version in -next is > different to this version of the patch, but I also tried v4 and it still > crashes with the same error message. > I completely neglected 32b kernel in this series, I fixed that here: Thank you for testing and reporting, Alex > Guenter > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv >
WARNING: multiple messages have this Message-ID (diff)
From: Alex Ghiti <alex@ghiti.fr> To: Guenter Roeck <linux@roeck-us.net> Cc: Jonathan Corbet <corbet@lwn.net>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Arnd Bergmann <arnd@arndb.de>, Andrey Ryabinin <aryabinin@virtuozzo.com>, Alexander Potapenko <glider@google.com>, Dmitry Vyukov <dvyukov@google.com>, linux-doc@vger.kernel.org, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, kasan-dev@googlegroups.com, linux-arch@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v4 1/3] riscv: Move kernel mapping outside of linear mapping Date: Sat, 17 Apr 2021 13:23:33 -0400 [thread overview] Message-ID: <8c23ed42-d8c7-70be-71d8-0eb74ace8e67@ghiti.fr> (raw) In-Reply-To: <20210416185139.GA42339@roeck-us.net> 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 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 <arnd@arndb.de> >> Signed-off-by: Alexandre Ghiti <alex@ghiti.fr> > > In next-20210416, when booting a riscv32 image in qemu, this patch results in: > > [ 0.000000] Linux version 5.12.0-rc7-next-20210416 (groeck@desktop) (riscv32-linux-gcc (GCC) 10.3.0, GNU ld (GNU Binutils) 2.36.1) #1 SMP Fri Apr 16 10:38:09 PDT 2021 > [ 0.000000] OF: fdt: Ignoring memory block 0x80000000 - 0xa0000000 > [ 0.000000] Machine model: riscv-virtio,qemu > [ 0.000000] earlycon: uart8250 at MMIO 0x10000000 (options '115200') > [ 0.000000] printk: bootconsole [uart8250] enabled > [ 0.000000] efi: UEFI not found. > [ 0.000000] Kernel panic - not syncing: init_resources: Failed to allocate 160 bytes > [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 5.12.0-rc7-next-20210416 #1 > [ 0.000000] Hardware name: riscv-virtio,qemu (DT) > [ 0.000000] Call Trace: > [ 0.000000] [<80005292>] walk_stackframe+0x0/0xce > [ 0.000000] [<809f4db8>] dump_backtrace+0x38/0x46 > [ 0.000000] [<809f4dd4>] show_stack+0xe/0x16 > [ 0.000000] [<809ff1d0>] dump_stack+0x92/0xc6 > [ 0.000000] [<809f4fee>] panic+0x10a/0x2d8 > [ 0.000000] [<80c02b24>] setup_arch+0x2a0/0x4ea > [ 0.000000] [<80c006b0>] start_kernel+0x90/0x628 > [ 0.000000] ---[ end Kernel panic - not syncing: init_resources: Failed to allocate 160 bytes ]--- > > Reverting it fixes the problem. I understand that the version in -next is > different to this version of the patch, but I also tried v4 and it still > crashes with the same error message. > I completely neglected 32b kernel in this series, I fixed that here: Thank you for testing and reporting, Alex > Guenter > > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv > _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2021-04-17 17:23 UTC|newest] Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-04-09 6:14 [PATCH v4 0/3] Move kernel mapping outside the linear mapping Alexandre Ghiti 2021-04-09 6:14 ` Alexandre Ghiti 2021-04-09 6:14 ` [PATCH v4 1/3] riscv: Move kernel mapping outside of " Alexandre Ghiti 2021-04-09 6:14 ` Alexandre Ghiti 2021-04-16 18:51 ` Guenter Roeck 2021-04-16 18:51 ` Guenter Roeck 2021-04-17 17:23 ` Alex Ghiti [this message] 2021-04-17 17:23 ` Alex Ghiti 2021-04-09 6:14 ` [PATCH v4 2/3] Documentation: riscv: Add documentation that describes the VM layout Alexandre Ghiti 2021-04-09 6:14 ` Alexandre Ghiti 2021-04-09 6:15 ` [PATCH v4 3/3] riscv: Prepare ptdump for vm layout dynamic addresses Alexandre Ghiti 2021-04-09 6:15 ` Alexandre Ghiti 2021-04-09 10:48 ` kernel test robot
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8c23ed42-d8c7-70be-71d8-0eb74ace8e67@ghiti.fr \ --to=alex@ghiti.fr \ --cc=aou@eecs.berkeley.edu \ --cc=arnd@arndb.de \ --cc=aryabinin@virtuozzo.com \ --cc=corbet@lwn.net \ --cc=dvyukov@google.com \ --cc=glider@google.com \ --cc=kasan-dev@googlegroups.com \ --cc=linux-arch@vger.kernel.org \ --cc=linux-doc@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linux-riscv@lists.infradead.org \ --cc=linux@roeck-us.net \ --cc=palmer@dabbelt.com \ --cc=paul.walmsley@sifive.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.