From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D8340C6FD1C for ; Fri, 24 Mar 2023 10:00:16 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4A91F6B0072; Fri, 24 Mar 2023 06:00:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 431EB6B0074; Fri, 24 Mar 2023 06:00:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D1F56B0075; Fri, 24 Mar 2023 06:00:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 173456B0072 for ; Fri, 24 Mar 2023 06:00:16 -0400 (EDT) Received: from smtpin06.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 979E7120558 for ; Fri, 24 Mar 2023 10:00:15 +0000 (UTC) X-FDA: 80603346390.06.68EC824 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by imf25.hostedemail.com (Postfix) with ESMTP id A9F87A002E for ; Fri, 24 Mar 2023 10:00:12 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=none; spf=none (imf25.hostedemail.com: domain of alex@ghiti.fr has no SPF policy when checking 217.70.183.196) smtp.mailfrom=alex@ghiti.fr; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679652013; a=rsa-sha256; cv=none; b=qy6i00E/4x0+hvnMCHWo/3Wiz4c7B0eKamWMRzVqp44+VE3ZqwYT2unpIotvC6s8fbWZCR ai5wjv8hughS+VPgwzYryKbXehG4hrv4ITUDrGx60RGuiZherRp5FyDkRGFMQDINoXeS5U CC721YKbnRWuiIigWsVK3SaEQaNDaTA= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=none; spf=none (imf25.hostedemail.com: domain of alex@ghiti.fr has no SPF policy when checking 217.70.183.196) smtp.mailfrom=alex@ghiti.fr; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679652013; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kHsgggp0g5Ws0Ej+efmFcQXLlgwLcCd1/v8teWpkVvk=; b=FqrOD+vsTKnLG5PPfNCWyMvaKKcNulp9o6l7kR8qsDwuLfKcSeajUwgj/GcNdvZrwMd5MA cAorPLt24q868GQrW8Ry84xyhITNd0haJcJZr2Y3+O9+1ovbZuAE/Bea5ctNDwCg8LUe5u /bX/J2y5Rbr4Fkt8bz9fimshaTa/tJ0= Received: (Authenticated sender: alex@ghiti.fr) by mail.gandi.net (Postfix) with ESMTPSA id 1881FE000B; Fri, 24 Mar 2023 09:59:57 +0000 (UTC) Message-ID: Date: Fri, 24 Mar 2023 10:59:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v8 0/4] riscv: Use PUD/P4D/PGD pages for the linear mapping Content-Language: en-US To: Anup Patel , Alexandre Ghiti Cc: Catalin Marinas , Will Deacon , Paul Walmsley , Palmer Dabbelt , Albert Ou , Rob Herring , Frank Rowand , Mike Rapoport , Andrew Morton , Anup Patel , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, devicetree@vger.kernel.org, linux-mm@kvack.org References: <20230316131711.1284451-1-alexghiti@rivosinc.com> From: Alexandre Ghiti In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Queue-Id: A9F87A002E X-Rspamd-Server: rspam01 X-Stat-Signature: xhtwuzah4zt38zdff1bdjnycr1sfzuei X-HE-Tag: 1679652012-940026 X-HE-Meta: U2FsdGVkX19yu5ENM5n9v35ODQ26mAPqqmJMkNO9elP2M6NOhpk5aK/Q3bynkrPnWpAHXoOyk2qEqxDjuFaD+uLWuvifL/OL1gSQJ6EmPyVA80jei27CeCGnOn8ryGHbLqEDzGe+GhE78O+DiRWs8BVpqCM4v9+GEnmuQIsA/1fMn1jZHxo4q9eAazyplw3/3vJkVTBirEdXTggcRLqpQ1ACIQANGDQ/fU0rwr0Tbwz3OVxP/GmIRT6+GfdwiHYVo9k4lsg5JK2WXuZQ2p13iJBQE6LaoxHsFBfCVfywE719LlZc05c6KMmRKz9Pl/Wu+Ycc+FWZuVgWQ/fiCzhqd5/zlYCpZeEC89BFk2vq9izDzCCGiEIAD7PBnNE/7NanU0NGOHpqE+vN0rpqtC/Is3EZQ1hPKEpZZ36dg9XmwQq3eC6AcDsB/5B1NCdhQ8w3LDy3lMJQpkTEbtliBkjVv5LcqkBoDuNb+81gmv3tzsxQJgIWsRzgLwr1lsUOmHdPJuq2eJ/In4SaAPSrxhp/kGC016JsOTwIbheQ82+WuHvCyFanud9A2SHlu2jUZde513mW1Jxu1D2eP8sESmplgy+SeTMXnjKxKU60m703W8jIyrDoivsHKyxmkZf3yjqjqH/tYGVrhgRW+uMuTtulrY3eKzPxH0SatflgmZgxcw+uwdG1qKaR8SmLfuv3eRf4gfVNh53h+H4IeeF5ePgDwQSyw2HxOzpO8ZV33zlcfPyB4elBMBG9nY1EWVArtJPrlS1Jz9FH21P3/Cd65kOnsQz5rSX08dX0FKwmCAGogRNc5HE4EKOV4kWYCxerD9ylTOJMd3ogUh+XvXbklyCdXsY6labos2RqIQps3lqFSak4LjL6bUZNoA2sEgQrCqh5N+XshKTgPxLj9CiyDLRH1xI9+QhS+IhcnWYUtMET9KEW3/QVOHOCd7WVex1/pmOkA4s1qIAe2M8o1EMbCpN f09zOq9g IWq+t4QiX1AMMiBU6Gn0GqO3H+xrr9gkthDdq13gXqqlbSVjC7KtK+aGRwXk1U/RDNh31PhNI64PdShBoMt33wz03pzFlOYRjYZh+Qhv37tZjaAJ7UPrWNzre3FqnSY75nJx8Sguok8hh6xkGqYygzxaf70PploFarWyq3mJzzb/E/LSV+Q9fIzrBWzms2m0YTiGx6NBGUziE6Wt5FAkYIQ/wvWj90nMqKATMShwFfG/SJB9PVxrDJe8ij5WrwtP0FRMAeKDnVnHvTVZO7m+sKBYG2Gzryv5x/BryUvS+QfiuESuvELr+PgC6TZIBOv6VHVUMNrOTA2ztbIqsYaOFmQdOsNnbVTe+vZfN X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 3/23/23 15:55, Anup Patel wrote: > On Thu, Mar 23, 2023 at 6:24 PM Alexandre Ghiti wrote: >> Hi Anup, >> >> On Thu, Mar 23, 2023 at 1:18 PM Anup Patel wrote: >>> Hi Alex, >>> >>> On Thu, Mar 16, 2023 at 6:48 PM Alexandre Ghiti 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