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 X-Spam-Level: X-Spam-Status: No, score=-5.3 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,NICE_REPLY_A,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 603FBC43460 for ; Fri, 9 Apr 2021 12:57:59 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 83F0B610FB for ; Fri, 9 Apr 2021 12:57:58 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 83F0B610FB Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ghiti.fr Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id EF3976B0070; Fri, 9 Apr 2021 08:57:57 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EA3986B0071; Fri, 9 Apr 2021 08:57:57 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6B5F6B0072; Fri, 9 Apr 2021 08:57:57 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0003.hostedemail.com [216.40.44.3]) by kanga.kvack.org (Postfix) with ESMTP id BD5116B0070 for ; Fri, 9 Apr 2021 08:57:57 -0400 (EDT) Received: from smtpin33.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 7762C87D2 for ; Fri, 9 Apr 2021 12:57:57 +0000 (UTC) X-FDA: 78012830994.33.FFB4FF0 Received: from relay9-d.mail.gandi.net (relay9-d.mail.gandi.net [217.70.183.199]) by imf26.hostedemail.com (Postfix) with ESMTP id 6064940002DD for ; Fri, 9 Apr 2021 12:57:53 +0000 (UTC) X-Originating-IP: 82.65.183.113 Received: from [172.16.5.113] (82-65-183-113.subs.proxad.net [82.65.183.113]) (Authenticated sender: alex@ghiti.fr) by relay9-d.mail.gandi.net (Postfix) with ESMTPSA id BB8BBFF803; Fri, 9 Apr 2021 12:57:51 +0000 (UTC) Subject: Re: [PATCH v7] RISC-V: enable XIP To: David Hildenbrand , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, linux-mm@kvack.org Cc: Vitaly Wool , Mike Rapoport References: <20210409065115.11054-1-alex@ghiti.fr> <3500f3cb-b660-5bbc-ae8d-0c9770e4a573@ghiti.fr> From: Alex Ghiti Message-ID: Date: Fri, 9 Apr 2021 08:57:51 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 6064940002DD X-Stat-Signature: g5164khq5xqddyrxyc9azgpzjemk5wd1 Received-SPF: none (ghiti.fr>: No applicable sender policy available) receiver=imf26; identity=mailfrom; envelope-from=""; helo=relay9-d.mail.gandi.net; client-ip=217.70.183.199 X-HE-DKIM-Result: none/none X-HE-Tag: 1617973073-782369 Content-Transfer-Encoding: quoted-printable 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: Le 4/9/21 =C3=A0 8:07 AM, David Hildenbrand a =C3=A9crit=C2=A0: > On 09.04.21 13:39, Alex Ghiti wrote: >> Hi David, >> >> Le 4/9/21 =C3=A0 4:23 AM, David Hildenbrand a =C3=A9crit=C2=A0: >>> On 09.04.21 09:14, Alex Ghiti wrote: >>>> Le 4/9/21 =C3=A0 2:51 AM, Alexandre Ghiti a =C3=A9crit=C2=A0: >>>>> From: Vitaly Wool >>>>> >>>>> Introduce XIP (eXecute In Place) support for RISC-V platforms. >>>>> It allows code to be executed directly from non-volatile storage >>>>> directly addressable by the CPU, such as QSPI NOR flash which can >>>>> be found on many RISC-V platforms. This makes way for significant >>>>> optimization of RAM footprint. The XIP kernel is not compressed >>>>> since it has to run directly from flash, so it will occupy more >>>>> space on the non-volatile storage. The physical flash address used >>>>> to link the kernel object files and for storing it has to be known >>>>> at compile time and is represented by a Kconfig option. >>>>> >>>>> XIP on RISC-V will for the time being only work on MMU-enabled >>>>> kernels. >>>>> >>>> I added linux-mm and linux-arch to get feedbacks because I noticed t= hat >>>> DEBUG_VM_PGTABLE fails for SPARSEMEM (it works for FLATMEM but I thi= nk >>>> it does not do what is expected): the fact that we don't have any=20 >>>> struct >>>> page to back the text and rodata in flash is the problem but to whic= h >>>> extent ? >>> >>> Just wondering, why can't we create a memmap for that memory -- or is= it >>> even desireable to not do that explicity? There might be some nasty s= ide >>> effects when not having a memmap for text and rodata. >> >> >> Do you have examples of such effects ? Any feature that will not work >> without that ? >> >=20 > At least if it's not part of /proc/iomem in any way (maybe "System RAM"= =20 > is not what we want without a memmap, TBD), kexec-tools won't be able t= o=20 > handle it properly e.g., for kdump. But not sure if that is really=20 > relevant in your setup. >=20 > Regarding other features, anything that does a pfn_valid(),=20 > pfn_to_page() or pfn_to_online_page() would behave differently now --=20 > assuming the kernel doesn't fall into a section with other System RAM=20 > (whereby we would still allocate the memmap for the whole section). >=20 > I guess you might stumble over some surprises in some code paths, but=20 > nothing really comes to mind. Not sure if your zeropage is part of the=20 > kernel image on RISC-V (I remember that we sometimes need a memmap=20 > there, but I might be wrong)? It is in the kernel image and is located in bss which will be in RAM and=20 then be backed by a memmap. >=20 > I assume you still somehow create the direct mapping for the kernel,=20 > right? So it's really some memory region with a direct mapping but=20 > without a memmap (and right now, without a resource), correct? >=20 No I don't create any direct mapping for the text and the rodata. > [...] >=20 >>> >>> Also, will that memory properly be exposed in the resource tree as >>> System RAM (e.g., /proc/iomem) ? Otherwise some things (/proc/kcore) >>> won't work as expected - the kernel won't be included in a dump. >> >> >> I have just checked and it does not appear in /proc/iomem. >> >> Ok your conclusion would be to have struct page, I'm going to implemen= t >> this version then using memblock as you described. >=20 > Let's first evaluate what the harm could be. You could (and should?)=20 > create the kernel resource manually - IIRC, that's independent of the=20 > memmap/memblock thing. >=20 > @Mike, what's your take on not having a memmap for kernel text and ro d= ata? >=20