Message ID | 20230704121837.248976-1-alexghiti@rivosinc.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:9f45:0:b0:3ea:f831:8777 with SMTP id v5csp1180013vqx; Tue, 4 Jul 2023 05:23:34 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5fvzxUajUAv49cpmsVRLa7rJCeYqD8TwzixOAVyCsM5GmSiA31veapvDahLg+kzb+Xytvp X-Received: by 2002:a05:6808:159f:b0:3a3:7745:bdd7 with SMTP id t31-20020a056808159f00b003a37745bdd7mr12526588oiw.17.1688473414270; Tue, 04 Jul 2023 05:23:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1688473414; cv=none; d=google.com; s=arc-20160816; b=c+ZlDyswlnp78zAvkTX3OnI0P08m8PxCrFtXk9M5p6vryYHmPPYeKNY0z6q7aZW48t rdkbYdOI9C3IG6MDTSj+aAF5RXOp6cDU9acoMm2LPlnKK11mM+A7rLKjMSmMShRDzzK3 GgSmmf969umVIkgJmHoAGE6dCGiFNlPGykf5GTT1h7NPkqN1pBYOCiHNHTv2ELEWI29A 0gAPYCAHOGJylM/cCLv/IMcdbs3ZSfS5B6UeaK7dN4cpmBjFugqPHe6ZbuJvHzHVahwW upmnOKFtXE9/U6UXgsnQVJQboRCdJUm1+Y5FQe5juY2Gkik0tctNywO9LVBdPVQN4Egd 3fDQ== 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=hOxTf/FoItb3tkCzHBcD5o9fcnb2mULyauZWaQEOj5s=; fh=eh1dXaG6IFd4h25zHSS1vEFlmt8lfA2NkclBq7GsvwE=; b=MeRuPPCkMeh+fApS9fnMIj4cAcw6mxwSNI3layZO31I9Sov7oXfmexoPy/z8PiJDfR ZUJp6MfoVt67EEdGzLVDK0dp4cwhrbsTl/nLxUGpBer/lDgNSf9qrRPGz1e+a1foxR++ vc3BhJYXl9BLFdIZp6A5BMyqeSP0YMMLlbpc2sTCSB8kNP8g51AW046qT7bgvvMkf/tK F+dY0w8cZvirHpBwRHdpV/7nZM3CPxlti2AQmg88IXT/J7KUjeK+aVz5F9EM11YpV+Ca jjxItghE9fPpjEyNzD37MmEXhRAKA7qxc9/0ZKubo2sAJbutzpOIqXgHWUrCiNK1cnrr 5Isw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20221208.gappssmtp.com header.s=20221208 header.b=GQH147pJ; 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 p3-20020a17090ac00300b00261113f2843si22603488pjt.131.2023.07.04.05.23.19; Tue, 04 Jul 2023 05:23:34 -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.20221208.gappssmtp.com header.s=20221208 header.b=GQH147pJ; 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 S230472AbjGDMSn (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 4 Jul 2023 08:18:43 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37016 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229603AbjGDMSm (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 4 Jul 2023 08:18:42 -0400 Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 324C4E6A for <linux-kernel@vger.kernel.org>; Tue, 4 Jul 2023 05:18:41 -0700 (PDT) Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-3fbc5d5742bso54753175e9.2 for <linux-kernel@vger.kernel.org>; Tue, 04 Jul 2023 05:18:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20221208.gappssmtp.com; s=20221208; t=1688473119; x=1691065119; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=hOxTf/FoItb3tkCzHBcD5o9fcnb2mULyauZWaQEOj5s=; b=GQH147pJZZd0uy7HRqLSeRD4MqK0jpuyx9VA/x2qMTyfs0Ub6QrFkCnJxE4twAFKzC a5aSjiBKFpA59XP+5bbH2d4OtmkjTWMAjvbtmWGtV3wTgvKH3W2dTAnVTpjf7V/4t3kV pPumyphSN6NXKU9sqn8t0HeTmk7l2f0kJebl/ZrbKHVFleZDdjzfpdQ/hQXLGF7N6DZa aLKts8Ebf7KY84NpVDqqCmlmWU70AppsltS+lagdNuSYYiK/xmVCRcyLFyayiXmOlyJV SDN7yS1GSSdkM9SaH3486h7ROcBzo+DMnsFao3dwAdAGDOSqeYPxVPL1zXec6Tg0SAf7 57vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1688473119; x=1691065119; 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=hOxTf/FoItb3tkCzHBcD5o9fcnb2mULyauZWaQEOj5s=; b=eq5tzS7Bky4Cas1oteA+i7rKA7IQNpamNqenEkIxgm8gkRDeEHK74rqEMECC+8SFLA zY4WgWnfVhWliZL8cI5V6B2X73fBoK0Yg4MmQ30qIGHCQwlmnYOgYWtVyW1LyPvz+oWT GMH1HkdWhlgjgbc6ZR4ptq96Moshu/nSNxifPTLx6qOWXlA+rt3ba8t/UemOLNIsm7OM gucvsaSB76bJ6Ka61DfeooxSFsqiT/YtoAfmJDn2fnEVSMpokPjCZh9Hm2jvX+kuCmOS Eb4BhxfFV4KgKeywT/2U1txY5rGoBqXxXviKFvEdD7Q5XhWJWO2gqR3Qf/s17uqHqW1p neaQ== X-Gm-Message-State: ABy/qLY32UmH4TEtSDRgHFyermzRK/FE/YJ9hXREdIuFCFI2MmQmpd1P j0XzvtRJ1Bhpn+tQMEpyGAMYytn2JTxIZc9CzCI= X-Received: by 2002:a5d:6986:0:b0:314:37a9:f225 with SMTP id g6-20020a5d6986000000b0031437a9f225mr5409529wru.40.1688473119531; Tue, 04 Jul 2023 05:18:39 -0700 (PDT) Received: from alex-rivos.home (amontpellier-656-1-456-62.w92-145.abo.wanadoo.fr. [92.145.124.62]) by smtp.gmail.com with ESMTPSA id d11-20020a1c730b000000b003fb416d732csm22409679wmb.6.2023.07.04.05.18.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 04 Jul 2023 05:18:39 -0700 (PDT) From: Alexandre Ghiti <alexghiti@rivosinc.com> To: Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Song Shuai <suagrfillet@gmail.com>, linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Subject: [PATCH] riscv: Start of DRAM should at least be aligned on PMD size for the direct mapping Date: Tue, 4 Jul 2023 14:18:37 +0200 Message-Id: <20230704121837.248976-1-alexghiti@rivosinc.com> X-Mailer: git-send-email 2.39.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, T_SCC_BODY_TEXT_LINE autolearn=ham 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?1770492698857484327?= X-GMAIL-MSGID: =?utf-8?q?1770492698857484327?= |
Series |
riscv: Start of DRAM should at least be aligned on PMD size for the direct mapping
|
|
Commit Message
Alexandre Ghiti
July 4, 2023, 12:18 p.m. UTC
So that we do not end up mapping the whole linear mapping using 4K
pages, which is slow at boot time, and also very likely at runtime.
So make sure we align the start of DRAM on a PMD boundary.
Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com>
---
arch/riscv/mm/init.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
Comments
Hey Alex, On Tue, Jul 04, 2023 at 02:18:37PM +0200, Alexandre Ghiti wrote: > So that we do not end up mapping the whole linear mapping using 4K > pages, which is slow at boot time, and also very likely at runtime. > > So make sure we align the start of DRAM on a PMD boundary. > > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> Obviously correct me if I am wrong here, but was this not reported by Song Shuai as a regression? Accordingly, should this not have Reported-by, Closes/Link & Fixes tags? Cheers, Conor. > --- > arch/riscv/mm/init.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 4fa420faa780..4a43ec275c6d 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -214,8 +214,13 @@ static void __init setup_bootmem(void) > memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); > > phys_ram_end = memblock_end_of_DRAM(); > + > + /* > + * Make sure we align the start of the memory on a PMD boundary so that > + * at worst, we map the linear mapping with PMD mappings. > + */ > if (!IS_ENABLED(CONFIG_XIP_KERNEL)) > - phys_ram_base = memblock_start_of_DRAM(); > + phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; > > /* > * In 64-bit, any use of __va/__pa before this point is wrong as we > -- > 2.39.2 >
On Tue, Jul 4, 2023 at 2:26 PM Conor Dooley <conor.dooley@microchip.com> wrote: > > Hey Alex, > > On Tue, Jul 04, 2023 at 02:18:37PM +0200, Alexandre Ghiti wrote: > > So that we do not end up mapping the whole linear mapping using 4K > > pages, which is slow at boot time, and also very likely at runtime. > > > > So make sure we align the start of DRAM on a PMD boundary. > > > > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> > > Obviously correct me if I am wrong here, but was this not reported by > Song Shuai as a regression? > Accordingly, should this not have Reported-by, Closes/Link & Fixes tags? Sure we should add the reported by from Song as he did the proper report :) Reported-by: Song Shuai <suagrfillet@gmail.com> Closes: https://lore.kernel.org/linux-riscv/20230625140931.1266216-1-songshuaishuai@tinylab.org/ And yes sorry, I thought it was there before, but it was actually when I retrieved the first 2MB that the problem appeared, so: Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") Thanks! > > Cheers, > Conor. > > > --- > > arch/riscv/mm/init.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > index 4fa420faa780..4a43ec275c6d 100644 > > --- a/arch/riscv/mm/init.c > > +++ b/arch/riscv/mm/init.c > > @@ -214,8 +214,13 @@ static void __init setup_bootmem(void) > > memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); > > > > phys_ram_end = memblock_end_of_DRAM(); > > + > > + /* > > + * Make sure we align the start of the memory on a PMD boundary so that > > + * at worst, we map the linear mapping with PMD mappings. > > + */ > > if (!IS_ENABLED(CONFIG_XIP_KERNEL)) > > - phys_ram_base = memblock_start_of_DRAM(); > > + phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; > > > > /* > > * In 64-bit, any use of __va/__pa before this point is wrong as we > > -- > > 2.39.2 > >
在 2023/7/4 21:16, Alexandre Ghiti 写道: > On Tue, Jul 4, 2023 at 2:26 PM Conor Dooley <conor.dooley@microchip.com> wrote: >> >> Hey Alex, >> >> On Tue, Jul 04, 2023 at 02:18:37PM +0200, Alexandre Ghiti wrote: >>> So that we do not end up mapping the whole linear mapping using 4K >>> pages, which is slow at boot time, and also very likely at runtime. >>> >>> So make sure we align the start of DRAM on a PMD boundary. >>> >>> Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> >> >> Obviously correct me if I am wrong here, but was this not reported by >> Song Shuai as a regression? >> Accordingly, should this not have Reported-by, Closes/Link & Fixes tags? > > Sure we should add the reported by from Song as he did the proper report :) > > Reported-by: Song Shuai <suagrfillet@gmail.com> > Closes: https://lore.kernel.org/linux-riscv/20230625140931.1266216-1-songshuaishuai@tinylab.org/ > > And yes sorry, I thought it was there before, but it was actually when > I retrieved the first 2MB that the problem appeared, so: > > Fixes: 3335068f8721 ("riscv: Use PUD/P4D/PGD pages for the linear mapping") > > Thanks! And you can add my tested-by: Tested-by: Song Shuai <suagrfillet@gmail.com> > >> >> Cheers, >> Conor. >> >>> --- >>> arch/riscv/mm/init.c | 7 ++++++- >>> 1 file changed, 6 insertions(+), 1 deletion(-) >>> >>> diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c >>> index 4fa420faa780..4a43ec275c6d 100644 >>> --- a/arch/riscv/mm/init.c >>> +++ b/arch/riscv/mm/init.c >>> @@ -214,8 +214,13 @@ static void __init setup_bootmem(void) >>> memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); >>> >>> phys_ram_end = memblock_end_of_DRAM(); >>> + >>> + /* >>> + * Make sure we align the start of the memory on a PMD boundary so that >>> + * at worst, we map the linear mapping with PMD mappings. >>> + */ >>> if (!IS_ENABLED(CONFIG_XIP_KERNEL)) >>> - phys_ram_base = memblock_start_of_DRAM(); >>> + phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; >>> >>> /* >>> * In 64-bit, any use of __va/__pa before this point is wrong as we >>> -- >>> 2.39.2 >>>
On Tue, 04 Jul 2023 05:18:37 PDT (-0700), alexghiti@rivosinc.com wrote: > So that we do not end up mapping the whole linear mapping using 4K > pages, which is slow at boot time, and also very likely at runtime. > > So make sure we align the start of DRAM on a PMD boundary. > > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> > --- > arch/riscv/mm/init.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > index 4fa420faa780..4a43ec275c6d 100644 > --- a/arch/riscv/mm/init.c > +++ b/arch/riscv/mm/init.c > @@ -214,8 +214,13 @@ static void __init setup_bootmem(void) > memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); > > phys_ram_end = memblock_end_of_DRAM(); > + > + /* > + * Make sure we align the start of the memory on a PMD boundary so that > + * at worst, we map the linear mapping with PMD mappings. > + */ > if (!IS_ENABLED(CONFIG_XIP_KERNEL)) > - phys_ram_base = memblock_start_of_DRAM(); > + phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; This rounds down, which IIUC will result in mappings outside what memblock detected as the start af DRAM. I'd expect that to cause bad behavior somewhere. Shouldn't we be rounding up? > > /* > * In 64-bit, any use of __va/__pa before this point is wrong as we
(sorry for the delay!) On Thu, Jul 6, 2023 at 7:05 PM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Tue, 04 Jul 2023 05:18:37 PDT (-0700), alexghiti@rivosinc.com wrote: > > So that we do not end up mapping the whole linear mapping using 4K > > pages, which is slow at boot time, and also very likely at runtime. > > > > So make sure we align the start of DRAM on a PMD boundary. > > > > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> > > --- > > arch/riscv/mm/init.c | 7 ++++++- > > 1 file changed, 6 insertions(+), 1 deletion(-) > > > > diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c > > index 4fa420faa780..4a43ec275c6d 100644 > > --- a/arch/riscv/mm/init.c > > +++ b/arch/riscv/mm/init.c > > @@ -214,8 +214,13 @@ static void __init setup_bootmem(void) > > memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); > > > > phys_ram_end = memblock_end_of_DRAM(); > > + > > + /* > > + * Make sure we align the start of the memory on a PMD boundary so that > > + * at worst, we map the linear mapping with PMD mappings. > > + */ > > if (!IS_ENABLED(CONFIG_XIP_KERNEL)) > > - phys_ram_base = memblock_start_of_DRAM(); > > + phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; > > This rounds down, which IIUC will result in mappings outside what > memblock detected as the start af DRAM. I'd expect that to cause bad > behavior somewhere. Actually we are not mapping this new region as it is not present in the memblock regions, we are just re-aligning the virtual and physical address: phys_ram_base is only used for the virtual to physical translations. > > Shouldn't we be rounding up? Doing so would remove memory from the memory map, but I'm not sure this is correct, we could remove memory that contains "something" that needs to be accessed using the linear mapping (ACPI tables? DT?). More testing is welcome as I can be wrong of course. Thanks, Alex > > > > > /* > > * In 64-bit, any use of __va/__pa before this point is wrong as we
On Tue, 04 Jul 2023 14:18:37 +0200, Alexandre Ghiti wrote: > So that we do not end up mapping the whole linear mapping using 4K > pages, which is slow at boot time, and also very likely at runtime. > > So make sure we align the start of DRAM on a PMD boundary. > > Applied, thanks! [1/1] riscv: Start of DRAM should at least be aligned on PMD size for the direct mapping https://git.kernel.org/palmer/c/9d3e8e1ff0d8 Best regards,
Hello: This patch was applied to riscv/linux.git (fixes) by Palmer Dabbelt <palmer@rivosinc.com>: On Tue, 4 Jul 2023 14:18:37 +0200 you wrote: > So that we do not end up mapping the whole linear mapping using 4K > pages, which is slow at boot time, and also very likely at runtime. > > So make sure we align the start of DRAM on a PMD boundary. > > Signed-off-by: Alexandre Ghiti <alexghiti@rivosinc.com> > > [...] Here is the summary with links: - riscv: Start of DRAM should at least be aligned on PMD size for the direct mapping https://git.kernel.org/riscv/c/9d3e8e1ff0d8 You are awesome, thank you!
diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 4fa420faa780..4a43ec275c6d 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -214,8 +214,13 @@ static void __init setup_bootmem(void) memblock_reserve(vmlinux_start, vmlinux_end - vmlinux_start); phys_ram_end = memblock_end_of_DRAM(); + + /* + * Make sure we align the start of the memory on a PMD boundary so that + * at worst, we map the linear mapping with PMD mappings. + */ if (!IS_ENABLED(CONFIG_XIP_KERNEL)) - phys_ram_base = memblock_start_of_DRAM(); + phys_ram_base = memblock_start_of_DRAM() & PMD_MASK; /* * In 64-bit, any use of __va/__pa before this point is wrong as we