From patchwork Thu Sep 30 14:28:44 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Luca Fancellu X-Patchwork-Id: 12528533 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B3EE3C4332F for ; Thu, 30 Sep 2021 14:29:12 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 7F84961A08 for ; Thu, 30 Sep 2021 14:29:12 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 7F84961A08 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.199967.354319 (Exim 4.92) (envelope-from ) id 1mVx3Y-0004xQ-MT; Thu, 30 Sep 2021 14:29:04 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 199967.354319; Thu, 30 Sep 2021 14:29:04 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mVx3Y-0004xF-Ig; Thu, 30 Sep 2021 14:29:04 +0000 Received: by outflank-mailman (input) for mailman id 199967; Thu, 30 Sep 2021 14:29:03 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mVx3W-0004f4-Vb for xen-devel@lists.xenproject.org; Thu, 30 Sep 2021 14:29:03 +0000 Received: from foss.arm.com (unknown [217.140.110.172]) by us1-rack-iad1.inumbo.com (Halon) with ESMTP id 138cb30a-50fd-4426-a5a2-b52cb5b73a10; Thu, 30 Sep 2021 14:28:57 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 615E8113E; Thu, 30 Sep 2021 07:28:57 -0700 (PDT) Received: from e125770.cambridge.arm.com (e125770.cambridge.arm.com [10.1.195.16]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id EB7113F70D; Thu, 30 Sep 2021 07:28:55 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 138cb30a-50fd-4426-a5a2-b52cb5b73a10 From: Luca Fancellu To: xen-devel@lists.xenproject.org Cc: bertrand.marquis@arm.com, wei.chen@arm.com, Stefano Stabellini , Julien Grall , Volodymyr Babchuk , Andrew Cooper , George Dunlap , Ian Jackson , Jan Beulich , Wei Liu Subject: [PATCH v4 1/3] arm/efi: Introduce xen,uefi-cfg-load DT property Date: Thu, 30 Sep 2021 15:28:44 +0100 Message-Id: <20210930142846.13348-2-luca.fancellu@arm.com> X-Mailer: git-send-email 2.17.1 In-Reply-To: <20210930142846.13348-1-luca.fancellu@arm.com> References: <20210930142846.13348-1-luca.fancellu@arm.com> Introduce the xen,uefi-cfg-load DT property of /chosen node for ARM whose presence decide whether to force the load of the UEFI Xen configuration file. The logic is that if any multiboot,module is found in the DT, then the xen,uefi-cfg-load property is used to see if the UEFI Xen configuration file is needed. Modify a comment in efi_arch_use_config_file, removing the part that states "dom0 required" because it's not true anymore with this commit. Signed-off-by: Luca Fancellu Reviewed-by: Stefano Stabellini Reviewed-by: Bertrand Marquis --- v4 changes: - modify property name to xen,uefi-cfg-load v3 changes: - add documentation to misc/arm/device-tree/booting.txt - Modified variable name and logic from skip_cfg_file to load_cfg_file - Add in the commit message that I'm modifying a comment. v2 changes: - Introduced uefi,cfg-load property - Add documentation about the property --- docs/misc/arm/device-tree/booting.txt | 8 ++++++++ docs/misc/efi.pandoc | 2 ++ xen/arch/arm/efi/efi-boot.h | 28 ++++++++++++++++++++++----- 3 files changed, 33 insertions(+), 5 deletions(-) diff --git a/docs/misc/arm/device-tree/booting.txt b/docs/misc/arm/device-tree/booting.txt index 44cd9e1a9a..352b0ec43a 100644 --- a/docs/misc/arm/device-tree/booting.txt +++ b/docs/misc/arm/device-tree/booting.txt @@ -121,6 +121,14 @@ A Xen-aware bootloader would set xen,xen-bootargs for Xen, xen,dom0-bootargs for Dom0 and bootargs for native Linux. +UEFI boot and DT +================ + +When Xen is booted using UEFI, it doesn't read the configuration file if any +multiboot module is specified. To force Xen to load the configuration file, the +boolean property xen,uefi-cfg-load must be declared in the /chosen node. + + Creating Multiple Domains directly from Xen =========================================== diff --git a/docs/misc/efi.pandoc b/docs/misc/efi.pandoc index ac3cd58cae..ed85351541 100644 --- a/docs/misc/efi.pandoc +++ b/docs/misc/efi.pandoc @@ -14,6 +14,8 @@ loaded the modules and describes them in the device tree provided to Xen. If a bootloader provides a device tree containing modules then any configuration files are ignored, and the bootloader is responsible for populating all relevant device tree nodes. +The property "xen,uefi-cfg-load" can be specified in the /chosen node to force +Xen to load the configuration file even if multiboot modules are found. Once built, `make install-xen` will place the resulting binary directly into the EFI boot partition, provided `EFI_VENDOR` is set in the environment (and diff --git a/xen/arch/arm/efi/efi-boot.h b/xen/arch/arm/efi/efi-boot.h index cf9c37153f..a3e46453d4 100644 --- a/xen/arch/arm/efi/efi-boot.h +++ b/xen/arch/arm/efi/efi-boot.h @@ -581,22 +581,40 @@ static void __init efi_arch_load_addr_check(EFI_LOADED_IMAGE *loaded_image) static bool __init efi_arch_use_config_file(EFI_SYSTEM_TABLE *SystemTable) { + bool load_cfg_file = true; /* * For arm, we may get a device tree from GRUB (or other bootloader) * that contains modules that have already been loaded into memory. In - * this case, we do not use a configuration file, and rely on the - * bootloader to have loaded all required modules and appropriate - * options. + * this case, we search for the property xen,uefi-cfg-load in the /chosen + * node to decide whether to skip the UEFI Xen configuration file or not. */ fdt = lookup_fdt_config_table(SystemTable); dtbfile.ptr = fdt; dtbfile.need_to_free = false; /* Config table memory can't be freed. */ - if ( !fdt || fdt_node_offset_by_compatible(fdt, 0, "multiboot,module") < 0 ) + + if ( fdt_node_offset_by_compatible(fdt, 0, "multiboot,module") > 0 ) + { + /* Locate chosen node */ + int node = fdt_subnode_offset(fdt, 0, "chosen"); + const void *cfg_load_prop; + int cfg_load_len; + + if ( node > 0 ) + { + /* Check if xen,uefi-cfg-load property exists */ + cfg_load_prop = fdt_getprop(fdt, node, "xen,uefi-cfg-load", + &cfg_load_len); + if ( !cfg_load_prop ) + load_cfg_file = false; + } + } + + if ( !fdt || load_cfg_file ) { /* * We either have no FDT, or one without modules, so we must have a - * Xen EFI configuration file to specify modules. (dom0 required) + * Xen EFI configuration file to specify modules. */ return true; }