Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp553617ybh; Tue, 21 Jul 2020 02:00:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyST+iPNZw6qTh7Tnvd88rrCm6jYp+vl5Y3IUmAkDAijLUp0p9ukGblGfQrbx7FNj6duesE X-Received: by 2002:a50:ee87:: with SMTP id f7mr25538616edr.355.1595322016223; Tue, 21 Jul 2020 02:00:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595322016; cv=none; d=google.com; s=arc-20160816; b=ouMBngr3sajbMkGQ0WCKRSgvEZTrb8fQ6+QySTnSi0CNajP2P9zhwTWmXu0GybSj0+ Wl9589eMv2SgTeRB1vZ0oHy/eLLCt0iSBAmhYXpOD6+SuQXWuGWtjM8vic2hL0e/9GzF SgOeTpwLyzbtuP3TdjqxqYcFdHP220tNy/ZQYvnAnWzbGZw2RSdkPDNWjXflUAiogpFU lJ/rNZYEkwufOhvqR5Ywu79qdqcWDIrTbtfxtvKMhZ+Nna7gYfeOh3HCpXi88Wma0C8G hC4brKxX4XTiSaIAGWmOC0etd81TLOcTRI+1SzdpyDjPljCHkFReiKNKxx/vlX/ZHf7Q TOSg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=Nj//SRpYBGBjvh1WjsCbr5O415zqB5RQ1RmI7MDHYBc=; b=sbz1mUG6yZCTOacMEat83L64LHO9nyz1s1GB7TBvuaqIKbvgEFaczVdnIbCeWrxeKt zCuaD1r/Mzz8TwVEdcTQIMNVDpb68xB7n2xJu3OgG5vGIZwUErUOCCEtY5N5uiUVTZOX l6lhUiw/fCuwC9aXSXYS3ePd2Eb5dzCTCRBSNZ+3wkJOOwiayQN004GPkY2lbneeek/y +Zcvf/BIfkeBjJb9Rdy6aOnQN9s8uk6VQn/Tl4RZvoXf+0278wiSo1tH1ygi4vaHO+fq //6gd5CpYJZTKIm6/AZvlBVstJkJgrRuy0HYAgHVxJuPEnVuwz2PL9rRkjQ0aXfbhFx8 pebA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t16si11167274edc.161.2020.07.21.01.59.53; Tue, 21 Jul 2020 02:00:16 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728925AbgGUI5p (ORCPT + 99 others); Tue, 21 Jul 2020 04:57:45 -0400 Received: from mout.kundenserver.de ([217.72.192.75]:41639 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726821AbgGUI5o (ORCPT ); Tue, 21 Jul 2020 04:57:44 -0400 Received: from mail-qt1-f170.google.com ([209.85.160.170]) by mrelayeu.kundenserver.de (mreue108 [212.227.15.145]) with ESMTPSA (Nemesis) id 1N7Qt9-1kuHVr214H-017pto; Tue, 21 Jul 2020 10:57:42 +0200 Received: by mail-qt1-f170.google.com with SMTP id s23so2436405qtq.12; Tue, 21 Jul 2020 01:57:42 -0700 (PDT) X-Gm-Message-State: AOAM532tb1orIsiCr6BC4WdLdFPDw97jVaqwkB5CT/3HQlGdENXQU+iM MmWeYWK/uP60V8cPV3srGyp1mjsLtKslYb2lVCw= X-Received: by 2002:ac8:4ccb:: with SMTP id l11mr27467703qtv.18.1595321861275; Tue, 21 Jul 2020 01:57:41 -0700 (PDT) MIME-Version: 1.0 References: <20200716234104.29049-1-atish.patra@wdc.com> <20200716234104.29049-2-atish.patra@wdc.com> In-Reply-To: From: Arnd Bergmann Date: Tue, 21 Jul 2020 10:57:24 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFT PATCH v3 1/9] RISC-V: Move DT mapping outof fixmap To: Atish Patra Cc: Atish Patra , "linux-kernel@vger.kernel.org" , Anup Patel , Ard Biesheuvel , Greentime Hu , Kees Cook , linux-efi , linux-riscv , Mark Rutland , Masahiro Yamada , Mike Rapoport , Palmer Dabbelt , Paul Walmsley , Will Deacon , Zong Li , Heinrich Schuchardt , Linux ARM Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:1ABNl54a5UCI+4ZNMYFht6ehM8yPzb33aIUKsYUtej0+aFoQUss 9WNIuMojR1Kn3WCLrrtUQgO3vJ0FUiY1ZfDrWFsAOgePrBFxePCSuO/0nrwqAPI9zWwZi5Y 2onlrXdxsH8kOXVH2YEgPrNxLAO5XeprxhwOla2BeRAAWo2XhhROkMmNOgQTYu3zZZC1seu 7/d2N8Tu/BkPZxJmuoJkw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:77Hf8qhTi0Q=:EWtUkseO8iC0woJ2xan+qj BlU3FxBFtLdEJfVGyyR9DzJvf9+OoMkkRVby8hVprxYobrm58XKR541FOjdKy2sPZGoinLoal 3g8BF2qMRVR6+wT+VMTZKsMXgXXDrScrKvzn4zdYZhrsS8y2HURtVHWTErGbrIEMt5T8dBn6/ J29rARuntsoBm2TDJ6UueG+SJCXnYd2O8tAB6WK+8e3sy8LB7yn3kNA0mmq0aj11rl0dFs/xr R5FZ3ZoGn56ZseTze0Qf+8C/x5mp+LTY5hAnWobvXFVbqY0qAnICy4y1KXEPjWSfANGyyG54K quyj5xgYZVuu5mOZauKpH+oRYA64cd4YiYPd5dtKZHB9UoJ9+eOerdzZix6aCssz7/0Qmi276 FcpYYalrU3GHWI5GXNoHf+rjY4hti3KNsrIgwhotV3krtyKRcjMuZLXrutlLgocx6N7Ga7gGl malBTkr+4DA5raeSYOpwrKHG7TxR60oT/95fAbemdSh33ix1tibH88YsmeIee6LDka1kKeKJT GJfCmODBTXL7ESZf2DsvXvbSXzZbN0ZjNQLIfM2TwNl8/eMeWtGFDii400URV3BCSnR1dYLGq l6bYA0B3wCKB1whDPsmQ2vGJLwQ/N1AZx0CV7lbRZt734Tcu9rsiH5wbPFmnMQalnHqN+O5Rw NGzpEW1Nic3MOZCExIdZYWgRoFDsyG5ybKnrXk5crwEaPoM05/TICURyd133MSWEQObQBapZH yFLc+xv/QOcOXPT7z2Z09M9yxJs4ssNEcVjXJp1K4sXfsrcnTdsgD2HttqaNUjQA4ngM5+TFA awAnoxxvAdoJZ6f2U2HfgAUtFd3CJXfLlRETp87cxCUyiIjx2P66JDDqSdJ/KsxpNhDxBRi7F gNtR/kPEt2xmj8hOJjmkDQPZxF/9Dl8h8pu8LvivmfBdTc97KJZF0+fhx+jJE59/Fe6EPnlAy Zv7gUiTlj9ZnOVph+HH2VKdC+C0m8qrb5yZLaU1LShNa1RhKPNnlt Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 21, 2020 at 6:18 AM Atish Patra wrote: > On Sat, Jul 18, 2020 at 2:24 AM Arnd Bergmann wrote: > > On Sat, Jul 18, 2020 at 3:05 AM Atish Patra wrote: > > > That's what the original code was doing. A fixmap entry was added to > > > map the original fdt > > > location to a virtual so that parse_dtb can be operated on a virtual > > > address. But we can't map > > > both FDT & early ioremap within a single PMD region( 2MB ). That's why > > > we removed the DT > > > mapping from the fixmap to .bss section. The other alternate option is > > > to increase the fixmap space to 4MB which seems more fragile. > > > > Could the original location just be part of the regular linear mapping of all > > RAM? > > No. Because we don't map the entire RAM until setup_vm_final(). > We need to parse DT before setup_vm_final() to get the memblocks and > reserved memory regions. Ok, I see how you create a direct mapping for the kernel image, plus the fixmap for the dtb in setup_vm(), and how moving the dtb into the kernel image simplifies that. I'm still wondering why you can't do the same kind of PGD mapping for the dtb that you do for the vmlinux, creating linear page table entries exactly for the location that holds the dtb, from dtb_pa to dtb_pa+((struct fdt_header*)dtb_pa)->totalsize. Arnd