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 A2FEEC43460 for ; Fri, 9 Apr 2021 14:42:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0D8FE61008 for ; Fri, 9 Apr 2021 14:42:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0D8FE61008 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 8B0F26B0070; Fri, 9 Apr 2021 10:42:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 862416B0071; Fri, 9 Apr 2021 10:42:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6DB976B0072; Fri, 9 Apr 2021 10:42:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0093.hostedemail.com [216.40.44.93]) by kanga.kvack.org (Postfix) with ESMTP id 51C3D6B0070 for ; Fri, 9 Apr 2021 10:42:25 -0400 (EDT) Received: from smtpin32.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 181218798 for ; Fri, 9 Apr 2021 14:42:25 +0000 (UTC) X-FDA: 78013094250.32.C74DF9C Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com [209.85.208.175]) by imf28.hostedemail.com (Postfix) with ESMTP id 47C092000242 for ; Fri, 9 Apr 2021 14:42:25 +0000 (UTC) Received: by mail-lj1-f175.google.com with SMTP id u9so6740584ljd.11 for ; Fri, 09 Apr 2021 07:42:24 -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; bh=mgWegSwhOpcGml0uML3IWUn1X3Z+AH0MFZdCHi/93PY=; b=o7eFJ30qOzBa3dgRnh/WcCN0kX49sPw9maR/6OuBKUPp5AJKAFmoQDa74vCSyYhlXn hXJeJrBR3C5NdSpTtex/aViY9q5M/fbQ4/Z9GR18hYJendIm2ZSEhhp48Syfl2xDKuD7 d6uhhhrmy+ADPRbj2wNKbzG2BqQoEEVnbG5DY= 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; bh=mgWegSwhOpcGml0uML3IWUn1X3Z+AH0MFZdCHi/93PY=; b=KMKhI6kz+NjJzvj8FIAQINd94EMeXJZ6MO01zfIVIJ/ZhcT7Pb/I3SL+8wxgVSah4b KaD/gqCq+lVKrZFLL07ji5+mT6eu2URIroCv7gmOATWwNihSDheTU1m5Gtj9A3Mga2En Zebv4yDZ5E7sAKR4zozLPi6rr9ZdbkUwq5deb03B4NUGP1XhqMArCq0e/RL/AHdFdyjE qIzgzzfcAqELBcW14FIc34cvXxbItVABc14jykkVbq4H5QhXINevDBy+wfRhRefPt7gn Gj1v6u95UZCBtrzdG67Bale/nw5oJTr22wQVdMCRUdCe3jGBQGTqx/9K6Lw6bBWim/JD x5rA== X-Gm-Message-State: AOAM530UrVSyj356Y+B0XU0ykvP/GnQnFW8hQaJaHabXATHVNzMQWZDq 62pDTrvHd3do5RzVLkpxF7vuaIpRmYoJzHbZJCdekg== X-Google-Smtp-Source: ABdhPJyLql3K0BO+oWb/9QvOTKYKMmjccNLMOLeXWEEXD3jfxsO8N+MD+HIzwc0FZJ18L7cYPrFgQ7ScHDtmwE+wAss= X-Received: by 2002:a2e:9dd8:: with SMTP id x24mr9267330ljj.173.1617979343021; Fri, 09 Apr 2021 07:42:23 -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: Fri, 9 Apr 2021 16:42:12 +0200 Message-ID: Subject: Re: [PATCH v7] RISC-V: enable XIP To: Mike Rapoport Cc: David Hildenbrand , Alex Ghiti , Paul Walmsley , Palmer Dabbelt , Albert Ou , linux-riscv , LKML , linux-arch@vger.kernel.org, Linux-MM Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 47C092000242 X-Stat-Signature: ghfzjbkbq5qc9j1mbtfzq5trceg39wwb Received-SPF: none (konsulko.com>: No applicable sender policy available) receiver=imf28; identity=mailfrom; envelope-from=""; helo=mail-lj1-f175.google.com; client-ip=209.85.208.175 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617979345-987276 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 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/kcore) > > > > > 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/iomem? ;-) > > > > 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 implement 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" operation, > > > so lack of kdump could be one of them. > > > > I agree. > > > > > > > > I might be wrong, but IMHO, artificially creating a memory map for part of > > > flash would cause more problems in the long run. > > > > Can you elaborate? > > Nothing particular, just a gut feeling. Usually, when you force something > 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 that > > > implement it? > > > > Interesting point, I thought XIP would be something new on RISC-V (well, at > > least to me :) ). If that concept exists already, we better mimic what > > existing implementations do. > > I had quick glance at ARM, it seems that kernel text does not have memory > 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). Best regards, Vitaly