Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp1112862imm; Wed, 4 Jul 2018 11:50:33 -0700 (PDT) X-Google-Smtp-Source: AAOMgpexozNWvE1IrATdMR+H1VG4acnwQpGvOI2598sFs/rcZ36WG+c2qNYnCbh3XY6Hbn+YQjyW X-Received: by 2002:a63:501c:: with SMTP id e28-v6mr2907727pgb.114.1530730233810; Wed, 04 Jul 2018 11:50:33 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530730233; cv=none; d=google.com; s=arc-20160816; b=PqgSxRgqfhnEHY6VKParnucYrAXC3rgygfIuLT6BbDniTs4Jk9z79qWShUU6B+COYf k49vnIFlaYDrTRJbw6G2I8J6zfuUvfNmDIvudDETazg8NycfzUAtDsndHgapnAX3mikt VDgwg/CDnXaj42BMU5cp2QJj2UxwtZ5gaWU2aUHH9kyd7hJhHfgXyYAYAoG9nE2Pgn0w ur/Rakt3IE7Z/hT1+U8pkjgUuqba0VF1h4m+//IA0cdTERBUGGTlPw1OwWB7pfTqaXpr yHzySLXQO+E5n+3li4+l0Y88czMroWw0xKTUgn4CnyMo3WDRDkv7ikB7XdzXxJBL4puy lbtg== 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 :references:in-reply-to:mime-version:dkim-signature :arc-authentication-results; bh=YKOU0/mFLqrZnq8SaepcSuK2Sz2mIDx1GjuyHLrS4Zo=; b=twk7an8fVc5J5Bs0i0/zoyDsl1g7spGBP+EexTMGOhNdBYtjoPaLEBVOi2IG1JvGQx Rh3f7VB0jU/2VfTWD17Dyo/ygTlgUtluaVjIMP9NTydGFtl5ySeyVIL7vRPaO3x6lKJg M6ePfbu6/Z/UPR5iUCTMtPj75gFvAlseJbiPZq+6I4V+1VCk25a6PtrlSaKMXT1feLrS eovnhXi3Erkj0U82zp+AYW0s1254aUa/HHpQtj7nrU0oqaLnUK6qERJB0d4RNBDhWJil Nx/nWmWEv4mqjuvSWE7199ZxwBwcsb8DbjU+PK1bNN1QAshn6meNmIgGQoIcReOC647y UD2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=bUErg5lj; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f66-v6si4183604plb.103.2018.07.04.11.50.17; Wed, 04 Jul 2018 11:50:33 -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 header.s=google header.b=bUErg5lj; 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 S1752611AbeGDStf (ORCPT + 99 others); Wed, 4 Jul 2018 14:49:35 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:39540 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752251AbeGDStd (ORCPT ); Wed, 4 Jul 2018 14:49:33 -0400 Received: by mail-it0-f66.google.com with SMTP id p185-v6so9150260itp.4 for ; Wed, 04 Jul 2018 11:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YKOU0/mFLqrZnq8SaepcSuK2Sz2mIDx1GjuyHLrS4Zo=; b=bUErg5ljww71AUhFvoNLmtAwaPTEX1ZypMCs5rtWNpQWluPQn55n0WF1QQu4x0fSUw BoKeo70z1EtP2ypvDU5YHGpJgMx5+AVy4bgiOakO/pl2Ix0xCjdxMU2tc4/qKB+2z4B4 lUtrggmvJInRy0Gq4zdAFNXfqmb+VWsGZNax0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YKOU0/mFLqrZnq8SaepcSuK2Sz2mIDx1GjuyHLrS4Zo=; b=lHAn7DfwVMF1yYrofAPjnr0wYCLosI5EEDortP4W1gpa125dJJCKjmoezOQqYNcwwH 88BQtZxGQTZKMARkybMhI/J9suRcq60vTE55Hai6lZnru5Cfn+4fe0qrKVCtZMykV/Op C8kQox13hKsnv2FaSlRyHKzdD+KEg/IsuwaOY5zdNQnmJ022JGS3spjNau1GVm/tWyIe Y8O+K1KEQokUFVFGVlFC9W+lJEQASdDm2HY+QmN/SSjZZfiV31c6E4ZxjVQLs1mW0bdx +1aNrg47FBrYCWp6CRqZRuCVc1gLlDRy71cnAVGtavnQvjuvTh+7ZzyrIS9cbKDBRaTm elPg== X-Gm-Message-State: APt69E1/bTlgcQTpPhVV0F0ac2wDNJK3Yyo/4HHlr4SrPdZbQBtuBqcG IjcyUil61k1NTciZH+3CbEvNl3SbAwDrQtTIudQYIQ== X-Received: by 2002:a24:d7c5:: with SMTP id y188-v6mr2577688itg.50.1530730173176; Wed, 04 Jul 2018 11:49:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a6b:bbc7:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 11:49:32 -0700 (PDT) In-Reply-To: <20180704170655.GD8370@arm.com> References: <20180619064424.6642-1-takahiro.akashi@linaro.org> <20180619064424.6642-4-takahiro.akashi@linaro.org> <20180704170655.GD8370@arm.com> From: Ard Biesheuvel Date: Wed, 4 Jul 2018 20:49:32 +0200 Message-ID: Subject: Re: [PATCH v2 3/4] efi/arm: map UEFI memory map earlier on boot To: Will Deacon Cc: AKASHI Takahiro , Catalin Marinas , Andrew Morton , "Baicar, Tyler" , Bhupesh Sharma , Dave Young , James Morse , Mark Rutland , Al Stone , Graeme Gregory , Hanjun Guo , Lorenzo Pieralisi , Sudeep Holla , linux-arm-kernel , Linux Kernel Mailing List , Kexec Mailing List 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 4 July 2018 at 19:06, Will Deacon wrote: > Hi all, > > [Ard -- please can you look at the EFI parts of this patch] > > On Tue, Jun 19, 2018 at 03:44:23PM +0900, AKASHI Takahiro wrote: >> Since arm_enter_runtime_services() was modified to always create a virtual >> mapping of UEFI memory map in the previous patch, it is now renamed to >> efi_enter_virtual_mode() and called earlier before acpi_load_tables() >> in acpi_early_init(). >> >> This will allow us to use UEFI memory map in acpi_os_ioremap() to create >> mappings of ACPI tables using memory attributes described in UEFI memory >> map. >> >> See a relevant commit: >> arm64: acpi: fix alignment fault in accessing ACPI tables >> >> Signed-off-by: AKASHI Takahiro >> Cc: Ard Biesheuvel >> Cc: Andrew Morton >> --- >> drivers/firmware/efi/arm-runtime.c | 15 ++++++--------- >> init/main.c | 3 +++ >> 2 files changed, 9 insertions(+), 9 deletions(-) >> >> diff --git a/drivers/firmware/efi/arm-runtime.c b/drivers/firmware/efi/arm-runtime.c >> index 30ac5c82051e..566ef0a9edb5 100644 >> --- a/drivers/firmware/efi/arm-runtime.c >> +++ b/drivers/firmware/efi/arm-runtime.c >> @@ -106,46 +106,43 @@ static bool __init efi_virtmap_init(void) >> * non-early mapping of the UEFI system table and virtual mappings for all >> * EFI_MEMORY_RUNTIME regions. >> */ >> -static int __init arm_enable_runtime_services(void) >> +void __init efi_enter_virtual_mode(void) >> { >> u64 mapsize; >> >> if (!efi_enabled(EFI_BOOT)) { >> pr_info("EFI services will not be available.\n"); >> - return 0; >> + return; >> } >> >> mapsize = efi.memmap.desc_size * efi.memmap.nr_map; >> >> if (efi_memmap_init_late(efi.memmap.phys_map, mapsize)) { >> pr_err("Failed to remap EFI memory map\n"); >> - return 0; >> + return; >> } >> >> if (efi_runtime_disabled()) { >> pr_info("EFI runtime services will be disabled.\n"); >> - return 0; >> + return; >> } >> >> if (efi_enabled(EFI_RUNTIME_SERVICES)) { >> pr_info("EFI runtime services access via paravirt.\n"); >> - return 0; >> + return; >> } >> >> pr_info("Remapping and enabling EFI services.\n"); >> >> if (!efi_virtmap_init()) { >> pr_err("UEFI virtual mapping missing or invalid -- runtime services will not be available\n"); >> - return -ENOMEM; >> + return; >> } >> >> /* Set up runtime services function pointers */ >> efi_native_runtime_setup(); >> set_bit(EFI_RUNTIME_SERVICES, &efi.flags); >> - >> - return 0; >> } >> -early_initcall(arm_enable_runtime_services); >> >> void efi_virtmap_load(void) >> { >> diff --git a/init/main.c b/init/main.c >> index 3b4ada11ed52..532fc0d02353 100644 >> --- a/init/main.c >> +++ b/init/main.c >> @@ -694,6 +694,9 @@ asmlinkage __visible void __init start_kernel(void) >> debug_objects_mem_init(); >> setup_per_cpu_pageset(); >> numa_policy_init(); >> + if (IS_ENABLED(CONFIG_EFI) && >> + (IS_ENABLED(CONFIG_ARM64) || IS_ENABLED(CONFIG_ARM))) >> + efi_enter_virtual_mode(); > > Hmm, this is ugly as hell. Is there nothing else we can piggy-back off? > It's also fairly jarring that, on x86, efi_enter_virtual_mode() is called > a few lines later, *after* acpi_early_init() has been called. > Currently, there is a gap where we have already torn down the early mapping and haven't created the definitive mapping of the UEFI memory map. There are other reasons why this is an issue, and I recently proposed [0] myself to address one of them (and I didn't remember this particular series, or the fact that I actually suggested this approach IIRC) Akashi-san, could you please confirm whether the patch below would be sufficient for you? Apologies for going back and forth on this, but I agree with Will that we should try to avoid warts like the one above in generic code. [0] https://marc.info/?l=linux-efi&m=152930773507524&w=2 > The rest of the series looks fine to me, but I'm not comfortable taking > changes like this via the arm64 tree. > > Will