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.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS 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 E7616C433B4 for ; Mon, 12 Apr 2021 07:49:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 3A69661364 for ; Mon, 12 Apr 2021 07:49:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3A69661364 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=konsulko.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 879766B0036; Mon, 12 Apr 2021 03:49:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 802416B006C; Mon, 12 Apr 2021 03:49:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 62D806B006E; Mon, 12 Apr 2021 03:49:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0217.hostedemail.com [216.40.44.217]) by kanga.kvack.org (Postfix) with ESMTP id 3D2E56B0036 for ; Mon, 12 Apr 2021 03:49:34 -0400 (EDT) Received: from smtpin02.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CE35082499A8 for ; Mon, 12 Apr 2021 07:49:33 +0000 (UTC) X-FDA: 78022940226.02.320CA53 Received: from mail-lf1-f43.google.com (mail-lf1-f43.google.com [209.85.167.43]) by imf03.hostedemail.com (Postfix) with ESMTP id 53E28C0001F7 for ; Mon, 12 Apr 2021 07:49:30 +0000 (UTC) Received: by mail-lf1-f43.google.com with SMTP id b4so19827042lfi.6 for ; Mon, 12 Apr 2021 00:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=qFK3ymFR+8IkY/EyN1emVbVTfc7jJvlULyoMvBmBots=; b=Soa1RlqoeN2pveBDhZJ7t62minjfgT/bCsZg0/EBGI558bQ/bao3frHXP0Rz7qclWJ XlL0cuJODa1mwy5dDSETOj5ECqGIfCVjJ14QfQ6C5VOOVsvvjSbiWgX64VQqQHkhUMIC eOC6tA7GhvnTU36knNTYZi4yN5tdqRic44hco= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=qFK3ymFR+8IkY/EyN1emVbVTfc7jJvlULyoMvBmBots=; b=D7myIP9tuoLiZqTlnGUxAfsrFBphDA2gOHGIBopUnHmme7puCeYc8erVGPUAvAfh/x IBQAlvm77zzjuXwk/Wb7hD5C1LX3jIDXyMj89BR5WZrNsaladof+/MnXvSffbTAZA32W hCNEUwfsyda99qnCygWe0vQmxvII4l9vmS/NnwgtPsN0ernyeBnNSUpBYnJL/mCilTwe aqVLXs110/q2zZxM+ZiGaRerQWlj5LUHPTruwrhO04AnCsy+G+BPs686Us+zGAQHpteK CLWbIOtnIdUuaH1wCHb2VZcHD0gInqUfFaYZKcSuRp6SVC7rvqERx2iSeCVsKlZKHRxk qtjQ== X-Gm-Message-State: AOAM532z6BSIViqU47wo1CUEvjMnjO2rwqMeQUMiwTRDWgTwB2Pa5qKY 135sgMwjhRjHk61ZRQd2eupReoRrafcrUOH8t+tbzg== X-Google-Smtp-Source: ABdhPJwBRSVhNhw4No6L7/vBHycAOzfNc3erh48gevSjcRU17HxBGnY6Rhiut8kw7o9Ldf5DIb/dwWKFzUtR20neYAw= X-Received: by 2002:ac2:59c2:: with SMTP id x2mr4535970lfn.407.1618213771658; Mon, 12 Apr 2021 00:49:31 -0700 (PDT) MIME-Version: 1.0 References: <20210409065115.11054-1-alex@ghiti.fr> <3500f3cb-b660-5bbc-ae8d-0c9770e4a573@ghiti.fr> In-Reply-To: From: Vitaly Wool Date: Mon, 12 Apr 2021 09:49:20 +0200 Message-ID: Subject: Re: [PATCH v7] RISC-V: enable XIP To: Alex Ghiti Cc: Mike Rapoport , David Hildenbrand , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv , LKML , linux-arch@vger.kernel.org, Linux-MM Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: ag4cqk7p1t6cf5rxhf8853xbtfze5zye X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 53E28C0001F7 Received-SPF: none (konsulko.com>: No applicable sender policy available) receiver=imf03; identity=mailfrom; envelope-from=""; helo=mail-lf1-f43.google.com; client-ip=209.85.167.43 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1618213770-139290 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 Mon, Apr 12, 2021 at 7:12 AM Alex Ghiti wrote: > > Le 4/9/21 =C3=A0 10:42 AM, Vitaly Wool a =C3=A9crit : > > 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. > > > > 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. > > > >>>> 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. > > > > Exactly, and I believe ARM64 won't do that too when it gets its own > > XIP support (which is underway). > > > > > 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 > lies in flash, as mentioned by David, that could lead to silent > corruptions if something exists at the address where the struct page > should be. And it is hard to know which features in the kernel depends > on that. > > Regarding SPARSEMEM, the vmemmap lies in its own region so that's > unlikely to happen, so we will catch those invalid accesses (and that's > what I observed on riscv). > > But for FLATMEM, memmap is in the linear mapping, then that could very > likely happen silently. > > Could a simple solution be to force SPARSEMEM for those XIP kernels ? > Then wrong things could happen, but we would see those and avoid > spending hours to debug :) > > I will at least send a v8 to remove the pfn_valid modifications for > FLATMEM that now returns true to pfn in flash. That sounds good to me. I am not very keen on spending 200K on struct pages for flash (we can think of this as of an option but I would definitely like to have the option to compile it out in the end), so let's remove pfn_valid and fix things that will eventually break, if some. Best regards, Vitaly