Message ID | 20230316131711.1284451-1-alexghiti@rivosinc.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp482548wrt; Thu, 16 Mar 2023 06:29:26 -0700 (PDT) X-Google-Smtp-Source: AK7set8wLlhquk4BCeXG5dG6i5B0JwuXDGxofD593e1+2RvFTuLhuH6rI189SjW3POZgJndvuNtj X-Received: by 2002:a17:903:186:b0:19e:6d83:8277 with SMTP id z6-20020a170903018600b0019e6d838277mr3794876plg.51.1678973366004; Thu, 16 Mar 2023 06:29:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678973365; cv=none; d=google.com; s=arc-20160816; b=JN65/kPYEJGFdOBdwvl+z1gOAvy/jA5uTQ7BBrpS8cAzvnQda4hbxrcW6T2wZ3TcHU HGCpuQQGE7bKxXVKsc/Xev8BUeyYQu8aDu3X4I+N+XbzBZlnAj7jivPOfHXM7Qp3n+O8 +I7zrHtRABOKWEPKVkatYZ8EVjMBzaU3sLzDXLmaE/KRQDehTNX8vzzYymY0cIDQmxak wYTC776GTDFa0Ke04xLnqInhat4amnI/cofkDGoOsltzV5sUl7TVvV1pwnCJjv6lyeoz MOLpNNZGBeqPnXu9rMRFuSLp71wi0FicPT5jlPM1zJQKDXDg3G8FTZzaWKHAOxHKfpNB 9p6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=yb0JNi6cRDb5cM5WC9CEwD00CUTLKwtDAX0RcxE9c8c=; b=YFd6TXcYFxnNr0LPnOTgKm619hH3OYnrpqtc13iXsg69NOkQVv/gTzsHYaoFZSIDX2 KTKMb+p4p1VAnEs8pisBpHwgA6/gZJIk0Gv5Czj9nPSeXwKHOqKSnYsxgVE3bMBGDs8A mts6xSGZNBMKdP7fitGs34L9x+mh4qo3+dsz5s7x2Pb/eZhEZu/anWPCpGeBWe0P8C9z nS3EJZkshGyBopEe84PqcbaOgoiYvU2L/HX6haMOfFkl9FgmdkHUMtm1STcNT31XNEbP 6AMwOEiQsZrCEzCJHdtQ7bqgsUAz3m93FrAXIKWsGKpmLaa67qJ1UgK7grpAfCqQl+39 zYxQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=2Ev7aL6Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id b2-20020a170903228200b0019e88453482si439940plh.306.2023.03.16.06.29.13; Thu, 16 Mar 2023 06:29:25 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=2Ev7aL6Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230252AbjCPNSF (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Thu, 16 Mar 2023 09:18:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230098AbjCPNRr (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 16 Mar 2023 09:17:47 -0400 Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B23D4CC30F for <linux-kernel@vger.kernel.org>; Thu, 16 Mar 2023 06:17:18 -0700 (PDT) Received: by mail-wm1-x334.google.com with SMTP id fm20-20020a05600c0c1400b003ead37e6588so3143343wmb.5 for <linux-kernel@vger.kernel.org>; Thu, 16 Mar 2023 06:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1678972636; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=yb0JNi6cRDb5cM5WC9CEwD00CUTLKwtDAX0RcxE9c8c=; b=2Ev7aL6Z6zhWHuGqPE5WRugL+grtCgf1Rw+DE5yPncJqWsJZHaCBhlqpfyHHzrwI1D IUpoT5Oj2+AxeGLsJn0E0MGbjKM4v8gxIxDStGUIXy02nc+EgqABDoYG/hOTYXCiYSOG iJXRweRTFhgYGpwr8xQprpP8UgTS76aclNF9Q88Vn0eLPUVtmLtJpd6cV7LoVTHbBvrh 1q5XhWPVPnaXpKPzJ2vWiPfcyS8XnUsHIEUE5rYpgUMCG70N6PMSUo4+vx3GXuGIPvt/ V4QCyObIV+J3zkqwYafQgaQwhM6mcbbbhcaBTGh3Ec5hqKIhtCwzq3Y8iM8EHnAJ0VUh gAdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678972636; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yb0JNi6cRDb5cM5WC9CEwD00CUTLKwtDAX0RcxE9c8c=; b=WbsvDofOg6mkjiKPWURz18FSdBiZtfTuZpTLa7iS+WjNr+HZJ4mpA8QDm+I69e/NUW 2qovvAoAfJMGpAAjCoaeQ+dL67gO+FM+F1nejQR9yu8lUkB2WgtGBWZ8P/sAWoiAjm9l 0iNeuf1SO0IqyDKEbuTdwnpqaNl3hbaz03eiA2JPH+ljirFk2rscyKKraIHXlueyn9Bo qfcl6LJq/8qugzaDbx2TNNMMsGrhhGqcI+eesOgbTzt5y9K9NOQsZH3yN6wfq0B8Txz+ s4EjSPP5+E2T7fdEWiso1fwACPYG0aZTVmi1vukc5NS20vbQQJ2UVPnAXf37B287nIkF P3Ew== X-Gm-Message-State: AO0yUKUmK3gb0R1DCqiMLMmu21qc/ydEWKJ3xNtUjZnWIC7xugDtGtIH BLWBbSB5XBp+Hm41w6M4vRa0ww== X-Received: by 2002:a7b:ca41:0:b0:3ea:f75d:4626 with SMTP id m1-20020a7bca41000000b003eaf75d4626mr21011181wml.38.1678972636633; Thu, 16 Mar 2023 06:17:16 -0700 (PDT) Received: from alex-rivos.ba.rivosinc.com (238.174.185.81.rev.sfr.net. [81.185.174.238]) by smtp.gmail.com with ESMTPSA id a6-20020a1cf006000000b003ed4f6c6234sm1963364wmb.23.2023.03.16.06.17.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Mar 2023 06:17:16 -0700 (PDT) From: Alexandre Ghiti <alexghiti@rivosinc.com> To: Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Rob Herring <robh+dt@kernel.org>, Frank Rowand <frowand.list@gmail.com>, Mike Rapoport <rppt@kernel.org>, Andrew Morton <akpm@linux-foundation.org>, Anup Patel <anup@brainfault.org>, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-mm@kvack.org Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Subject: [PATCH v8 0/4] riscv: Use PUD/P4D/PGD pages for the linear mapping Date: Thu, 16 Mar 2023 14:17:07 +0100 Message-Id: <20230316131711.1284451-1-alexghiti@rivosinc.com> X-Mailer: git-send-email 2.37.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760531176129429604?= X-GMAIL-MSGID: =?utf-8?q?1760531176129429604?= |
Series |
riscv: Use PUD/P4D/PGD pages for the linear mapping
|
|
Message
Alexandre Ghiti
March 16, 2023, 1:17 p.m. UTC
This patchset intends to improve tlb utilization by using hugepages for the linear mapping. As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must take care of isolating the kernel text and rodata so that they are not mapped with a PUD mapping which would then assign wrong permissions to the whole region: it is achieved by introducing a new memblock API. Another patch makes use of this new API in arm64 which used some sort of hack to solve this issue: it was built/boot tested successfully. base-commit-tag: v6.3-rc1 v8: - Fix rv32, as reported by Anup - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew - Fix arm64 double mapping (which to me did not work in v7), but ends up not being pretty at all, will wait for comments from arm64 reviewers, but this patch can easily be dropped if they do not want it. v7: - Fix Anup bug report by introducing memblock_isolate_memory which allows us to split the memblock mappings and then avoid to map the the PUD which contains the kernel as read only - Add a patch to arm64 to use this newly introduced API v6: - quiet LLVM warning by casting phys_ram_base into an unsigned long v5: - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks Conor - Add RB from Andrew v4: - Rebase on top of v6.2-rc3, as noted by Conor - Add Acked-by Rob v3: - Change the comment about initrd_start VA conversion so that it fits ARM64 and RISCV64 (and others in the future if needed), as suggested by Rob v2: - Add a comment on why RISCV64 does not need to set initrd_start/end that early in the boot process, as asked by Rob Alexandre Ghiti (4): riscv: Get rid of riscv_pfn_base variable mm: Introduce memblock_isolate_memory arm64: Make use of memblock_isolate_memory for the linear mapping riscv: Use PUD/P4D/PGD pages for the linear mapping arch/arm64/mm/mmu.c | 25 +++++++++++------ arch/riscv/include/asm/page.h | 19 +++++++++++-- arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- arch/riscv/mm/physaddr.c | 16 +++++++++++ drivers/of/fdt.c | 11 ++++---- include/linux/memblock.h | 1 + mm/memblock.c | 20 +++++++++++++ 7 files changed, 119 insertions(+), 26 deletions(-)
Comments
Hi Alex, On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > This patchset intends to improve tlb utilization by using hugepages for > the linear mapping. > > As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must > take care of isolating the kernel text and rodata so that they are not > mapped with a PUD mapping which would then assign wrong permissions to > the whole region: it is achieved by introducing a new memblock API. > > Another patch makes use of this new API in arm64 which used some sort of > hack to solve this issue: it was built/boot tested successfully. > > base-commit-tag: v6.3-rc1 > > v8: > - Fix rv32, as reported by Anup > - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike > - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew > - Fix arm64 double mapping (which to me did not work in v7), but ends up not > being pretty at all, will wait for comments from arm64 reviewers, but > this patch can easily be dropped if they do not want it. > > v7: > - Fix Anup bug report by introducing memblock_isolate_memory which > allows us to split the memblock mappings and then avoid to map the > the PUD which contains the kernel as read only > - Add a patch to arm64 to use this newly introduced API > > v6: > - quiet LLVM warning by casting phys_ram_base into an unsigned long > > v5: > - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks > Conor > - Add RB from Andrew > > v4: > - Rebase on top of v6.2-rc3, as noted by Conor > - Add Acked-by Rob > > v3: > - Change the comment about initrd_start VA conversion so that it fits > ARM64 and RISCV64 (and others in the future if needed), as suggested > by Rob > > v2: > - Add a comment on why RISCV64 does not need to set initrd_start/end that > early in the boot process, as asked by Rob > > Alexandre Ghiti (4): > riscv: Get rid of riscv_pfn_base variable > mm: Introduce memblock_isolate_memory > arm64: Make use of memblock_isolate_memory for the linear mapping > riscv: Use PUD/P4D/PGD pages for the linear mapping Kernel boot fine on RV64 but there is a failure which is still not addressed. You can see this failure as following message in kernel boot log: 0.000000] Failed to add a System RAM resource at 80200000 Regards, Anup > > arch/arm64/mm/mmu.c | 25 +++++++++++------ > arch/riscv/include/asm/page.h | 19 +++++++++++-- > arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- > arch/riscv/mm/physaddr.c | 16 +++++++++++ > drivers/of/fdt.c | 11 ++++---- > include/linux/memblock.h | 1 + > mm/memblock.c | 20 +++++++++++++ > 7 files changed, 119 insertions(+), 26 deletions(-) > > -- > 2.37.2 >
Hi Anup, On Thu, Mar 23, 2023 at 1:18 PM Anup Patel <apatel@ventanamicro.com> wrote: > > Hi Alex, > > On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > > > This patchset intends to improve tlb utilization by using hugepages for > > the linear mapping. > > > > As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must > > take care of isolating the kernel text and rodata so that they are not > > mapped with a PUD mapping which would then assign wrong permissions to > > the whole region: it is achieved by introducing a new memblock API. > > > > Another patch makes use of this new API in arm64 which used some sort of > > hack to solve this issue: it was built/boot tested successfully. > > > > base-commit-tag: v6.3-rc1 > > > > v8: > > - Fix rv32, as reported by Anup > > - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike > > - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew > > - Fix arm64 double mapping (which to me did not work in v7), but ends up not > > being pretty at all, will wait for comments from arm64 reviewers, but > > this patch can easily be dropped if they do not want it. > > > > v7: > > - Fix Anup bug report by introducing memblock_isolate_memory which > > allows us to split the memblock mappings and then avoid to map the > > the PUD which contains the kernel as read only > > - Add a patch to arm64 to use this newly introduced API > > > > v6: > > - quiet LLVM warning by casting phys_ram_base into an unsigned long > > > > v5: > > - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks > > Conor > > - Add RB from Andrew > > > > v4: > > - Rebase on top of v6.2-rc3, as noted by Conor > > - Add Acked-by Rob > > > > v3: > > - Change the comment about initrd_start VA conversion so that it fits > > ARM64 and RISCV64 (and others in the future if needed), as suggested > > by Rob > > > > v2: > > - Add a comment on why RISCV64 does not need to set initrd_start/end that > > early in the boot process, as asked by Rob > > > > Alexandre Ghiti (4): > > riscv: Get rid of riscv_pfn_base variable > > mm: Introduce memblock_isolate_memory > > arm64: Make use of memblock_isolate_memory for the linear mapping > > riscv: Use PUD/P4D/PGD pages for the linear mapping > > Kernel boot fine on RV64 but there is a failure which is still not > addressed. You can see this failure as following message in > kernel boot log: > 0.000000] Failed to add a System RAM resource at 80200000 Hmmm I don't get that in any of my test configs, would you mind sharing yours and your qemu command line? Thanks > > Regards, > Anup > > > > > arch/arm64/mm/mmu.c | 25 +++++++++++------ > > arch/riscv/include/asm/page.h | 19 +++++++++++-- > > arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- > > arch/riscv/mm/physaddr.c | 16 +++++++++++ > > drivers/of/fdt.c | 11 ++++---- > > include/linux/memblock.h | 1 + > > mm/memblock.c | 20 +++++++++++++ > > 7 files changed, 119 insertions(+), 26 deletions(-) > > > > -- > > 2.37.2 > >
On Thu, Mar 23, 2023 at 6:24 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > Hi Anup, > > On Thu, Mar 23, 2023 at 1:18 PM Anup Patel <apatel@ventanamicro.com> wrote: > > > > Hi Alex, > > > > On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > > > > > This patchset intends to improve tlb utilization by using hugepages for > > > the linear mapping. > > > > > > As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must > > > take care of isolating the kernel text and rodata so that they are not > > > mapped with a PUD mapping which would then assign wrong permissions to > > > the whole region: it is achieved by introducing a new memblock API. > > > > > > Another patch makes use of this new API in arm64 which used some sort of > > > hack to solve this issue: it was built/boot tested successfully. > > > > > > base-commit-tag: v6.3-rc1 > > > > > > v8: > > > - Fix rv32, as reported by Anup > > > - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike > > > - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew > > > - Fix arm64 double mapping (which to me did not work in v7), but ends up not > > > being pretty at all, will wait for comments from arm64 reviewers, but > > > this patch can easily be dropped if they do not want it. > > > > > > v7: > > > - Fix Anup bug report by introducing memblock_isolate_memory which > > > allows us to split the memblock mappings and then avoid to map the > > > the PUD which contains the kernel as read only > > > - Add a patch to arm64 to use this newly introduced API > > > > > > v6: > > > - quiet LLVM warning by casting phys_ram_base into an unsigned long > > > > > > v5: > > > - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks > > > Conor > > > - Add RB from Andrew > > > > > > v4: > > > - Rebase on top of v6.2-rc3, as noted by Conor > > > - Add Acked-by Rob > > > > > > v3: > > > - Change the comment about initrd_start VA conversion so that it fits > > > ARM64 and RISCV64 (and others in the future if needed), as suggested > > > by Rob > > > > > > v2: > > > - Add a comment on why RISCV64 does not need to set initrd_start/end that > > > early in the boot process, as asked by Rob > > > > > > Alexandre Ghiti (4): > > > riscv: Get rid of riscv_pfn_base variable > > > mm: Introduce memblock_isolate_memory > > > arm64: Make use of memblock_isolate_memory for the linear mapping > > > riscv: Use PUD/P4D/PGD pages for the linear mapping > > > > Kernel boot fine on RV64 but there is a failure which is still not > > addressed. You can see this failure as following message in > > kernel boot log: > > 0.000000] Failed to add a System RAM resource at 80200000 > > Hmmm I don't get that in any of my test configs, would you mind > sharing yours and your qemu command line? Try alexghiti_test branch at https://github.com/avpatel/linux.git I am building the kernel using defconfig and my rootfs is based on busybox. My QEMU command is: qemu-system-riscv64 -M virt -m 512M -nographic -bios opensbi/build/platform/generic/firmware/fw_dynamic.bin -kernel ./build-riscv64/arch/riscv/boot/Image -append "root=/dev/ram rw console=ttyS0 earlycon" -initrd ./rootfs_riscv64.img -smp 4 Regards, Anup > > Thanks > > > > > Regards, > > Anup > > > > > > > > arch/arm64/mm/mmu.c | 25 +++++++++++------ > > > arch/riscv/include/asm/page.h | 19 +++++++++++-- > > > arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- > > > arch/riscv/mm/physaddr.c | 16 +++++++++++ > > > drivers/of/fdt.c | 11 ++++---- > > > include/linux/memblock.h | 1 + > > > mm/memblock.c | 20 +++++++++++++ > > > 7 files changed, 119 insertions(+), 26 deletions(-) > > > > > > -- > > > 2.37.2 > > >
On 3/23/23 15:55, Anup Patel wrote: > On Thu, Mar 23, 2023 at 6:24 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: >> Hi Anup, >> >> On Thu, Mar 23, 2023 at 1:18 PM Anup Patel <apatel@ventanamicro.com> wrote: >>> Hi Alex, >>> >>> On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: >>>> This patchset intends to improve tlb utilization by using hugepages for >>>> the linear mapping. >>>> >>>> As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must >>>> take care of isolating the kernel text and rodata so that they are not >>>> mapped with a PUD mapping which would then assign wrong permissions to >>>> the whole region: it is achieved by introducing a new memblock API. >>>> >>>> Another patch makes use of this new API in arm64 which used some sort of >>>> hack to solve this issue: it was built/boot tested successfully. >>>> >>>> base-commit-tag: v6.3-rc1 >>>> >>>> v8: >>>> - Fix rv32, as reported by Anup >>>> - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike >>>> - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew >>>> - Fix arm64 double mapping (which to me did not work in v7), but ends up not >>>> being pretty at all, will wait for comments from arm64 reviewers, but >>>> this patch can easily be dropped if they do not want it. >>>> >>>> v7: >>>> - Fix Anup bug report by introducing memblock_isolate_memory which >>>> allows us to split the memblock mappings and then avoid to map the >>>> the PUD which contains the kernel as read only >>>> - Add a patch to arm64 to use this newly introduced API >>>> >>>> v6: >>>> - quiet LLVM warning by casting phys_ram_base into an unsigned long >>>> >>>> v5: >>>> - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks >>>> Conor >>>> - Add RB from Andrew >>>> >>>> v4: >>>> - Rebase on top of v6.2-rc3, as noted by Conor >>>> - Add Acked-by Rob >>>> >>>> v3: >>>> - Change the comment about initrd_start VA conversion so that it fits >>>> ARM64 and RISCV64 (and others in the future if needed), as suggested >>>> by Rob >>>> >>>> v2: >>>> - Add a comment on why RISCV64 does not need to set initrd_start/end that >>>> early in the boot process, as asked by Rob >>>> >>>> Alexandre Ghiti (4): >>>> riscv: Get rid of riscv_pfn_base variable >>>> mm: Introduce memblock_isolate_memory >>>> arm64: Make use of memblock_isolate_memory for the linear mapping >>>> riscv: Use PUD/P4D/PGD pages for the linear mapping >>> Kernel boot fine on RV64 but there is a failure which is still not >>> addressed. You can see this failure as following message in >>> kernel boot log: >>> 0.000000] Failed to add a System RAM resource at 80200000 >> Hmmm I don't get that in any of my test configs, would you mind >> sharing yours and your qemu command line? > Try alexghiti_test branch at > https://github.com/avpatel/linux.git > > I am building the kernel using defconfig and my rootfs is > based on busybox. > > My QEMU command is: > qemu-system-riscv64 -M virt -m 512M -nographic -bios > opensbi/build/platform/generic/firmware/fw_dynamic.bin -kernel > ./build-riscv64/arch/riscv/boot/Image -append "root=/dev/ram rw > console=ttyS0 earlycon" -initrd ./rootfs_riscv64.img -smp 4 So splitting memblock.memory is the culprit, it "confuses" the resources addition and I can only find hacky ways to fix that... So given that the arm64 patch with the new API is not pretty and that the simplest solution is to re-merge the memblock regions afterwards (which is done by memblock_clear_nomap), I'll drop the new API and the arm64 patch to use the nomap API like arm64: I'll take advantage of that to clean setup_vm_final which I have wanted to do for a long time. @Mike Thanks for you reviews! @Anup Thanks for all your bug reports on this patchset, I have to improve my test flow (it is in the work :)). > Regards, > Anup > >> Thanks >> >>> Regards, >>> Anup >>> >>>> arch/arm64/mm/mmu.c | 25 +++++++++++------ >>>> arch/riscv/include/asm/page.h | 19 +++++++++++-- >>>> arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- >>>> arch/riscv/mm/physaddr.c | 16 +++++++++++ >>>> drivers/of/fdt.c | 11 ++++---- >>>> include/linux/memblock.h | 1 + >>>> mm/memblock.c | 20 +++++++++++++ >>>> 7 files changed, 119 insertions(+), 26 deletions(-) >>>> >>>> -- >>>> 2.37.2 >>>> > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv
> On 3/23/23 15:55, Anup Patel wrote: > > On Thu, Mar 23, 2023 at 6:24 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > >> Hi Anup, > >> > >> On Thu, Mar 23, 2023 at 1:18 PM Anup Patel <apatel@ventanamicro.com> wrote: > >>> Hi Alex, > >>> > >>> On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > >>>> This patchset intends to improve tlb utilization by using hugepages for > >>>> the linear mapping. > >>>> > >>>> As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must > >>>> take care of isolating the kernel text and rodata so that they are not > >>>> mapped with a PUD mapping which would then assign wrong permissions to > >>>> the whole region: it is achieved by introducing a new memblock API. > >>>> > >>>> Another patch makes use of this new API in arm64 which used some sort of > >>>> hack to solve this issue: it was built/boot tested successfully. > >>>> > >>>> base-commit-tag: v6.3-rc1 > >>>> > >>>> v8: > >>>> - Fix rv32, as reported by Anup > >>>> - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike > >>>> - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew > >>>> - Fix arm64 double mapping (which to me did not work in v7), but ends up not > >>>> being pretty at all, will wait for comments from arm64 reviewers, but > >>>> this patch can easily be dropped if they do not want it. > >>>> > >>>> v7: > >>>> - Fix Anup bug report by introducing memblock_isolate_memory which > >>>> allows us to split the memblock mappings and then avoid to map the > >>>> the PUD which contains the kernel as read only > >>>> - Add a patch to arm64 to use this newly introduced API > >>>> > >>>> v6: > >>>> - quiet LLVM warning by casting phys_ram_base into an unsigned long > >>>> > >>>> v5: > >>>> - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks > >>>> Conor > >>>> - Add RB from Andrew > >>>> > >>>> v4: > >>>> - Rebase on top of v6.2-rc3, as noted by Conor > >>>> - Add Acked-by Rob > >>>> > >>>> v3: > >>>> - Change the comment about initrd_start VA conversion so that it fits > >>>> ARM64 and RISCV64 (and others in the future if needed), as suggested > >>>> by Rob > >>>> > >>>> v2: > >>>> - Add a comment on why RISCV64 does not need to set initrd_start/end that > >>>> early in the boot process, as asked by Rob > >>>> > >>>> Alexandre Ghiti (4): > >>>> riscv: Get rid of riscv_pfn_base variable > >>>> mm: Introduce memblock_isolate_memory > >>>> arm64: Make use of memblock_isolate_memory for the linear mapping > >>>> riscv: Use PUD/P4D/PGD pages for the linear mapping > >>> Kernel boot fine on RV64 but there is a failure which is still not > >>> addressed. You can see this failure as following message in > >>> kernel boot log: > >>> 0.000000] Failed to add a System RAM resource at 80200000 > >> Hmmm I don't get that in any of my test configs, would you mind > >> sharing yours and your qemu command line? > > Try alexghiti_test branch at > > https://github.com/avpatel/linux.git > > > > I am building the kernel using defconfig and my rootfs is > > based on busybox. > > > > My QEMU command is: > > qemu-system-riscv64 -M virt -m 512M -nographic -bios > > opensbi/build/platform/generic/firmware/fw_dynamic.bin -kernel > > ./build-riscv64/arch/riscv/boot/Image -append "root=/dev/ram rw > > console=ttyS0 earlycon" -initrd ./rootfs_riscv64.img -smp 4 > > > So splitting memblock.memory is the culprit, it "confuses" the resources > addition and I can only find hacky ways to fix that... Hi Alexandre, We encountered the same error as Anup. After adding your patch (3335068f87217ea59d08f462187dc856652eea15), we will not encounter the error again. What I have observed so far is - before your patch When merging consecutive memblocks, if the memblock types are different, they will be merged into reserved - after your patch When consecutive memblocks are merged, if the memblock types are different, they will be merged into memory. Such a result will cause the memory location of OpenSBI to be changed from reserved to memory. Will this have any side effects? > > So given that the arm64 patch with the new API is not pretty and that > the simplest solution is to re-merge the memblock regions afterwards > (which is done by memblock_clear_nomap), I'll drop the new API and the > arm64 patch to use the nomap API like arm64: I'll take advantage of that > to clean setup_vm_final which I have wanted to do for a long time. > > @Mike Thanks for you reviews! > > @Anup Thanks for all your bug reports on this patchset, I have to > improve my test flow (it is in the work :)). > > > > Regards, > > Anup > > > >> Thanks > >> > >>> Regards, > >>> Anup > >>> > >>>> arch/arm64/mm/mmu.c | 25 +++++++++++------ > >>>> arch/riscv/include/asm/page.h | 19 +++++++++++-- > >>>> arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- > >>>> arch/riscv/mm/physaddr.c | 16 +++++++++++ > >>>> drivers/of/fdt.c | 11 ++++---- > >>>> include/linux/memblock.h | 1 + > >>>> mm/memblock.c | 20 +++++++++++++ > >>>> 7 files changed, 119 insertions(+), 26 deletions(-) > >>>> > >>>> -- > >>>> 2.37.2 > >>>> > > _______________________________________________ > > 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
Hi Nylon, On Thu, Jan 18, 2024 at 9:23 AM Nylon Chen <nylon.chen@sifive.com> wrote: > > > On 3/23/23 15:55, Anup Patel wrote: > > > On Thu, Mar 23, 2023 at 6:24 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > >> Hi Anup, > > >> > > >> On Thu, Mar 23, 2023 at 1:18 PM Anup Patel <apatel@ventanamicro.com> wrote: > > >>> Hi Alex, > > >>> > > >>> On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > >>>> This patchset intends to improve tlb utilization by using hugepages for > > >>>> the linear mapping. > > >>>> > > >>>> As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must > > >>>> take care of isolating the kernel text and rodata so that they are not > > >>>> mapped with a PUD mapping which would then assign wrong permissions to > > >>>> the whole region: it is achieved by introducing a new memblock API. > > >>>> > > >>>> Another patch makes use of this new API in arm64 which used some sort of > > >>>> hack to solve this issue: it was built/boot tested successfully. > > >>>> > > >>>> base-commit-tag: v6.3-rc1 > > >>>> > > >>>> v8: > > >>>> - Fix rv32, as reported by Anup > > >>>> - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike > > >>>> - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew > > >>>> - Fix arm64 double mapping (which to me did not work in v7), but ends up not > > >>>> being pretty at all, will wait for comments from arm64 reviewers, but > > >>>> this patch can easily be dropped if they do not want it. > > >>>> > > >>>> v7: > > >>>> - Fix Anup bug report by introducing memblock_isolate_memory which > > >>>> allows us to split the memblock mappings and then avoid to map the > > >>>> the PUD which contains the kernel as read only > > >>>> - Add a patch to arm64 to use this newly introduced API > > >>>> > > >>>> v6: > > >>>> - quiet LLVM warning by casting phys_ram_base into an unsigned long > > >>>> > > >>>> v5: > > >>>> - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks > > >>>> Conor > > >>>> - Add RB from Andrew > > >>>> > > >>>> v4: > > >>>> - Rebase on top of v6.2-rc3, as noted by Conor > > >>>> - Add Acked-by Rob > > >>>> > > >>>> v3: > > >>>> - Change the comment about initrd_start VA conversion so that it fits > > >>>> ARM64 and RISCV64 (and others in the future if needed), as suggested > > >>>> by Rob > > >>>> > > >>>> v2: > > >>>> - Add a comment on why RISCV64 does not need to set initrd_start/end that > > >>>> early in the boot process, as asked by Rob > > >>>> > > >>>> Alexandre Ghiti (4): > > >>>> riscv: Get rid of riscv_pfn_base variable > > >>>> mm: Introduce memblock_isolate_memory > > >>>> arm64: Make use of memblock_isolate_memory for the linear mapping > > >>>> riscv: Use PUD/P4D/PGD pages for the linear mapping > > >>> Kernel boot fine on RV64 but there is a failure which is still not > > >>> addressed. You can see this failure as following message in > > >>> kernel boot log: > > >>> 0.000000] Failed to add a System RAM resource at 80200000 > > >> Hmmm I don't get that in any of my test configs, would you mind > > >> sharing yours and your qemu command line? > > > Try alexghiti_test branch at > > > https://github.com/avpatel/linux.git > > > > > > I am building the kernel using defconfig and my rootfs is > > > based on busybox. > > > > > > My QEMU command is: > > > qemu-system-riscv64 -M virt -m 512M -nographic -bios > > > opensbi/build/platform/generic/firmware/fw_dynamic.bin -kernel > > > ./build-riscv64/arch/riscv/boot/Image -append "root=/dev/ram rw > > > console=ttyS0 earlycon" -initrd ./rootfs_riscv64.img -smp 4 > > > > > > So splitting memblock.memory is the culprit, it "confuses" the resources > > addition and I can only find hacky ways to fix that... > Hi Alexandre, > > We encountered the same error as Anup. After adding your patch > (3335068f87217ea59d08f462187dc856652eea15), we will not encounter the > error again. > > What I have observed so far is > > - before your patch > When merging consecutive memblocks, if the memblock types are different, > they will be merged into reserved > - after your patch > When consecutive memblocks are merged, if the memblock types are > different, they will be merged into memory. > > Such a result will cause the memory location of OpenSBI to be changed > from reserved to memory. Will this have any side effects? I guess it will end up in the memory pool and pages from openSBI region will be allocated, so we should see very quickly bad stuff happening (either PMP violation or M-mode ecall never returning/trapping/etc). But I don't observe the same thing, I always see the openSBI region being reserved: reserved[0x0] [0x0000000080000000-0x000000008007ffff], 0x0000000000080000 bytes flags: 0x0 Can you elaborate a bit more about "When consecutive memblocks are merged, if the memblock types are different, they will be merged into memory"? Where/when does this merge happen? Can you give me a config file and a kernel revision so that I can take a look? Thanks, Alex > > > > So given that the arm64 patch with the new API is not pretty and that > > the simplest solution is to re-merge the memblock regions afterwards > > (which is done by memblock_clear_nomap), I'll drop the new API and the > > arm64 patch to use the nomap API like arm64: I'll take advantage of that > > to clean setup_vm_final which I have wanted to do for a long time. > > > > @Mike Thanks for you reviews! > > > > @Anup Thanks for all your bug reports on this patchset, I have to > > improve my test flow (it is in the work :)). > > > > > > > Regards, > > > Anup > > > > > >> Thanks > > >> > > >>> Regards, > > >>> Anup > > >>> > > >>>> arch/arm64/mm/mmu.c | 25 +++++++++++------ > > >>>> arch/riscv/include/asm/page.h | 19 +++++++++++-- > > >>>> arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- > > >>>> arch/riscv/mm/physaddr.c | 16 +++++++++++ > > >>>> drivers/of/fdt.c | 11 ++++---- > > >>>> include/linux/memblock.h | 1 + > > >>>> mm/memblock.c | 20 +++++++++++++ > > >>>> 7 files changed, 119 insertions(+), 26 deletions(-) > > >>>> > > >>>> -- > > >>>> 2.37.2 > > >>>> > > > _______________________________________________ > > > 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
Hi Nylon, On Fri, Jan 19, 2024 at 10:27 AM Nylon Chen <nylon.chen@sifive.com> wrote: > > Alexandre Ghiti <alexghiti@rivosinc.com> 於 2024年1月18日 週四 下午9:01寫道: > > > > Hi Nylon, > Hi Alexandre, thanks for your feedback, > > > > On Thu, Jan 18, 2024 at 9:23 AM Nylon Chen <nylon.chen@sifive.com> wrote: > > > > > > > On 3/23/23 15:55, Anup Patel wrote: > > > > > On Thu, Mar 23, 2023 at 6:24 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > > > >> Hi Anup, > > > > >> > > > > >> On Thu, Mar 23, 2023 at 1:18 PM Anup Patel <apatel@ventanamicro.com> wrote: > > > > >>> Hi Alex, > > > > >>> > > > > >>> On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti <alexghiti@rivosinc.com> wrote: > > > > >>>> This patchset intends to improve tlb utilization by using hugepages for > > > > >>>> the linear mapping. > > > > >>>> > > > > >>>> As reported by Anup in v6, when STRICT_KERNEL_RWX is enabled, we must > > > > >>>> take care of isolating the kernel text and rodata so that they are not > > > > >>>> mapped with a PUD mapping which would then assign wrong permissions to > > > > >>>> the whole region: it is achieved by introducing a new memblock API. > > > > >>>> > > > > >>>> Another patch makes use of this new API in arm64 which used some sort of > > > > >>>> hack to solve this issue: it was built/boot tested successfully. > > > > >>>> > > > > >>>> base-commit-tag: v6.3-rc1 > > > > >>>> > > > > >>>> v8: > > > > >>>> - Fix rv32, as reported by Anup > > > > >>>> - Do not modify memblock_isolate_range and fixes comment, as suggested by Mike > > > > >>>> - Use the new memblock API for crash kernel too in arm64, as suggested by Andrew > > > > >>>> - Fix arm64 double mapping (which to me did not work in v7), but ends up not > > > > >>>> being pretty at all, will wait for comments from arm64 reviewers, but > > > > >>>> this patch can easily be dropped if they do not want it. > > > > >>>> > > > > >>>> v7: > > > > >>>> - Fix Anup bug report by introducing memblock_isolate_memory which > > > > >>>> allows us to split the memblock mappings and then avoid to map the > > > > >>>> the PUD which contains the kernel as read only > > > > >>>> - Add a patch to arm64 to use this newly introduced API > > > > >>>> > > > > >>>> v6: > > > > >>>> - quiet LLVM warning by casting phys_ram_base into an unsigned long > > > > >>>> > > > > >>>> v5: > > > > >>>> - Fix nommu builds by getting rid of riscv_pfn_base in patch 1, thanks > > > > >>>> Conor > > > > >>>> - Add RB from Andrew > > > > >>>> > > > > >>>> v4: > > > > >>>> - Rebase on top of v6.2-rc3, as noted by Conor > > > > >>>> - Add Acked-by Rob > > > > >>>> > > > > >>>> v3: > > > > >>>> - Change the comment about initrd_start VA conversion so that it fits > > > > >>>> ARM64 and RISCV64 (and others in the future if needed), as suggested > > > > >>>> by Rob > > > > >>>> > > > > >>>> v2: > > > > >>>> - Add a comment on why RISCV64 does not need to set initrd_start/end that > > > > >>>> early in the boot process, as asked by Rob > > > > >>>> > > > > >>>> Alexandre Ghiti (4): > > > > >>>> riscv: Get rid of riscv_pfn_base variable > > > > >>>> mm: Introduce memblock_isolate_memory > > > > >>>> arm64: Make use of memblock_isolate_memory for the linear mapping > > > > >>>> riscv: Use PUD/P4D/PGD pages for the linear mapping > > > > >>> Kernel boot fine on RV64 but there is a failure which is still not > > > > >>> addressed. You can see this failure as following message in > > > > >>> kernel boot log: > > > > >>> 0.000000] Failed to add a System RAM resource at 80200000 > > > > >> Hmmm I don't get that in any of my test configs, would you mind > > > > >> sharing yours and your qemu command line? > > > > > Try alexghiti_test branch at > > > > > https://github.com/avpatel/linux.git > > > > > > > > > > I am building the kernel using defconfig and my rootfs is > > > > > based on busybox. > > > > > > > > > > My QEMU command is: > > > > > qemu-system-riscv64 -M virt -m 512M -nographic -bios > > > > > opensbi/build/platform/generic/firmware/fw_dynamic.bin -kernel > > > > > ./build-riscv64/arch/riscv/boot/Image -append "root=/dev/ram rw > > > > > console=ttyS0 earlycon" -initrd ./rootfs_riscv64.img -smp 4 > > > > > > > > > > > > So splitting memblock.memory is the culprit, it "confuses" the resources > > > > addition and I can only find hacky ways to fix that... > > > Hi Alexandre, > > > > > > We encountered the same error as Anup. After adding your patch > > > (3335068f87217ea59d08f462187dc856652eea15), we will not encounter the > > > error again. > > > > > > What I have observed so far is > > > > > > - before your patch > > > When merging consecutive memblocks, if the memblock types are different, > > > they will be merged into reserved > > > - after your patch > > > When consecutive memblocks are merged, if the memblock types are > > > different, they will be merged into memory. > > > > > > Such a result will cause the memory location of OpenSBI to be changed > > > from reserved to memory. Will this have any side effects? > > > > I guess it will end up in the memory pool and pages from openSBI > > region will be allocated, so we should see very quickly bad stuff > > happening (either PMP violation or M-mode ecall never > > returning/trapping/etc). > > > > But I don't observe the same thing, I always see the openSBI region > > being reserved: > > > > reserved[0x0] [0x0000000080000000-0x000000008007ffff], > > 0x0000000000080000 bytes flags: 0x0 > > > > Can you elaborate a bit more about "When consecutive memblocks are > > merged, if the memblock types are different, they will be merged into > > memory"? Where/when does this merge happen? Can you give me a config > > file and a kernel revision so that I can take a look? > Ok, If you want to reproduce the same results you just need to modify OpenSBI > > [ lib/sbi/sbi_domain.c ] > +#define TEST_SIZE 0x200000 > > - (scratch->fw_size - scratch->fw_rw_offset), > + (TEST_SIZE - scratch->fw_rw_offset), > > In addition, you can insert checks in the kernel merged function > [ mm/memblock.c ] > static void __init_memblock memblock_merge_regions(struct memblock_type *type) > while (i < type->cnt - 1) { > ... > /* move forward from next + 1, index of which is i + 2 */ > memmove(next, next + 1, (type->cnt - (i + 2)) * sizeof(*next)); > type->cnt--; > } > + pr_info("Merged memblock_type: cnt = %lu, max = %lu, > total_size = 0x%llx\n",type->cnt, type->max, type->total_size); > + for (i = 0; i < type->cnt; i++) { > + const char *region_type = > memblock_is_memory(type->regions[i].base) ? "memory" : "reserve"; > + pr_info("Region %d: base = 0x%llx, size = 0x%llx, type > = %s\n", i, type->regions[i].base, type->regions[i].size, > region_type); > + } > } > This is kernel boot log > - before your patch > ... > [ 0.000000] OF: fdt: Reserving memory: base = 0x80000000, size = 0x200000 > [ 0.000000] Merged memblock_type: cnt = 4, max = 128, total_size = 0x1628501 > [ 0.000000] Region 0: base = 0x80000000, size = 0x1600000, type = reserve > ... > > - after your patch > ... > [ 0.000000] OF: fdt: Reserving memory: base = 0x80000000, size = 0x200000 > [ 0.000000] Merged memblock_type: cnt = 4, max = 128, total_size = 0x180c42e > [ 0.000000] Region 0: base = 0x80000000, size = 0x1800000, type = memory So the openSBI region is marked as memory, and not reserved because this region is now described as nomap, and memblock_mark_nomap() does not move this region into the reserved memblock list, but keep it in the memory list with the nomap flag (https://elixir.bootlin.com/linux/latest/source/drivers/of/fdt.c#L479). But as stated in the description of memblock_mark_nomap() (https://elixir.bootlin.com/linux/latest/source/mm/memblock.c#L969), the pages associated with the region will be marked as PageReserved and the region will not be covered in the linear mapping. So to me, this is normal and we are safe. Let me know if I made a mistake. And sorry for the long delay, that slipped my mind! Thanks, Alex > ... > [ 0.000000] Failed to add a system RAM resource at 80200000 > ... > > > > Thanks, > > > > Alex > > > > > > > > > > So given that the arm64 patch with the new API is not pretty and that > > > > the simplest solution is to re-merge the memblock regions afterwards > > > > (which is done by memblock_clear_nomap), I'll drop the new API and the > > > > arm64 patch to use the nomap API like arm64: I'll take advantage of that > > > > to clean setup_vm_final which I have wanted to do for a long time. > > > > > > > > @Mike Thanks for you reviews! > > > > > > > > @Anup Thanks for all your bug reports on this patchset, I have to > > > > improve my test flow (it is in the work :)). > > > > > > > > > > > > > Regards, > > > > > Anup > > > > > > > > > >> Thanks > > > > >> > > > > >>> Regards, > > > > >>> Anup > > > > >>> > > > > >>>> arch/arm64/mm/mmu.c | 25 +++++++++++------ > > > > >>>> arch/riscv/include/asm/page.h | 19 +++++++++++-- > > > > >>>> arch/riscv/mm/init.c | 53 ++++++++++++++++++++++++++++------- > > > > >>>> arch/riscv/mm/physaddr.c | 16 +++++++++++ > > > > >>>> drivers/of/fdt.c | 11 ++++---- > > > > >>>> include/linux/memblock.h | 1 + > > > > >>>> mm/memblock.c | 20 +++++++++++++ > > > > >>>> 7 files changed, 119 insertions(+), 26 deletions(-) > > > > >>>> > > > > >>>> -- > > > > >>>> 2.37.2 > > > > >>>> > > > > > _______________________________________________ > > > > > 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