From patchwork Tue Apr 4 16:02:39 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 96741 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp263287qgd; Tue, 4 Apr 2017 09:03:36 -0700 (PDT) X-Received: by 10.99.147.16 with SMTP id b16mr24981804pge.126.1491321816479; Tue, 04 Apr 2017 09:03:36 -0700 (PDT) Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c1si7404096pge.59.2017.04.04.09.03.36; Tue, 04 Apr 2017 09:03:36 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932140AbdDDQD3 (ORCPT + 25 others); Tue, 4 Apr 2017 12:03:29 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36097 "EHLO mail-wm0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932092AbdDDQDZ (ORCPT ); Tue, 4 Apr 2017 12:03:25 -0400 Received: by mail-wm0-f41.google.com with SMTP id o81so29493173wmb.1 for ; Tue, 04 Apr 2017 09:03:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=HdQqJl8Qda/2hBvEmVzQTsn5K/1JnqrEU3fXfndOhIo=; b=cXPoROjW+4jEPDOw6deIk+2eHYbHUo/Id3ckUe6a1yKYjv/LdUOInaK/tdG//y+V5b dFOq+2ZE0gDW8EUCjPM/beKhcA2ukow3e62u3c8o43L6D9SOF7VYKSpRVidftPTD2ZC2 CfFZeMepCN3MWRPhn3lQCxv7R0m9J17gqVi8M= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=HdQqJl8Qda/2hBvEmVzQTsn5K/1JnqrEU3fXfndOhIo=; b=I9mX05ht8Fxro7tt6YTDNEki3pbduNeR8T2IJSVTFkUtltf7ejd/5fo0rDYKkvVw6h KuKlDdESkc+fRFzc45afKg1ftpWZoe3FS0I8MKIYdVe8nQeaRSFsGbMlSuuM98mz0C4s CHFlz1LfVa7/DCdxg7Eu+d+abJj6MJur6BQspP/VVM76y4XxlGa+9dVv91MZ52T2K+Wp 6WeeUZJf3Qgn80pcsUsBVxnGyQaY8MuAOYkmwZfF+qb2F3uCWQn9kWV9g1ufxuOd6SDA 5NYkrBTkXAjaJ68rKVAS6MKSsI9XnuAFflexlkFdU/99VNNEMrmKef4c1Q5lquv93tUl 6qVQ== X-Gm-Message-State: AFeK/H2jYmijiE82m34EtHbmKteHwpKp6eeT5LnaAIi7tJi1HpTDeuHv +UpL4MVV5GjSyxFW X-Received: by 10.28.87.138 with SMTP id l132mr15310112wmb.95.1491321798432; Tue, 04 Apr 2017 09:03:18 -0700 (PDT) Received: from localhost.localdomain ([160.163.145.113]) by smtp.gmail.com with ESMTPSA id z88sm19686465wrb.1.2017.04.04.09.03.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 04 Apr 2017 09:03:17 -0700 (PDT) From: Ard Biesheuvel To: linux-efi@vger.kernel.org, Ingo Molnar , Thomas Gleixner , "H . Peter Anvin" Cc: Ard Biesheuvel , linux-kernel@vger.kernel.org Subject: [PATCH 03/12] efi: arm-stub: Round up FDT allocation to mapping size Date: Tue, 4 Apr 2017 17:02:39 +0100 Message-Id: <20170404160245.27812-6-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 In-Reply-To: <20170404160245.27812-1-ard.biesheuvel@linaro.org> References: <20170404160245.27812-1-ard.biesheuvel@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The FDT is mapped via a fixmap entry that is at least 2 MB in size and 2 MB aligned on 4 KB page size kernels. On UEFI systems, the FDT allocation may share this 2 MB mapping with a reserved region (or another memory region that we should never map), unless we account for this in the size of the allocation (the alignment is already 2 MB) So instead of taking guesses at the needed space, simply allocate 2 MB immediately. The allocation will be recorded as EFI_LOADER_DATA, and the kernel only memblock_reserve()'s the actual size of the FDT, so the unused space will be released back to the kernel. Cc: Matt Fleming Tested-by: Richard Ruigrok Reviewed-By: Jeffrey Hugo Signed-off-by: Ard Biesheuvel --- arch/arm64/include/asm/efi.h | 1 + drivers/firmware/efi/libstub/fdt.c | 57 ++++++++++++++++---------------------- 2 files changed, 25 insertions(+), 33 deletions(-) -- 2.9.3 diff --git a/arch/arm64/include/asm/efi.h b/arch/arm64/include/asm/efi.h index 083a52d3b59f..8f3043aba873 100644 --- a/arch/arm64/include/asm/efi.h +++ b/arch/arm64/include/asm/efi.h @@ -1,6 +1,7 @@ #ifndef _ASM_EFI_H #define _ASM_EFI_H +#include #include #include #include diff --git a/drivers/firmware/efi/libstub/fdt.c b/drivers/firmware/efi/libstub/fdt.c index 260c4b4b492e..41f457be64e8 100644 --- a/drivers/firmware/efi/libstub/fdt.c +++ b/drivers/firmware/efi/libstub/fdt.c @@ -206,6 +206,10 @@ static efi_status_t exit_boot_func(efi_system_table_t *sys_table_arg, return update_fdt_memmap(p->new_fdt_addr, map); } +#ifndef MAX_FDT_SIZE +#define MAX_FDT_SIZE SZ_2M +#endif + /* * Allocate memory for a new FDT, then add EFI, commandline, and * initrd related fields to the FDT. This routine increases the @@ -233,7 +237,6 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table, u32 desc_ver; unsigned long mmap_key; efi_memory_desc_t *memory_map, *runtime_map; - unsigned long new_fdt_size; efi_status_t status; int runtime_entry_count = 0; struct efi_boot_memmap map; @@ -262,41 +265,29 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table, "Exiting boot services and installing virtual address map...\n"); map.map = &memory_map; + status = efi_high_alloc(sys_table, MAX_FDT_SIZE, EFI_FDT_ALIGN, + new_fdt_addr, max_addr); + if (status != EFI_SUCCESS) { + pr_efi_err(sys_table, + "Unable to allocate memory for new device tree.\n"); + goto fail; + } + /* - * Estimate size of new FDT, and allocate memory for it. We - * will allocate a bigger buffer if this ends up being too - * small, so a rough guess is OK here. + * Now that we have done our final memory allocation (and free) + * we can get the memory map key needed for exit_boot_services(). */ - new_fdt_size = fdt_size + EFI_PAGE_SIZE; - while (1) { - status = efi_high_alloc(sys_table, new_fdt_size, EFI_FDT_ALIGN, - new_fdt_addr, max_addr); - if (status != EFI_SUCCESS) { - pr_efi_err(sys_table, "Unable to allocate memory for new device tree.\n"); - goto fail; - } - - status = update_fdt(sys_table, - (void *)fdt_addr, fdt_size, - (void *)*new_fdt_addr, new_fdt_size, - cmdline_ptr, initrd_addr, initrd_size); + status = efi_get_memory_map(sys_table, &map); + if (status != EFI_SUCCESS) + goto fail_free_new_fdt; - /* Succeeding the first time is the expected case. */ - if (status == EFI_SUCCESS) - break; + status = update_fdt(sys_table, (void *)fdt_addr, fdt_size, + (void *)*new_fdt_addr, MAX_FDT_SIZE, cmdline_ptr, + initrd_addr, initrd_size); - if (status == EFI_BUFFER_TOO_SMALL) { - /* - * We need to allocate more space for the new - * device tree, so free existing buffer that is - * too small. - */ - efi_free(sys_table, new_fdt_size, *new_fdt_addr); - new_fdt_size += EFI_PAGE_SIZE; - } else { - pr_efi_err(sys_table, "Unable to construct new device tree.\n"); - goto fail_free_new_fdt; - } + if (status != EFI_SUCCESS) { + pr_efi_err(sys_table, "Unable to construct new device tree.\n"); + goto fail_free_new_fdt; } priv.runtime_map = runtime_map; @@ -340,7 +331,7 @@ efi_status_t allocate_new_fdt_and_exit_boot(efi_system_table_t *sys_table, pr_efi_err(sys_table, "Exit boot services failed.\n"); fail_free_new_fdt: - efi_free(sys_table, new_fdt_size, *new_fdt_addr); + efi_free(sys_table, MAX_FDT_SIZE, *new_fdt_addr); fail: sys_table->boottime->free_pool(runtime_map);