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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id DE091C4332F for ; Wed, 19 Oct 2022 03:25:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:CC:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Owner; bh=hg93Sa8FRA3H43BoQxeqScYBCJoM2pR/9qHra2sIKJo=; b=oJGiJCyO6J7CBaMsbO5XaYAu+A kdDkc3B5LFK4Zy3pd72q/dzVO50HPmW+TfIANcX8IuYKXiqUnGQeiIo08gQSytsP63qAfTuBluC6w L2I8LJtIUEyzDaRu1n+LOGDQAnkhIWpEZXfzJcCAhtcWBb5xnOVPf8gPlJM1ocXei8tgQPP6R+3Xw /9Qtl7uM5psmUiCfoKjKlcWOHJwriF696tZ/+yH18uGxi4TZF6+vtk3eUIElq8C+We9Ca3zBLBTwC kSWqawZviVX2JxhMeHlsMaTRc+7NaXiqU09qYpDnzKXeHT3ycAJ8yFgbNr14d/q1noVyD5x6R2zbL BWqGkB8g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1okzgs-00EG6z-2j; Wed, 19 Oct 2022 03:24:22 +0000 Received: from szxga08-in.huawei.com ([45.249.212.255]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1okzgo-00EG5w-A8 for linux-arm-kernel@lists.infradead.org; Wed, 19 Oct 2022 03:24:20 +0000 Received: from canpemm500009.china.huawei.com (unknown [172.30.72.55]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4MsbYh5JFQz1P786; Wed, 19 Oct 2022 11:19:20 +0800 (CST) Received: from [10.67.102.169] (10.67.102.169) by canpemm500009.china.huawei.com (7.192.105.203) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Wed, 19 Oct 2022 11:24:03 +0800 CC: , , , , , , , Linuxarm Subject: Re: [PATCH] efi/libstub: arm64: avoid SetVirtualAddressMap() when possible To: Ard Biesheuvel , References: <20220916101843.495879-1-ardb@kernel.org> From: Yicong Yang Message-ID: <56877644-8173-d2ed-ed00-7973734a3698@huawei.com> Date: Wed, 19 Oct 2022 11:24:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <20220916101843.495879-1-ardb@kernel.org> X-Originating-IP: [10.67.102.169] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To canpemm500009.china.huawei.com (7.192.105.203) X-CFilter-Loop: Reflected X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221018_202418_575755_44F10C18 X-CRM114-Status: GOOD ( 23.84 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Ard, After entering 6.1-rc1 the efi runtime services is not working on my platform: [ 0.054039] Remapping and enabling EFI services. [ 0.054043] UEFI virtual mapping missing or invalid -- runtime services will not be available Not sure this patch is the root cause since I see some refactor of efi codes in 6.1-rc1, but simply reverting this make EFI runtime services works again. Tested on HiSilicon's Kunpeng 920 arm64 server using 48 bit VA address: CONFIG_ARM64_VA_BITS_48=y CONFIG_ARM64_VA_BITS=48 Thanks. On 2022/9/16 18:18, Ard Biesheuvel wrote: > EFI's SetVirtualAddressMap() runtime service is a horrid hack that we'd > like to avoid using, if possible. For 64-bit architectures such as > arm64, the user and kernel mappings are entirely disjoint, and given > that we use the user region for mapping the UEFI runtime regions when > running under the OS, we don't rely on SetVirtualAddressMap() in the > conventional way, i.e., to permit kernel mappings of the OS to coexist > with kernel region mappings of the firmware regions. This means that, in > principle, we should be able to avoid SetVirtualAddressMap() altogether, > and simply use the 1:1 mapping that UEFI uses at boot time. (Note that > omitting SetVirtualAddressMap() is explicitly permitted by the UEFI > spec). > > However, there is a corner case on arm64, which, if configured for > 3-level paging (or 2-level paging when using 64k pages), may not be able > to cover the entire range of firmware mappings (which might contain both > memory and MMIO peripheral mappings). > > So let's avoid SetVirtualAddressMap() on arm64, but only if the VA space > is guaranteed to be of sufficient size. > > Signed-off-by: Ard Biesheuvel > --- > drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/drivers/firmware/efi/libstub/arm64-stub.c b/drivers/firmware/efi/libstub/arm64-stub.c > index cd3bea25c762..4fff6c32899e 100644 > --- a/drivers/firmware/efi/libstub/arm64-stub.c > +++ b/drivers/firmware/efi/libstub/arm64-stub.c > @@ -31,6 +31,15 @@ efi_status_t check_platform_features(void) > efi_err("This 16 KB granular kernel is not supported by your CPU\n"); > return EFI_UNSUPPORTED; > } > + > + /* > + * If we have 48 bits of VA space for TTBR0 mappings, we can map the > + * UEFI runtime regions 1:1 and so calling SetVirtualAddressMap() is > + * unnecessary. > + */ > + if (VA_BITS_MIN >= 48) > + efi_novamap = true; > + > return EFI_SUCCESS; > } > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel