From: "Björn Töpel" <bjorn@kernel.org>
To: Alexandre Ghiti <alexghiti@rivosinc.com>
Cc: "Albert Ou" <aou@eecs.berkeley.edu>,
"David Hildenbrand" <david@redhat.com>,
"Palmer Dabbelt" <palmer@dabbelt.com>,
"Paul Walmsley" <paul.walmsley@sifive.com>,
linux-riscv@lists.infradead.org,
"Björn Töpel" <bjorn@rivosinc.com>,
"Andrew Bresticker" <abrestic@rivosinc.com>,
"Chethan Seshadri" <Chethan.Seshadri@catalinasystems.io>,
"Lorenzo Stoakes" <lstoakes@gmail.com>,
"Oscar Salvador" <osalvador@suse.de>,
"Santosh Mamila" <santosh.mamila@catalinasystems.io>,
"Sivakumar Munnangi" <siva.munnangi@catalinasystems.io>,
"Sunil V L" <sunilvl@ventanamicro.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v2 1/8] riscv: mm: Pre-allocate vmemmap/direct map PGD entries
Date: Tue, 14 May 2024 18:33:09 +0200 [thread overview]
Message-ID: <87wmnwtku2.fsf@all.your.base.are.belong.to.us> (raw)
In-Reply-To: <CAHVXubhfsvDZrw_Cvg8AnEm00P0TQvrSOV_jVSBRckmJLp6EFQ@mail.gmail.com>
Alexandre Ghiti <alexghiti@rivosinc.com> writes:
> Hi Björn,
>
> On Tue, May 14, 2024 at 4:05 PM Björn Töpel <bjorn@kernel.org> wrote:
>>
>> From: Björn Töpel <bjorn@rivosinc.com>
>>
>> The RISC-V port copies the PGD table from init_mm/swapper_pg_dir to
>> all userland page tables, which means that if the PGD level table is
>> changed, other page tables has to be updated as well.
>>
>> Instead of having the PGD changes ripple out to all tables, the
>> synchronization can be avoided by pre-allocating the PGD entries/pages
>> at boot, avoiding the synchronization all together.
>>
>> This is currently done for the bpf/modules, and vmalloc PGD regions.
>> Extend this scheme for the PGD regions touched by memory hotplugging.
>>
>> Prepare the RISC-V port for memory hotplug by pre-allocate
>> vmemmap/direct map entries at the PGD level. This will roughly waste
>> ~128 worth of 4K pages when memory hotplugging is enabled in the
>> kernel configuration.
>>
>> Signed-off-by: Björn Töpel <bjorn@rivosinc.com>
>> ---
>> arch/riscv/include/asm/kasan.h | 4 ++--
>> arch/riscv/mm/init.c | 7 +++++++
>> 2 files changed, 9 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/riscv/include/asm/kasan.h b/arch/riscv/include/asm/kasan.h
>> index 0b85e363e778..e6a0071bdb56 100644
>> --- a/arch/riscv/include/asm/kasan.h
>> +++ b/arch/riscv/include/asm/kasan.h
>> @@ -6,8 +6,6 @@
>>
>> #ifndef __ASSEMBLY__
>>
>> -#ifdef CONFIG_KASAN
>> -
>> /*
>> * The following comment was copied from arm64:
>> * KASAN_SHADOW_START: beginning of the kernel virtual addresses.
>> @@ -34,6 +32,8 @@
>> */
>> #define KASAN_SHADOW_START ((KASAN_SHADOW_END - KASAN_SHADOW_SIZE) & PGDIR_MASK)
>> #define KASAN_SHADOW_END MODULES_LOWEST_VADDR
>> +
>> +#ifdef CONFIG_KASAN
>> #define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL)
>>
>> void kasan_init(void);
>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c
>> index 2574f6a3b0e7..5b8cdfafb52a 100644
>> --- a/arch/riscv/mm/init.c
>> +++ b/arch/riscv/mm/init.c
>> @@ -27,6 +27,7 @@
>>
>> #include <asm/fixmap.h>
>> #include <asm/io.h>
>> +#include <asm/kasan.h>
>> #include <asm/numa.h>
>> #include <asm/pgtable.h>
>> #include <asm/sections.h>
>> @@ -1488,10 +1489,16 @@ static void __init preallocate_pgd_pages_range(unsigned long start, unsigned lon
>> panic("Failed to pre-allocate %s pages for %s area\n", lvl, area);
>> }
>>
>> +#define PAGE_END KASAN_SHADOW_START
>> +
>> void __init pgtable_cache_init(void)
>> {
>> preallocate_pgd_pages_range(VMALLOC_START, VMALLOC_END, "vmalloc");
>> if (IS_ENABLED(CONFIG_MODULES))
>> preallocate_pgd_pages_range(MODULES_VADDR, MODULES_END, "bpf/modules");
>> + if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG)) {
>> + preallocate_pgd_pages_range(VMEMMAP_START, VMEMMAP_END, "vmemmap");
>> + preallocate_pgd_pages_range(PAGE_OFFSET, PAGE_END, "direct map");
>> + }
>> }
>> #endif
>> --
>> 2.40.1
>>
>
> As you asked, with
> https://lore.kernel.org/linux-riscv/20240514133614.87813-1-alexghiti@rivosinc.com/T/#u,
> you will be able to remove the usage of KASAN_SHADOW_START.
Very nice -- consistency! I'll need to respin, so I'll clean this up for
the next version.
> But anyhow, you can add:
>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
Thank you!
Björn
next prev parent reply other threads:[~2024-05-14 16:33 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-14 14:04 [PATCH v2 0/8] riscv: Memory Hot(Un)Plug support Björn Töpel
2024-05-14 14:04 ` [PATCH v2 1/8] riscv: mm: Pre-allocate vmemmap/direct map PGD entries Björn Töpel
2024-05-14 15:57 ` Alexandre Ghiti
2024-05-14 16:33 ` Björn Töpel [this message]
2024-05-14 14:04 ` [PATCH v2 2/8] riscv: mm: Change attribute from __init to __meminit for page functions Björn Töpel
2024-05-14 15:59 ` David Hildenbrand
2024-05-14 17:17 ` Alexandre Ghiti
2024-05-14 17:45 ` Björn Töpel
2024-05-14 20:32 ` Oscar Salvador
2024-05-15 5:39 ` Björn Töpel
2024-05-14 14:04 ` [PATCH v2 3/8] riscv: mm: Refactor create_linear_mapping_range() for memory hot add Björn Töpel
2024-05-14 16:00 ` David Hildenbrand
2024-05-14 17:24 ` Alexandre Ghiti
2024-05-14 20:37 ` Oscar Salvador
2024-05-14 14:04 ` [PATCH v2 4/8] riscv: mm: Add memory hotplugging support Björn Töpel
2024-05-14 16:04 ` David Hildenbrand
2024-05-14 16:34 ` Björn Töpel
2024-05-14 17:49 ` Alexandre Ghiti
2024-05-14 19:31 ` Björn Töpel
2024-05-14 20:49 ` Oscar Salvador
2024-05-15 5:41 ` Björn Töpel
2024-05-14 14:04 ` [PATCH v2 5/8] riscv: mm: Take memory hotplug read-lock during kernel page table dump Björn Töpel
2024-05-14 20:39 ` David Hildenbrand
2024-05-14 21:03 ` Oscar Salvador
2024-05-14 14:04 ` [PATCH v2 6/8] riscv: Enable memory hotplugging for RISC-V Björn Töpel
2024-05-14 18:00 ` Alexandre Ghiti
2024-05-14 18:17 ` Björn Töpel
2024-05-14 18:41 ` Alexandre Ghiti
2024-05-14 20:40 ` David Hildenbrand
2024-05-14 21:06 ` Oscar Salvador
2024-05-14 14:04 ` [PATCH v2 7/8] virtio-mem: Enable virtio-mem " Björn Töpel
2024-05-14 15:58 ` David Hildenbrand
2024-05-14 14:04 ` [PATCH v2 8/8] riscv: mm: Add support for ZONE_DEVICE Björn Töpel
2024-05-15 7:03 ` Björn Töpel
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=87wmnwtku2.fsf@all.your.base.are.belong.to.us \
--to=bjorn@kernel.org \
--cc=Chethan.Seshadri@catalinasystems.io \
--cc=abrestic@rivosinc.com \
--cc=alexghiti@rivosinc.com \
--cc=aou@eecs.berkeley.edu \
--cc=bjorn@rivosinc.com \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=lstoakes@gmail.com \
--cc=osalvador@suse.de \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=santosh.mamila@catalinasystems.io \
--cc=siva.munnangi@catalinasystems.io \
--cc=sunilvl@ventanamicro.com \
--cc=virtualization@lists.linux-foundation.org \
/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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox