From mboxrd@z Thu Jan 1 00:00:00 1970 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 7FD26C433F5 for ; Wed, 10 Nov 2021 13:36:32 +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 3BB2B61211 for ; Wed, 10 Nov 2021 13:36:32 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 3BB2B61211 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=xen.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.224300.387532 (Exim 4.92) (envelope-from ) id 1mknly-00050a-0w; Wed, 10 Nov 2021 13:36:18 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 224300.387532; Wed, 10 Nov 2021 13:36:17 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mknlx-00050T-Ti; Wed, 10 Nov 2021 13:36:17 +0000 Received: by outflank-mailman (input) for mailman id 224300; Wed, 10 Nov 2021 13:36:16 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mknlw-00050M-Dq for xen-devel@lists.xenproject.org; Wed, 10 Nov 2021 13:36:16 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1mknlt-0002i6-2P; Wed, 10 Nov 2021 13:36:13 +0000 Received: from 54-240-197-239.amazon.com ([54.240.197.239] helo=[192.168.19.173]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mknls-0007EF-SB; Wed, 10 Nov 2021 13:36:13 +0000 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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=2HeERBqFGcE4/ONKmD9LNZi0lWIeIzEOqoGVgt5VdOE=; b=iSm8ZZirp9dxbI15HpnKpsJdlg 1RyQeeaH/SS/0sbWXeD+m2Ur3CL6r4sCQ3OihnNymkbVBbRsUAKLyso68cvIQnX/FOiCsil1cx7Xi r3gHtRfRaLFYddrA0VBsYpOfBH+o40a0x5NGipVSO/EkON721DCAs342HEAbnFOxdhFY=; Message-ID: <010fa02f-e561-e7a8-9638-5246db9166b4@xen.org> Date: Wed, 10 Nov 2021 13:36:10 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: [PATCH-4.16 v2] xen/efi: Fix Grub2 boot on arm64 To: Luca Fancellu , Stefano Stabellini Cc: Jan Beulich , Bertrand Marquis , wei.chen@arm.com, Ian Jackson , Volodymyr Babchuk , xen-devel@lists.xenproject.org References: <20211104141206.25153-1-luca.fancellu@arm.com> <81685961-501e-7a41-6f6f-bc4491645264@suse.com> <97C884F7-0577-4996-AB79-0A07A8D48FD8@arm.com> <9E52FA33-422B-4B1C-A6AF-601CDF565700@arm.com> <9bd58aa4-602b-4c64-e759-581513909457@suse.com> <191dd1b2-8e2a-ee91-f401-dda4fabf4c7c@suse.com> <3B8E0C6E-0522-4F73-B6C2-827FA45C87BA@arm.com> From: Julien Grall In-Reply-To: <3B8E0C6E-0522-4F73-B6C2-827FA45C87BA@arm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi Luca, On 10/11/2021 13:05, Luca Fancellu wrote: > I thought having the EFI_FILE_HANDLE global in efi-boot.h was a “no go”, but if it’s not then instead of > calling get_parent_handle in efi_check_dt_boot (that is the main issue with EDK2+Grub2), we can do > something like this: fs_dir_handle is only used by callees of efi_check_boot_dt_boot(). So the global variable is not an option for me because the risk is not worth it (it is easy to misuse a global variable). Instead, I think fs_dir_handle should be an argument of allocate_module_file() and propagated up to the first call in efi_check_dt_boot(). Cheers, -- Julien Grall