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,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 2E98AC43461 for ; Mon, 12 Apr 2021 05:12:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A29EE6124C for ; Mon, 12 Apr 2021 05:12:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A29EE6124C 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 CACB86B0036; Mon, 12 Apr 2021 01:12:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C5C256B006C; Mon, 12 Apr 2021 01:12:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B23B96B006E; Mon, 12 Apr 2021 01:12:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0244.hostedemail.com [216.40.44.244]) by kanga.kvack.org (Postfix) with ESMTP id 930756B0036 for ; Mon, 12 Apr 2021 01:12:30 -0400 (EDT) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 393F882499A8 for ; Mon, 12 Apr 2021 05:12:30 +0000 (UTC) X-FDA: 78022544460.27.BA26290 Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) by imf15.hostedemail.com (Postfix) with ESMTP id B76C6A00038C for ; Mon, 12 Apr 2021 05:12:27 +0000 (UTC) X-Originating-IP: 2.7.49.219 Received: from [192.168.1.100] (lfbn-lyo-1-457-219.w2-7.abo.wanadoo.fr [2.7.49.219]) (Authenticated sender: alex@ghiti.fr) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id B2748E0007; Mon, 12 Apr 2021 05:12:23 +0000 (UTC) From: Alex Ghiti Subject: Re: [PATCH v7] RISC-V: enable XIP To: Vitaly Wool , Mike Rapoport Cc: David Hildenbrand , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv , LKML , linux-arch@vger.kernel.org, Linux-MM References: <20210409065115.11054-1-alex@ghiti.fr> <3500f3cb-b660-5bbc-ae8d-0c9770e4a573@ghiti.fr> Message-ID: Date: Mon, 12 Apr 2021 01:12:23 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: fr X-Rspamd-Queue-Id: B76C6A00038C X-Stat-Signature: m61ub5wcokaw8kuzm1t6whxdctjpa9ph X-Rspamd-Server: rspam02 Received-SPF: none (ghiti.fr>: No applicable sender policy available) receiver=imf15; identity=mailfrom; envelope-from=""; helo=relay4-d.mail.gandi.net; client-ip=217.70.183.196 X-HE-DKIM-Result: none/none X-HE-Tag: 1618204347-996327 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 =E0 10:42 AM, Vitaly Wool a =E9crit=A0: > On Fri, Apr 9, 2021 at 3:59 PM Mike Rapoport wrote= : >> >> On Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrote: >>>>>> Also, will that memory properly be exposed in the resource tree as >>>>>> System RAM (e.g., /proc/iomem) ? Otherwise some things (/proc/kcor= e) >>>>>> won't work as expected - the kernel won't be included in a dump. >>>> Do we really need a XIP kernel to included in kdump? >>>> And does not it sound weird to expose flash as System RAM in /proc/i= omem? ;-) >>> >>> See my other mail, maybe we actually want something different. >>> >>>> >>>>> 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 imple= ment this >>>>> version then using memblock as you described. >>>> >>>> I'm not sure this is required. With XIP kernel text never gets into = RAM, so >>>> it does not seem to require struct page. >>>> >>>> XIP by definition has some limitations relatively to "normal" operat= ion, >>>> so lack of kdump could be one of them. >>> >>> I agree. >>> >>>> >>>> I might be wrong, but IMHO, artificially creating a memory map for p= art of >>>> flash would cause more problems in the long run. >>> >>> Can you elaborate? >> >> Nothing particular, just a gut feeling. Usually, when you force someth= ing >> it comes out the wrong way later. >=20 > It's possible still that MTD_XIP is implemented allowing to write to > the flash used for XIP. While flash is being written, memory map > doesn't make sense at all. I can't come up with a real life example > when it can actually lead to problems but it is indeed weird when > System RAM suddenly becomes unreadable. I really don't think exposing > it in /proc/iomem is a good idea. >=20 >>>> BTW, how does XIP account the kernel text on other architectures tha= t >>>> implement it? >>> >>> Interesting point, I thought XIP would be something new on RISC-V (we= ll, at >>> least to me :) ). If that concept exists already, we better mimic wha= t >>> existing implementations do. >> >> I had quick glance at ARM, it seems that kernel text does not have mem= ory >> map and does not show up in System RAM. >=20 > Exactly, and I believe ARM64 won't do that too when it gets its own > XIP support (which is underway). >=20 memmap does not seem necessary and ARM/ARM64 do not use it. But if someone tries to get a struct page from a physical address that=20 lies in flash, as mentioned by David, that could lead to silent=20 corruptions if something exists at the address where the struct page=20 should be. And it is hard to know which features in the kernel depends=20 on that. Regarding SPARSEMEM, the vmemmap lies in its own region so that's=20 unlikely to happen, so we will catch those invalid accesses (and that's=20 what I observed on riscv). But for FLATMEM, memmap is in the linear mapping, then that could very=20 likely happen silently. Could a simple solution be to force SPARSEMEM for those XIP kernels ?=20 Then wrong things could happen, but we would see those and avoid=20 spending hours to debug :) I will at least send a v8 to remove the pfn_valid modifications for=20 FLATMEM that now returns true to pfn in flash. Thanks, > Best regards, > Vitaly >=20 > _______________________________________________ > linux-riscv mailing list > linux-riscv@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-riscv >=20