From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [80.237.130.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8D71415AC for ; Thu, 20 Oct 2022 12:39:27 +0000 (UTC) Received: from [2a02:8108:963f:de38:eca4:7d19:f9a2:22c5]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1olUpM-0004m0-0r; Thu, 20 Oct 2022 14:39:12 +0200 Message-ID: <9c06c75d-5079-dd27-6533-c053c986083e@leemhuis.info> Date: Thu, 20 Oct 2022 14:39:09 +0200 Precedence: bulk X-Mailing-List: regressions@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-US, de-DE To: Yicong Yang , Ard Biesheuvel , linux-efi@vger.kernel.org Cc: yangyicong@hisilicon.com, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, probinson@gmail.com, andersson@kernel.org, catalin.marinas@arm.com, will@kernel.org, Linuxarm , "regressions@lists.linux.dev" References: <20220916101843.495879-1-ardb@kernel.org> <56877644-8173-d2ed-ed00-7973734a3698@huawei.com> From: Thorsten Leemhuis Subject: Re: [PATCH] efi/libstub: arm64: avoid SetVirtualAddressMap() when possible In-Reply-To: <56877644-8173-d2ed-ed00-7973734a3698@huawei.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1666269567;c6e6b065; X-HE-SMSGID: 1olUpM-0004m0-0r [TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.] Hi, this is your Linux kernel regression tracker. CCing the regression mailing list, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html On 19.10.22 05:24, Yicong Yang wrote: > > 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. Thanks for the report. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced d3549a938b73f203ef522562ae9f2d38aa43d234 #regzbot title efi/libstub: arm64: efi runtime services stopped working #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply -- ideally with also telling regzbot about it, as explained here: https://linux-regtracking.leemhuis.info/tracked-regression/ Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (the mail this one replies to), as explained for in the Linux kernel's documentation; above webpage explains why this is important for tracked regressions. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. > 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 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 1A52BC4332F for ; Thu, 20 Oct 2022 12:56:39 +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:Subject:From:References:Cc: To:MIME-Version:Date:Message-ID:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vrE0evlxwaEqsqdNu2cFmCJxIfswGMt6NZUpYUQmnAA=; b=wv8hF9P0OmKlx+ EY4snVhONM1KKS6yDClKgpA4cqCGONcd8Ej11t4+xV3BKJTErMu/dnyjjAgXUgAuAPnJ6Gch+0OhQ hi2WdbQnNuH5KmRO4NDNrYw5aJ3FtQQU3uXiEz/xk6ykd8RkJrkuajl2fSdfMtyoXsPVmqP+Vry78 rSAdZ+fP6nKpxLlCgIuNA6tb1hW6QOYgCGzlUcAjULVeX+sWHBk2tO/G53NfP0oGStN6Ntnh7Xz/C M7dey8Y8ugCTItfrNXRlfR4YILWKB1JCR4Q62/H7x04CP68zHT+ubaRTlcLOW3NzbtuRMrleiOiUa Q+2WLr037aS3oqzXNCVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1olV4u-00F6WH-ES; Thu, 20 Oct 2022 12:55:17 +0000 Received: from wp530.webpack.hosteurope.de ([80.237.130.52]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1olUpb-00EtWo-G3 for linux-arm-kernel@lists.infradead.org; Thu, 20 Oct 2022 12:39:30 +0000 Received: from [2a02:8108:963f:de38:eca4:7d19:f9a2:22c5]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1olUpM-0004m0-0r; Thu, 20 Oct 2022 14:39:12 +0200 Message-ID: <9c06c75d-5079-dd27-6533-c053c986083e@leemhuis.info> Date: Thu, 20 Oct 2022 14:39:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Content-Language: en-US, de-DE To: Yicong Yang , Ard Biesheuvel , linux-efi@vger.kernel.org Cc: yangyicong@hisilicon.com, linux-arm-kernel@lists.infradead.org, mark.rutland@arm.com, probinson@gmail.com, andersson@kernel.org, catalin.marinas@arm.com, will@kernel.org, Linuxarm , "regressions@lists.linux.dev" References: <20220916101843.495879-1-ardb@kernel.org> <56877644-8173-d2ed-ed00-7973734a3698@huawei.com> From: Thorsten Leemhuis Subject: Re: [PATCH] efi/libstub: arm64: avoid SetVirtualAddressMap() when possible In-Reply-To: <56877644-8173-d2ed-ed00-7973734a3698@huawei.com> X-bounce-key: webpack.hosteurope.de;regressions@leemhuis.info;1666269567;c6e6b065; X-HE-SMSGID: 1olUpM-0004m0-0r X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221020_053927_789205_3B555507 X-CRM114-Status: GOOD ( 30.25 ) 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 [TLDR: I'm adding this regression report to the list of tracked regressions; all text from me you find below is based on a few templates paragraphs you might have encountered already already in similar form.] Hi, this is your Linux kernel regression tracker. CCing the regression mailing list, as it should be in the loop for all regressions, as explained here: https://www.kernel.org/doc/html/latest/admin-guide/reporting-issues.html On 19.10.22 05:24, Yicong Yang wrote: > > 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. Thanks for the report. To be sure below issue doesn't fall through the cracks unnoticed, I'm adding it to regzbot, my Linux kernel regression tracking bot: #regzbot ^introduced d3549a938b73f203ef522562ae9f2d38aa43d234 #regzbot title efi/libstub: arm64: efi runtime services stopped working #regzbot ignore-activity This isn't a regression? This issue or a fix for it are already discussed somewhere else? It was fixed already? You want to clarify when the regression started to happen? Or point out I got the title or something else totally wrong? Then just reply -- ideally with also telling regzbot about it, as explained here: https://linux-regtracking.leemhuis.info/tracked-regression/ Reminder for developers: When fixing the issue, add 'Link:' tags pointing to the report (the mail this one replies to), as explained for in the Linux kernel's documentation; above webpage explains why this is important for tracked regressions. Ciao, Thorsten (wearing his 'the Linux kernel's regression tracker' hat) P.S.: As the Linux kernel's regression tracker I deal with a lot of reports and sometimes miss something important when writing mails like this. If that's the case here, don't hesitate to tell me in a public reply, it's in everyone's interest to set the public record straight. > 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 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel