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,DKIMWL_WL_HIGH, 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 80DD2C433ED for ; Fri, 9 Apr 2021 14:10:24 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1198160FF1 for ; Fri, 9 Apr 2021 14:10:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1198160FF1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 874446B006C; Fri, 9 Apr 2021 10:10:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 838136B006E; Fri, 9 Apr 2021 10:10:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7003E6B0070; Fri, 9 Apr 2021 10:10:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0058.hostedemail.com [216.40.44.58]) by kanga.kvack.org (Postfix) with ESMTP id 5802E6B006C for ; Fri, 9 Apr 2021 10:10:23 -0400 (EDT) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 0ABB6AF83 for ; Fri, 9 Apr 2021 14:10:23 +0000 (UTC) X-FDA: 78013013526.04.FC65F09 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by imf30.hostedemail.com (Postfix) with ESMTP id 7EE69E000114 for ; Fri, 9 Apr 2021 14:10:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1617977422; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=proPil0jUhRoc2kcDPVO/0GyIRKmtQoV0j0AhOkxvnU=; b=fJaJiuFUO42S3Qm5J6OWGQTCSDoZPqccojWUaeRv1OAjyUUlRNQqakMRtHLNRdTGZCZlVX 9dOE/h3WE1HNE9QNta57oeyOobux3OxCPXMM6669yuBYdVPEbKB5xEkKW9lB8wtKuHWSBM ZiHFM9ria0rmlXB3/6m2YqwMJ2/h0ns= Received: from mail-wm1-f71.google.com (mail-wm1-f71.google.com [209.85.128.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-317-kfnDfXhZM5qBi4WxUZ_0Aw-1; Fri, 09 Apr 2021 10:10:19 -0400 X-MC-Unique: kfnDfXhZM5qBi4WxUZ_0Aw-1 Received: by mail-wm1-f71.google.com with SMTP id a5-20020a1c66050000b02901258107720dso853789wmc.2 for ; Fri, 09 Apr 2021 07:10:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=EWNREvrOtHiS/gdxlthAoSyaX95CLmAUl3lJOVpNYCw=; b=DnUQW+jC/YZmFTc2tLhxC+bCA27Ic27q7zNT3zZ7vK9f9+hugjH/JWDKWaMgxaUvVk kLZchGKqs5/sZLkO2DKztQeGog1Oai7RwZ9bLHccxZ6l3nnaRiYSy+UMUJb6BOHkb3Zn OfRk4tkO6hIxdo5WDPe9jBVRY1l32ArAW8E8QwuOAjRlVb1hKYi6SPEpu2hgyXWbQjGE EYVeNttT/nP5Poq72BiIYQ2ukARR/FdQfto0QiM0l6LlvHpiALFAEhJtmJxQ5oJvbANq +bBxGoPFSOnswy8uENAvachwnYW4udYttYPLGgpFkEkdm+ftEGrVgD+GPKH9hInftzuu qQ9Q== X-Gm-Message-State: AOAM530PI+ASIKdyxYmiL4ZCqjcgZy++mcLuD+bSIXXIO7kTE0Eunk4s SaIXim+9FXF2U601kYkiPkPjsKvq/Kg8f6qnbkah5d43pATXxxfb97xsIc/ey0bbyC/7qH9UD2/ PXAMzIpBiKHI= X-Received: by 2002:a1c:49d5:: with SMTP id w204mr14121453wma.51.1617977417426; Fri, 09 Apr 2021 07:10:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxK2eQJebQQhfMGzxEK9Jzyvz7ElE085TfiU8H50Wp6kUuTBF1Ga0ilIdJhVRoRW8OfQyc2eA== X-Received: by 2002:a1c:49d5:: with SMTP id w204mr14121423wma.51.1617977417130; Fri, 09 Apr 2021 07:10:17 -0700 (PDT) Received: from [192.168.3.108] (p5b0c6302.dip0.t-ipconnect.de. [91.12.99.2]) by smtp.gmail.com with ESMTPSA id u8sm4960453wrr.42.2021.04.09.07.10.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 09 Apr 2021 07:10:16 -0700 (PDT) From: David Hildenbrand Mime-Version: 1.0 (1.0) Subject: Re: [PATCH v7] RISC-V: enable XIP Date: Fri, 9 Apr 2021 16:10:15 +0200 Message-Id: References: Cc: David Hildenbrand , Alex Ghiti , 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, Vitaly Wool In-Reply-To: To: Mike Rapoport X-Mailer: iPhone Mail (18D70) Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=david@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 7EE69E000114 X-Stat-Signature: j4kewgwc1as6uqhfz16jjtyn1jt5u9mx X-Rspamd-Server: rspam02 Received-SPF: none (redhat.com>: No applicable sender policy available) receiver=imf30; identity=mailfrom; envelope-from=""; helo=us-smtp-delivery-124.mimecast.com; client-ip=216.205.24.124 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1617977415-837705 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: > Am 09.04.2021 um 15:59 schrieb Mike Rapoport : >=20 > =EF=BB=BFOn Fri, Apr 09, 2021 at 02:46:17PM +0200, David Hildenbrand wrot= e: >>>>> 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/iome= m? ;-) >>=20 >> See my other mail, maybe we actually want something different. >>=20 >>>=20 >>>> I have just checked and it does not appear in /proc/iomem. >>>>=20 >>>> Ok your conclusion would be to have struct page, I'm going to implemen= t this >>>> version then using memblock as you described. >>>=20 >>> I'm not sure this is required. With XIP kernel text never gets into RAM= , so >>> it does not seem to require struct page. >>>=20 >>> XIP by definition has some limitations relatively to "normal" operation= , >>> so lack of kdump could be one of them. >>=20 >> I agree. >>=20 >>>=20 >>> I might be wrong, but IMHO, artificially creating a memory map for part= of >>> flash would cause more problems in the long run. >>=20 >> Can you elaborate? >=20 > Nothing particular, just a gut feeling. Usually, when you force something > it comes out the wrong way later. >=20 >>>=20 >>> BTW, how does XIP account the kernel text on other architectures that >>> implement it? >>=20 >> 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. >=20 > I had quick glance at ARM, it seems that kernel text does not have memory > map and does not show up in System RAM. >=20 Does it show up in a different way or not at all? > --=20 > Sincerely yours, > Mike. >=20