From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1lOPIR-0002tk-MA for mharc-grub-devel@gnu.org; Mon, 22 Mar 2021 14:28:59 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33154) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOPIQ-0002re-Ga for grub-devel@gnu.org; Mon, 22 Mar 2021 14:28:58 -0400 Received: from mail-ed1-x531.google.com ([2a00:1450:4864:20::531]:39672) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lOPIO-0007oC-DF for grub-devel@gnu.org; Mon, 22 Mar 2021 14:28:58 -0400 Received: by mail-ed1-x531.google.com with SMTP id bf3so20587566edb.6 for ; Mon, 22 Mar 2021 11:28:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=7r0Y1bQZzxInYrEnf8GosAan9pKQ9L24r/H1/CTIpKo=; b=kVZPOh07cXdd2VcE7yzy3F1ZcMmBuREAEjZyJR2BPRWk2Lt4LFNoQHbnJaUSvhdH4Q EKiPW9EuL8f8kv0yVG+eoaHp2C/dgQtZhJjjqX+FUn8AcHwzpUKw+UrP63EMinF/4N06 fmcHxv0LpC67/1MmQuAGhQVUyQR5pFIiAezn5D/M+ffaHrcJ3CgCsphttOsaHnI1z213 cX2rW6sR86ywNUJimA+4c3nsdZIHa1gge7g/chfhG4o85+6uiS//eKnaUxt1+tLnTmPX bbV1kgsoEeqnNK3Gl9R0W3oRGfiF95Oi4yEw71nUWPEDER7jCBXI6kD6nFclp7I1rkOf WolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=7r0Y1bQZzxInYrEnf8GosAan9pKQ9L24r/H1/CTIpKo=; b=VzRJldB6xtYB7Aq93fbqLx+4gXpDBdfHgbQQoe/Q0Mrte9MKB3j1RMLaMzgJmsMKne SknsrqK6RZIrVlbBlalBHr/wMXCL+tDhxIsVcel68LlSd7v8JrI6Bl24+EG2IXz6E+iL mA87/8HQDvgRgZ2JenuRKYZOGcxoMj2KU2DxNLlsontSBbLpfVoq0UyU1W4UY3BBtQl1 yP0Qweu5fdyOOvc79YjESDvzCkMcDB1ALHplW5YrHFkpquLfW7NJRiJRAd1e/LN8qPvi AJ9AsuA5AY7718RZT/gywWEN+QEvVNkhyOMBhQZ7SUkf7sSVKeZHgxZzXIBYYEAG39OZ c3jg== X-Gm-Message-State: AOAM531TDuCes2lusyniGL442dk227IqVF7GcTAQz4B7lEhH8gOls/f2 aYsN0oCxOAzpqvEsM8QZgiU/MA== X-Google-Smtp-Source: ABdhPJxKCUoR+hQB17DB8nikbAjimHaJkDJGMfhIx9uiHvvB5BU/FPXBBH5EtFr1YKiTeYKlpvjn6Q== X-Received: by 2002:a05:6402:b70:: with SMTP id cb16mr962917edb.11.1616437733323; Mon, 22 Mar 2021 11:28:53 -0700 (PDT) Received: from vanye (cpc1-cmbg19-2-0-cust915.5-4.cable.virginm.net. [82.27.183.148]) by smtp.gmail.com with ESMTPSA id q12sm10091891ejy.91.2021.03.22.11.28.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 22 Mar 2021 11:28:52 -0700 (PDT) Date: Mon, 22 Mar 2021 18:28:51 +0000 From: Leif Lindholm To: Daniel Kiper Cc: Vincent =?iso-8859-1?Q?Stehl=E9?= , grub-devel@gnu.org, Grant Likely , Peter Jones Subject: Re: [PATCH] arm/efi: fix ram base detection Message-ID: <20210322182851.GY1664@vanye> References: <20210312165455.22346-1-vincent.stehle@laposte.net> <20210322160015.sfpzc52twysubybe@tomti.i.net-space.pl> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210322160015.sfpzc52twysubybe@tomti.i.net-space.pl> User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: pass client-ip=2a00:1450:4864:20::531; envelope-from=leif@nuviainc.com; helo=mail-ed1-x531.google.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Mar 2021 18:28:58 -0000 On Mon, Mar 22, 2021 at 17:00:15 +0100, Daniel Kiper wrote: > On Fri, Mar 12, 2021 at 05:54:55PM +0100, Vincent Stehlé via Grub-devel wrote: > > On 32b Arm platforms, grub allocates memory for the initrd in the first > > 512MB of DRAM. To do so, the grub_efi_get_ram_base() function will be > > called to compute the DRAM base. Currently this function returns the lowest > > start address of all memory regions with attribute write-back. > > > > However, if for example a small memory region with type reserved and > > attribute write-back is present at the bottom of the memory map, it will be > > chosen as DRAM base and initrd memory allocation will fail with: > > > > error: out of memory. > > > > Press any key to continue... > > > > This is indeed the case with qemu arm machine virt when the secure world is > > enabled and TF-A and OP-TEE are used. The secure world firmware will > > reserve secure memory, resulting in the following EFI memory map: > > > > Type Physical start - end #Pages Size Attributes > > reserved 000000000e100000-000000000effffff 00000f00 15MiB WB > > conv-mem 0000000040000000-0000000047ef9fff 00007efa 130024KiB WB > > ACPI-rec 0000000047efa000-0000000047f05fff 0000000c 48KiB WB > > conv-mem 0000000047f06000-000000006d4f9fff 000255f4 612304KiB WB > > ldr-data 000000006d4fa000-000000006d4fafff 00000001 4KiB WB > > ... > > > > In this case, the DRAM base is computed as 0xe100000, while it should be > > 0x40000000 instead. > > > > Fix this issue by considering only conventional memory with attribute > > write-back for DRAM base computation. > > > > This is similar to what is done by Peter Jones in commit 3c1a5d940be5 > > ("arm/arm64 loader: Better memory allocation and error messages.") in > > Fedora's grub[1]. This patch reduces the modifications to a minimum. > > > > [1]: https://github.com/rhboot/grub2.git > > > > Fixes: bad144c60f66 ("efi: Add grub_efi_get_ram_base() function for arm64") > > Suggested-by: Grant Likely > > Signed-off-by: Vincent Stehlé > > Cc: Peter Jones > > Cc: Leif Lindholm > > s/leif.lindholm@linaro.org/leif@nuviainc.com/ Thanks :) > Reviewed-by: Daniel Kiper > > > --- > > grub-core/kern/efi/mm.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/grub-core/kern/efi/mm.c b/grub-core/kern/efi/mm.c > > index 0cdb063bb..abf8772bc 100644 > > --- a/grub-core/kern/efi/mm.c > > +++ b/grub-core/kern/efi/mm.c > > @@ -677,7 +677,8 @@ grub_efi_get_ram_base(grub_addr_t *base_addr) > > for (desc = memory_map, *base_addr = GRUB_EFI_MAX_USABLE_ADDRESS; > > (grub_addr_t) desc < ((grub_addr_t) memory_map + memory_map_size); > > desc = NEXT_MEMORY_DESCRIPTOR (desc, desc_size)) > > - if (desc->attribute & GRUB_EFI_MEMORY_WB) > > + if (desc->type == GRUB_EFI_CONVENTIONAL_MEMORY && > > + desc->attribute & GRUB_EFI_MEMORY_WB) Can we safely assume we don't also need to check against GRUB_EFI_PERSISTENT_MEMORY? If so, this is fine. / Leif > > *base_addr = grub_min (*base_addr, desc->physical_start); > > > > grub_free(memory_map); > > -- > > 2.30.0 > > > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel