Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp45912ybh; Fri, 17 Jul 2020 18:06:49 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxBNQeyTuTQbu1c35h35Mzs7/LM14K44mYccDhKkeMstzYWDczXqeCDaPUYdqFgU3GmYZFf X-Received: by 2002:a17:906:694d:: with SMTP id c13mr10725761ejs.337.1595034409599; Fri, 17 Jul 2020 18:06:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595034409; cv=none; d=google.com; s=arc-20160816; b=nc5HbTKri7PbkFZqGnR5J9Y2UnFaqLkYV41xM7xfflJEDJ5kDJswcQsapnvqt8GRhT iG0ACWnRgRp/OAdqNL5X5rRdS9ySCjgwRE6QcH25w2tCR+tnndkEF3kzUlKtXry20Qq9 qoEelqhGSOccFzpsoEHx/G6AHDK7oDS6wvnENKQ0lKMH6aJihX+rULo3Q8j55P4dZSQR Xsmqr2YcjrwECSLn829TwvxE+rvLPVynZHXpyy3flOZRn4uVz2up1o7miUEO5f7jN1fO S4RJn5Bpb4DS9/55WQ5HtTYEIfdFpMim6saN8Ehz4vzs+LzsPbDOejGlhnqDB2yIKkZo 062g== 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:dkim-signature; bh=LE3moRbyBfkEEvwl1ynsLf05iOxnrGFtEat6arjyjJA=; b=nuqwHZsVZGsFIk6x3WauZLFgqGV/KhnI2nS30X7mh/IlIRnuL1yAsB61mKPXTrLZZv 30cAOt3+Nk9SS2B09vEmSvvN6E9rEqAkZySpDMAYlXjg5RcuwNaUAl37BY1ZFTtS+W9L j0LyE2uPAz+YqeOa5yCjt5F5b8XTF5w5nOG41loYtG+UzvGvzv7e7yURLCUdRP4AEm10 wO/bA15zATgCm52B2PqnKSxS3CwHodzeRWhXpXRjn54d5UOoL3YTNchH652WHfSmGNeX B+yJlk/CG8/HqcsLAGj5wHS6T+TBJN56rIYwObl+txuBBFOo+AGtzYrAXcSPcPrL83ly 1geA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@atishpatra.org header.s=google header.b=DlQrUmEc; 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 bq8si4584552ejb.320.2020.07.17.18.06.26; Fri, 17 Jul 2020 18:06:49 -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; dkim=pass header.i=@atishpatra.org header.s=google header.b=DlQrUmEc; 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 S1726923AbgGRBFs (ORCPT + 99 others); Fri, 17 Jul 2020 21:05:48 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57524 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726788AbgGRBFr (ORCPT ); Fri, 17 Jul 2020 21:05:47 -0400 Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 43519C0619D3 for ; Fri, 17 Jul 2020 18:05:47 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id g10so8090600wmc.1 for ; Fri, 17 Jul 2020 18:05:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=atishpatra.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LE3moRbyBfkEEvwl1ynsLf05iOxnrGFtEat6arjyjJA=; b=DlQrUmEcVs+sEzs7LTd6DciH8etJ7IwCujSHeDADxBNWKlerCcMjspn/MdYRgsubVO eTUPZ9yUuqQCMtLBhNQ3KgfTfCtnpEDh+rCd+1VBseJoD6abQWrF1PCQ+R7sbSO/cDgu sv9WWSlhBIos7DU49J+FTiOuQAgdnZvz8oTW4= 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=LE3moRbyBfkEEvwl1ynsLf05iOxnrGFtEat6arjyjJA=; b=JDL5BKGIZhIN9kdr/5GJtCUEVHeASk44OH9SFV8gMYFjLwYEuyvROvVfhNcqh/dk4G 4mG+8+3iwo2kBWnANK6cPg5nBWqbqG5OpeiqcM33yhY4i/uBgoc7QPzyxnSqPXDbyIVq zDAVt586HomMlr5IxLMkgqzqa6bRgeTOub7nFrv0k7amxH8Q7c7P9wZoJ4gyqgjEQfEm RB8TiH5845UGksQhJpgZ6oozEZoaKkxIGaN5B+O1TsnsjN5eF1u7Z6wLBOUtMhX6SeBF S9y6PUHoYUPPY886P/EAh3ccsvPRAwU2PsTlqW92wG2Equv9LxByJZIij4TiuaXPoNHn OivA== X-Gm-Message-State: AOAM532ducAprZguceMGtbZp5ulyQdCIJnSxgYgTwMHhOKLiRiAR65ME ZjHCg5DKKvsDleeAJnc2B9aT8ku8LpopwAiECEwJ X-Received: by 2002:a1c:345:: with SMTP id 66mr11309396wmd.31.1595034344969; Fri, 17 Jul 2020 18:05:44 -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: Atish Patra Date: Fri, 17 Jul 2020 18:05:34 -0700 Message-ID: Subject: Re: [RFT PATCH v3 1/9] RISC-V: Move DT mapping outof fixmap To: Arnd Bergmann 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" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jul 16, 2020 at 11:32 PM Arnd Bergmann wrote: > > On Fri, Jul 17, 2020 at 1:41 AM Atish Patra wrote: > > > > From: Anup Patel > > > > Currently, RISC-V reserves 1MB of fixmap memory for device tree. However, > > it maps only single PMD (2MB) space for fixmap which leaves only < 1MB space > > left for other kernel features such as early ioremap which requires fixmap > > as well. The fixmap size can be increased by another 2MB but it brings > > additional complexity and changes the virtual memory layout as well. > > If we require some additional feature requiring fixmap again, it has to be > > moved again. > > > > Technically, DT doesn't need a fixmap as the memory occupied by the DT is > > only used during boot. Thus, init memory section can be used for the same > > purpose as well. This simplifies fixmap implementation. > > > > Signed-off-by: Anup Patel > > Signed-off-by: Atish Patra > > The patch seems fine for the moment, but I have one concern for the > long run: > > > +#define DTB_EARLY_SIZE SZ_1M > > +static char early_dtb[DTB_EARLY_SIZE] __initdata; > > Hardcoding the size in .bss seems slightly problematic both for > small and for big systems. On machines with very little memory, > this can lead to running out of free pages before .initdata gets freed, > and it increases the size of the uncompressed vmlinux file by quite > a bit. > > On some systems, the 1MB limit may get too small. While most dtbs > would fall into the range between 10KB and 100KB, it can also be > much larger than that, e.g. when there are DT properties that include > blobs like device firmware that gets loaded into hardware by a kernel > driver. > I was not aware that we can do such things. Is there a current example of that ? > Is there anything stopping you from parsing the FDT in its original > location without the extra copy before it gets unflattened? > 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. > Arnd -- Regards, Atish