Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp600610pxk; Wed, 9 Sep 2020 13:40:17 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwjIURysvSLhtCL8teaOOlolx/9mD2CSoHg4jmU4wUuku5y8M8rcNCQ0gGty9UePWN2RwfO X-Received: by 2002:a05:6402:48a:: with SMTP id k10mr6167713edv.22.1599684017715; Wed, 09 Sep 2020 13:40:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1599684017; cv=none; d=google.com; s=arc-20160816; b=xw/ji8ZQwxU9n+RXNoPiP4U57dDXJi2Z1p4cfdV5m7Dm5D44JEVHhNNJQLpPdcezcM WVvhk4WLvtPe42rlfT9zVt7F8bH5SZu7+E7nTUa7HXgXHKp9AhO3oJsZn8UJD2skjqYa AU/Xwh0r3SWEWnRj2utgaVPv0j5UtsVdYRT8HiTeuthKGobICUOEqHZ0z97qc2MeTfyi tV4PQYlMjV4r2RRCsClbNm4uJOtXRUh/NKHVrH6Lgix9f8ufTr2s+RmmvF7taQB/F+o0 uH+cq/tw2U1ZNxRdALzG5NybbMaeodwCK/1HXuiKgBc8et748A+MS6ScN2mTAse574s1 34xA== 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=IxpDQzrsNIx5XK9835G9janE/xMpHUZ2uvG496EzU4c=; b=ctV1lZVOXdwQpQ6P2BbLpYivpUJL5KXHP2ib8rhoUmnpnuNDjsO8Ux2yblfLxFu30l y2QJ8JtuNlAwIceUYsrgbz7wdaKgs84ltIaz7MxeGywW2vM/Z8GW69/ZnQAoFOLelQs4 kUZjCCpBq9XCXUpgy49/kfPJiZojdfZCSkEvi3as40rdsicl96cUQgPHVXV2rGFbc6eH kgYFCwd8tFV/VmxmBan4388ogR+QllXJ2AW+NZ8nvHPxbmJ+X7MDZNNtrRFUIWqe970y l7whJCNEhnMaODjBTcdYqaaJSqSSfQMTUpPnMaoDh0Wp7U/jSn2Zx/vr4mc1rDW7Rabi s13w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@atishpatra.org header.s=google header.b=uS92XPYq; 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 bx10si2158725edb.383.2020.09.09.13.39.54; Wed, 09 Sep 2020 13:40:17 -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=uS92XPYq; 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 S1728626AbgIIUhF (ORCPT + 99 others); Wed, 9 Sep 2020 16:37:05 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38622 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726534AbgIIUhE (ORCPT ); Wed, 9 Sep 2020 16:37:04 -0400 Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 53C7FC061755 for ; Wed, 9 Sep 2020 13:37:03 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id w2so3554578wmi.1 for ; Wed, 09 Sep 2020 13:37:03 -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=IxpDQzrsNIx5XK9835G9janE/xMpHUZ2uvG496EzU4c=; b=uS92XPYqpRhOsmDhb/M+bZTwgExe+1thV6iqBUozWBfXEodWAvbPKaUV5OpnDhj4sV d7TuGytPDfhScP3DSI91yHgQO9DxEPrMvU5abRcxLH8qsOQDmhxfL5bh+rlxACEs28g6 0nQhSHTHwstThwSDMpF5uqpI054HHm5VIWYpQ= 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=IxpDQzrsNIx5XK9835G9janE/xMpHUZ2uvG496EzU4c=; b=Wjmse0KpRxYLrcIrin0Nb0rGa2QldIbluu/CA/7OyY+QnkZ9ogjV+8omN5XfbChucE PBOERjKwLOgNgbqlJD0l0ZK//Z/Kh+JmoLySUEBtRaALcfugulzHJckXd4QlMCBnaL8O COY0hgwlgOK8Egb0n6LG6jm2nuxhcvzNeR5tJbcb5d936ZJ7YQ2MIM8RRkqliHWEKs/F Uz6sZJQf6b9Ho6QC2Xd+WBXYK3Feb/24bhoB1YUpHjVJGbIGqjViSh4QAsbd7Ybd+OZk veXOX4ggCObDCJ4IftHMv36SqtePbilELgXKRwkqf+GA/2GF9k5fvHAxG32xDILpcxD6 Jd4w== X-Gm-Message-State: AOAM533KZapkuaGsLjrorgQvBx+3EkYHP2lBLRcd0Q8C9GXn6wXBKei5 oWcjPhXpfo7DBesIb7ivyxQrjesHkue8qIme3D9w X-Received: by 2002:a1c:c20a:: with SMTP id s10mr5235421wmf.55.1599683821370; Wed, 09 Sep 2020 13:37:01 -0700 (PDT) MIME-Version: 1.0 References: <20200904155025.55718-1-xypron.glpk@gmx.de> In-Reply-To: From: Atish Patra Date: Wed, 9 Sep 2020 13:36:50 -0700 Message-ID: Subject: Re: [PATCH 1/1] efi/libstub: DRAM base calculation To: Ard Biesheuvel Cc: Heinrich Schuchardt , Atish Patra , Palmer Dabbelt , Ingo Molnar , Arvind Sankar , linux-efi , Linux Kernel Mailing List , Maxim Uvarov , Jens Wiklander 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 Wed, Sep 9, 2020 at 1:17 AM Ard Biesheuvel wrote: > > (+ Atish, Palmer) > > On Fri, 4 Sep 2020 at 18:50, Heinrich Schuchardt wrote: > > > > In the memory map the regions with the lowest addresses may be of type > > EFI_RESERVED_TYPE. The reserved areas may be discontinuous relative to the > > rest of the memory. So for calculating the maximum loading address for the > > device tree and the initial ramdisk image these reserved areas should not > > be taken into account. > > > > Signed-off-by: Heinrich Schuchardt > > --- > > drivers/firmware/efi/libstub/efi-stub.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/firmware/efi/libstub/efi-stub.c b/drivers/firmware/efi/libstub/efi-stub.c > > index c2484bf75c5d..13058ac75765 100644 > > --- a/drivers/firmware/efi/libstub/efi-stub.c > > +++ b/drivers/firmware/efi/libstub/efi-stub.c > > @@ -106,7 +106,8 @@ static unsigned long get_dram_base(void) > > map.map_end = map.map + map_size; > > > > for_each_efi_memory_desc_in_map(&map, md) { > > - if (md->attribute & EFI_MEMORY_WB) { > > + if (md->attribute & EFI_MEMORY_WB && > > + md->type != EFI_RESERVED_TYPE) { > > if (membase > md->phys_addr) > > membase = md->phys_addr; > > } > > -- > > 2.28.0 > > > > This is not the right fix - on RPi2, for instance, which has some > reserved memory at the base of DRAM, this change will result in the > first 16 MB of memory to be wasted. > > What I would prefer to do is get rid of get_dram_base() entirely - > arm64 does not use its return value in the first place, and for ARM, > the only reason we need it is so that we can place the uncompressed > kernel image as low in memory as possible, and there are probably > better ways to do that. RISC-V just started using it too, but only > passes it from handle_kernel_image() to efi_relocate_kernel(), and > afaict, passing 0x0 there instead would not cause any problems. Yes. Passing 0x0 to efi_relocate_kernel will result in a failure in efi_bs_call and it will fallback to efi_low_alloc_above which will try to assign the lowest possible available memory with 2MB alignment restriction. The only disadvantage is an extra unnecessary call to UEFI firmware which should be okay as it is not in the hotpath. -- Regards, Atish