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=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED 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 ACD76C433DF for ; Tue, 21 Jul 2020 09:02:52 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 816A92080D for ; Tue, 21 Jul 2020 09:02:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595322172; bh=H4sR2N24637FuvcXN7OsFonQ4tJiLJ5HJGUm63XkrCY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:List-ID:From; b=wSlu/iuSuvUc10bTuB8hveziQd6qsT/unbwEEDI/HPwDzz/ak4742JTToIwZW0Oib jryw1SQr0rYyYJdxZYyn7AsvcQLUVeP4ckfBfltr8FWzYJ+DGMAc8rpe4+WEeZFIwd 7OusAkNuOqTRYsi7gH1AVLy3JoiEWuyAEZaBOkXU= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726821AbgGUJCw (ORCPT ); Tue, 21 Jul 2020 05:02:52 -0400 Received: from mail.kernel.org ([198.145.29.99]:39484 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726089AbgGUJCw (ORCPT ); Tue, 21 Jul 2020 05:02:52 -0400 Received: from mail-oo1-f52.google.com (mail-oo1-f52.google.com [209.85.161.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 5FF2F22C9C; Tue, 21 Jul 2020 09:02:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1595322171; bh=H4sR2N24637FuvcXN7OsFonQ4tJiLJ5HJGUm63XkrCY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=SF717i3ruwvvsB00BOLFc80n9scQYuZQ1PdLipTsltsFjejsLVQu/vt3AYsQii5pi U337BVficYv7cKmD9zTy/tjxaMLdR1//QRHaLpL41jlIYwcx4G9C/4B3NUiPJDZoFu CmQhhHmpC2cY9eXZPYGIoPLabzrTI8njiISCUfrA= Received: by mail-oo1-f52.google.com with SMTP id t12so3778316ooc.10; Tue, 21 Jul 2020 02:02:51 -0700 (PDT) X-Gm-Message-State: AOAM532RRoonY9DwZeZjswyLga/P5UgfJlil4fCkDg9PE0IG0+nG1PyL Bnzgqa9gwbOSkvl7LjWwxJOX9kV6VxBmZ7s6d2U= X-Google-Smtp-Source: ABdhPJxTRlrnT+ydEM3pK3cWrhrvw/wbjW+JnumS5WS6Rxoc8K1cIu7KOklEbd+we69/kFrM//djif/Xf4zfAGSx86g= X-Received: by 2002:a4a:b006:: with SMTP id f6mr23179936oon.13.1595322170629; Tue, 21 Jul 2020 02:02:50 -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: Ard Biesheuvel Date: Tue, 21 Jul 2020 12:02:39 +0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFT PATCH v3 1/9] RISC-V: Move DT mapping outof fixmap To: Arnd Bergmann Cc: Atish Patra , Atish Patra , "linux-kernel@vger.kernel.org" , Anup Patel , 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" Sender: linux-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@vger.kernel.org On Tue, 21 Jul 2020 at 11:57, Arnd Bergmann wrote: > > 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. > On arm64, we limit the size of the DT to 2MB, and reserve a pair of PMD entries adjacent to the fixmap so we can map it r/o statically using huge pages without using fixmap/early_ioremap slots. (Using a pair of PMD entries allows the DT to appear at any alignment in memory, given that PMD entries cover 2 MB each on 4k pages kernels)