Message ID | 20230525094914.23420-1-ltao@redhat.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp241869vqr; Thu, 25 May 2023 02:59:02 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5a0pqAmGNOUnWNmvuzG7gnKMTvtQllLUcF5qIYuSI9yAHbBR9irL1spQb9DAMrlsZjNcZV X-Received: by 2002:a17:902:b787:b0:1af:a2a4:8379 with SMTP id e7-20020a170902b78700b001afa2a48379mr1070623pls.17.1685008742690; Thu, 25 May 2023 02:59:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685008742; cv=none; d=google.com; s=arc-20160816; b=JFz2nEfmnASooSyeXnSoM2I4x/kE8oBgSQ5AnyJPsTk876PMzq25QXWt/Nf1TqOIIG fpCtSLq0RGlCGNJHxEv5YxGzKCI/qhd80LBEco8YVO4+4yw8qyk7bfpYYePNe+wpkbLT y2Ope+4E1zTo7LmjZpOPLsd9+qlsHz4qDCuECCS9VKaLavZtAT6xS5InNFryBNRDg/zs QEsmc41CNmkM8NDSC2bn9Vv6sZLDt4gs45B+/i6bRtNBqq+IIE1bJBeswATlwGLVdQBI i41yFKfCjviLfNSy6UCxvIUP9neHLIMangQvRWSmbaKQIZOEGsE1YWAQfPFvy0Yyy7LT xm+A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=hAxjra5W1+1SvpBMN22QXJJOi5JB+teXZgPwJvUgVGE=; b=tD8CjAb3dD6cD3fapN2WfDBypnUbX5HxNKCm4grb5tOf0fDYKw89ooNS3q0LJwlH68 dFPPa02OHQjubVdI2/jX6O0kV1G74zuCtjA756/naroXyoRjmWqTMNN0RZj0LQWZGtfn Ph7QE2PtgOIuQyUKlj2v1xG7VLDZekDMExb9ISLKOnsft1PXzvnCE3YggSOQfH+76h+y JAfjq+9kI/X6oxVg85OMbslmh0JK77+O7NHfrR9cs00OreqHDd6fzzCz3CxRMr3CcLxZ dKKDKl4lAodYw1fx3MIl1PiJP61df1DpHo4m3EE+vB5H+SAhEk2sZ3h0VrbduF0mxRuT L/6Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H5eCmI5Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h24-20020a170902ac9800b0019a71e14c19si1058503plr.320.2023.05.25.02.58.49; Thu, 25 May 2023 02:59:02 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=H5eCmI5Z; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232749AbjEYJu3 (ORCPT <rfc822;ahmedalshaiji.dev@gmail.com> + 99 others); Thu, 25 May 2023 05:50:29 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240261AbjEYJu0 (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 25 May 2023 05:50:26 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC24B191 for <linux-kernel@vger.kernel.org>; Thu, 25 May 2023 02:49:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1685008180; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=hAxjra5W1+1SvpBMN22QXJJOi5JB+teXZgPwJvUgVGE=; b=H5eCmI5ZjssqzzZPef2G9MeMirWeBvpgB42ph90+wq0JHNlgkrjIjNlJsOZTFfu7ONWP+M Q0aWm1eL9R9jB9KmuIf31QQq6/gw6wZ9LZHCoVsiaQBa0ta2GjzDVc3QO4bgsMfF103OMs D+eFVc/DBLhWApjVmJN9V/pIG2E5tgw= Received: from mail-pg1-f200.google.com (mail-pg1-f200.google.com [209.85.215.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-44-FIiChdNTPFimlaeJDlZfEQ-1; Thu, 25 May 2023 05:49:38 -0400 X-MC-Unique: FIiChdNTPFimlaeJDlZfEQ-1 Received: by mail-pg1-f200.google.com with SMTP id 41be03b00d2f7-53425d37f33so902381a12.3 for <linux-kernel@vger.kernel.org>; Thu, 25 May 2023 02:49:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685008177; x=1687600177; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hAxjra5W1+1SvpBMN22QXJJOi5JB+teXZgPwJvUgVGE=; b=DBtByHAon5EpSh1gm8P3J+SGoHiCHyLM7g5Za4T4EKbXQQTH9inFKr0TXA18gxwQ6y NnxBCt66lLfuMyJZhOtF+UcEmLTHMPR/3rue6Fiw7Lbv8uT5WtWeS++avJJtK5oW1Sb/ caaTFp1CE2oUStYBlP5M6QR0DoAjyQfWoxKHOnFZc0k/jclGDH/nHA3ngAFX6+dmZ8fu mI7ueoWqOXvOdwwDYXCmmHsPp/Cu8gafSzcf1imYPC0SYSU7Zbg4V6NxOSD+nXYK5qgY b2ojpWJzbC6DrnCgQ9UEH7Lz+CsbUu0OaAcprOFglYH9HqtwBpUZXAUvfOIac6Ccv9Yi WoBQ== X-Gm-Message-State: AC+VfDwVApH1RZKLNk/g34cpYMEd+VyP1bNoQFxSi1GI2/MBAuDwB6Bj rdUkGdG/+UItmx3qWbh+9xqzh80zENZlkrzIa/SMyZRaViNMWAKi4BTrjqPd2PS6AKYX7zQLO7s J2ARKigdy7Nf0kL8LkuLQcmGR X-Received: by 2002:a17:903:230f:b0:1af:a03:8d82 with SMTP id d15-20020a170903230f00b001af0a038d82mr1149855plh.57.1685008177412; Thu, 25 May 2023 02:49:37 -0700 (PDT) X-Received: by 2002:a17:903:230f:b0:1af:a03:8d82 with SMTP id d15-20020a170903230f00b001af0a038d82mr1149833plh.57.1685008177110; Thu, 25 May 2023 02:49:37 -0700 (PDT) Received: from localhost.localdomain.com ([209.132.188.80]) by smtp.gmail.com with ESMTPSA id c10-20020a170903234a00b001ab2b4105ddsm1008282plh.60.2023.05.25.02.49.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 25 May 2023 02:49:36 -0700 (PDT) From: Tao Liu <ltao@redhat.com> To: tglx@linutronix.de, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com Cc: linux-kernel@vger.kernel.org, bhe@redhat.com, dyoung@redhat.com, kexec@lists.infradead.org, linux-efi@vger.kernel.org, Tao Liu <ltao@redhat.com> Subject: [PATCH] x86/kexec: Add EFI config table identity mapping for kexec kernel Date: Thu, 25 May 2023 17:49:14 +0800 Message-Id: <20230525094914.23420-1-ltao@redhat.com> X-Mailer: git-send-email 2.33.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1766859727556070783?= X-GMAIL-MSGID: =?utf-8?q?1766859727556070783?= |
Series |
x86/kexec: Add EFI config table identity mapping for kexec kernel
|
|
Commit Message
Tao Liu
May 25, 2023, 9:49 a.m. UTC
A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped
EFI config table.
Currently EFI system table is identity-mapped for the kexec kernel, but EFI
config table is not mapped explicitly:
commit 6bbeb276b71f ("x86/kexec: Add the EFI system tables and ACPI
tables to the ident map")
Later in the following 2 commits, EFI config table will be accessed when
enabling sev at kernel startup. This may result in a page fault due to EFI
config table's unmapped address. Since the page fault occurs at an early
stage, it is unrecoverable and kernel hangs.
commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features
earlier during boot")
commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature
detection/setup")
In addition, the issue doesn't appear on all systems, because the kexec
kernel uses Page Size Extension (PSE) for identity mapping. In most cases,
EFI config table can end up to be mapped into due to 1 GB page size.
However if nogbpages is set, or cpu doesn't support pdpe1gb feature
(e.g Intel Atom x6425RE cpu), EFI config table may not be mapped into
due to 2 MB page size, thus a page fault hang is more likely to happen.
In this patch, we will make sure the EFI config table is always mapped.
Signed-off-by: Tao Liu <ltao@redhat.com>
---
arch/x86/kernel/machine_kexec_64.c | 35 ++++++++++++++++++++++++++----
1 file changed, 31 insertions(+), 4 deletions(-)
Comments
Hi Tao, On 05/25/23 at 05:49pm, Tao Liu wrote: > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped > EFI config table. > > Currently EFI system table is identity-mapped for the kexec kernel, but EFI > config table is not mapped explicitly: > > commit 6bbeb276b71f ("x86/kexec: Add the EFI system tables and ACPI > tables to the ident map") > > Later in the following 2 commits, EFI config table will be accessed when > enabling sev at kernel startup. This may result in a page fault due to EFI > config table's unmapped address. Since the page fault occurs at an early > stage, it is unrecoverable and kernel hangs. > > commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features > earlier during boot") > commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature > detection/setup") > > In addition, the issue doesn't appear on all systems, because the kexec > kernel uses Page Size Extension (PSE) for identity mapping. In most cases, > EFI config table can end up to be mapped into due to 1 GB page size. > However if nogbpages is set, or cpu doesn't support pdpe1gb feature > (e.g Intel Atom x6425RE cpu), EFI config table may not be mapped into > due to 2 MB page size, thus a page fault hang is more likely to happen. > > In this patch, we will make sure the EFI config table is always mapped. Nice work. While you may need to rephrase above sentence, x86 maintainers don't like log with the 'this patch,' or 'we'. Please refer to 'Changelog' part of Documentation/process/maintainer-tip.rst and improve it. > > Signed-off-by: Tao Liu <ltao@redhat.com> > --- > arch/x86/kernel/machine_kexec_64.c | 35 ++++++++++++++++++++++++++---- > 1 file changed, 31 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > index 1a3e2c05a8a5..755aa12f583f 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -28,6 +28,7 @@ > #include <asm/setup.h> > #include <asm/set_memory.h> > #include <asm/cpu.h> > +#include <asm/efi.h> > > #ifdef CONFIG_ACPI > /* > @@ -86,10 +87,12 @@ const struct kexec_file_ops * const kexec_file_loaders[] = { > #endif > > static int > -map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) > +map_efi_sys_cfg_tab(struct x86_mapping_info *info, pgd_t *level4p) Can we call the function map_efi_tables() since we will map efi system table, system config table. If you need add another table mapping here, what would you call it, map_efi_sys_cfg_xxx_tab()? Anyway, not very strong opinion as long as x86 maintainer likes it. > { > #ifdef CONFIG_EFI > unsigned long mstart, mend; > + void *kaddr; > + int ret; > > if (!efi_enabled(EFI_BOOT)) > return 0; > @@ -105,6 +108,30 @@ map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) > if (!mstart) > return 0; > > + ret = kernel_ident_mapping_init(info, level4p, mstart, mend); > + if (ret) > + return ret; > + > + kaddr = memremap(mstart, mend - mstart, MEMREMAP_WB); > + if (!kaddr) { > + pr_err("Could not map UEFI system table\n"); > + return -ENOMEM; > + } > + > + mstart = efi_config_table; > + > + if (efi_enabled(EFI_64BIT)) { > + efi_system_table_64_t *stbl = (efi_system_table_64_t *)kaddr; > + > + mend = mstart + sizeof(efi_config_table_64_t) * stbl->nr_tables; > + } else { > + efi_system_table_32_t *stbl = (efi_system_table_32_t *)kaddr; > + > + mend = mstart + sizeof(efi_config_table_32_t) * stbl->nr_tables; > + } > + > + memunmap(kaddr); > + > return kernel_ident_mapping_init(info, level4p, mstart, mend); > #endif > return 0; > @@ -244,10 +271,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) > } > > /* > - * Prepare EFI systab and ACPI tables for kexec kernel since they are > - * not covered by pfn_mapped. > + * Prepare EFI systab, config table and ACPI tables for kexec kernel > + * since they are not covered by pfn_mapped. > */ > - result = map_efi_systab(&info, level4p); > + result = map_efi_sys_cfg_tab(&info, level4p); > if (result) > return result; > > -- > 2.33.1 >
Add Ard to CC. On 05/25/23 at 05:49pm, Tao Liu wrote: > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped > EFI config table. > > Currently EFI system table is identity-mapped for the kexec kernel, but EFI > config table is not mapped explicitly: > > commit 6bbeb276b71f ("x86/kexec: Add the EFI system tables and ACPI > tables to the ident map") > > Later in the following 2 commits, EFI config table will be accessed when > enabling sev at kernel startup. This may result in a page fault due to EFI > config table's unmapped address. Since the page fault occurs at an early > stage, it is unrecoverable and kernel hangs. > > commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features > earlier during boot") > commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature > detection/setup") > > In addition, the issue doesn't appear on all systems, because the kexec > kernel uses Page Size Extension (PSE) for identity mapping. In most cases, > EFI config table can end up to be mapped into due to 1 GB page size. > However if nogbpages is set, or cpu doesn't support pdpe1gb feature > (e.g Intel Atom x6425RE cpu), EFI config table may not be mapped into > due to 2 MB page size, thus a page fault hang is more likely to happen. > > In this patch, we will make sure the EFI config table is always mapped. > > Signed-off-by: Tao Liu <ltao@redhat.com> > --- > arch/x86/kernel/machine_kexec_64.c | 35 ++++++++++++++++++++++++++---- > 1 file changed, 31 insertions(+), 4 deletions(-) > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > index 1a3e2c05a8a5..755aa12f583f 100644 > --- a/arch/x86/kernel/machine_kexec_64.c > +++ b/arch/x86/kernel/machine_kexec_64.c > @@ -28,6 +28,7 @@ > #include <asm/setup.h> > #include <asm/set_memory.h> > #include <asm/cpu.h> > +#include <asm/efi.h> > > #ifdef CONFIG_ACPI > /* > @@ -86,10 +87,12 @@ const struct kexec_file_ops * const kexec_file_loaders[] = { > #endif > > static int > -map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) > +map_efi_sys_cfg_tab(struct x86_mapping_info *info, pgd_t *level4p) > { > #ifdef CONFIG_EFI > unsigned long mstart, mend; > + void *kaddr; > + int ret; > > if (!efi_enabled(EFI_BOOT)) > return 0; > @@ -105,6 +108,30 @@ map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) > if (!mstart) > return 0; > > + ret = kernel_ident_mapping_init(info, level4p, mstart, mend); > + if (ret) > + return ret; > + > + kaddr = memremap(mstart, mend - mstart, MEMREMAP_WB); > + if (!kaddr) { > + pr_err("Could not map UEFI system table\n"); > + return -ENOMEM; > + } > + > + mstart = efi_config_table; > + > + if (efi_enabled(EFI_64BIT)) { > + efi_system_table_64_t *stbl = (efi_system_table_64_t *)kaddr; > + > + mend = mstart + sizeof(efi_config_table_64_t) * stbl->nr_tables; > + } else { > + efi_system_table_32_t *stbl = (efi_system_table_32_t *)kaddr; > + > + mend = mstart + sizeof(efi_config_table_32_t) * stbl->nr_tables; > + } > + > + memunmap(kaddr); > + > return kernel_ident_mapping_init(info, level4p, mstart, mend); > #endif > return 0; > @@ -244,10 +271,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) > } > > /* > - * Prepare EFI systab and ACPI tables for kexec kernel since they are > - * not covered by pfn_mapped. > + * Prepare EFI systab, config table and ACPI tables for kexec kernel > + * since they are not covered by pfn_mapped. > */ > - result = map_efi_systab(&info, level4p); > + result = map_efi_sys_cfg_tab(&info, level4p); > if (result) > return result; > > -- > 2.33.1 >
Hi Baoquan, On Fri, May 26, 2023 at 12:08 PM Baoquan He <bhe@redhat.com> wrote: > > Hi Tao, > > On 05/25/23 at 05:49pm, Tao Liu wrote: > > A kexec kernel bootup hang is observed on Intel Atom cpu due to unmapped > > EFI config table. > > > > Currently EFI system table is identity-mapped for the kexec kernel, but EFI > > config table is not mapped explicitly: > > > > commit 6bbeb276b71f ("x86/kexec: Add the EFI system tables and ACPI > > tables to the ident map") > > > > Later in the following 2 commits, EFI config table will be accessed when > > enabling sev at kernel startup. This may result in a page fault due to EFI > > config table's unmapped address. Since the page fault occurs at an early > > stage, it is unrecoverable and kernel hangs. > > > > commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features > > earlier during boot") > > commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature > > detection/setup") > > > > In addition, the issue doesn't appear on all systems, because the kexec > > kernel uses Page Size Extension (PSE) for identity mapping. In most cases, > > EFI config table can end up to be mapped into due to 1 GB page size. > > However if nogbpages is set, or cpu doesn't support pdpe1gb feature > > (e.g Intel Atom x6425RE cpu), EFI config table may not be mapped into > > due to 2 MB page size, thus a page fault hang is more likely to happen. > > > > In this patch, we will make sure the EFI config table is always mapped. > > Nice work. While you may need to rephrase above sentence, x86 > maintainers don't like log with the 'this patch,' or 'we'. Please refer > to 'Changelog' part of Documentation/process/maintainer-tip.rst and > improve it. OK, Thanks for the suggestion! I will get the sentence rephrased in v2. > > > > > Signed-off-by: Tao Liu <ltao@redhat.com> > > --- > > arch/x86/kernel/machine_kexec_64.c | 35 ++++++++++++++++++++++++++---- > > 1 file changed, 31 insertions(+), 4 deletions(-) > > > > diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c > > index 1a3e2c05a8a5..755aa12f583f 100644 > > --- a/arch/x86/kernel/machine_kexec_64.c > > +++ b/arch/x86/kernel/machine_kexec_64.c > > @@ -28,6 +28,7 @@ > > #include <asm/setup.h> > > #include <asm/set_memory.h> > > #include <asm/cpu.h> > > +#include <asm/efi.h> > > > > #ifdef CONFIG_ACPI > > /* > > @@ -86,10 +87,12 @@ const struct kexec_file_ops * const kexec_file_loaders[] = { > > #endif > > > > static int > > -map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) > > +map_efi_sys_cfg_tab(struct x86_mapping_info *info, pgd_t *level4p) > > Can we call the function map_efi_tables() since we will map efi system > table, system config table. If you need add another table mapping here, > what would you call it, map_efi_sys_cfg_xxx_tab()? > Yeah, map_efi_sys_cfg_xxx_tab() is surely a bad name. I agree with the map_efi_tables() name. Thanks, Tao Liu > Anyway, not very strong opinion as long as x86 maintainer likes it. > > > { > > #ifdef CONFIG_EFI > > unsigned long mstart, mend; > > + void *kaddr; > > + int ret; > > > > if (!efi_enabled(EFI_BOOT)) > > return 0; > > @@ -105,6 +108,30 @@ map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) > > if (!mstart) > > return 0; > > > > + ret = kernel_ident_mapping_init(info, level4p, mstart, mend); > > + if (ret) > > + return ret; > > + > > + kaddr = memremap(mstart, mend - mstart, MEMREMAP_WB); > > + if (!kaddr) { > > + pr_err("Could not map UEFI system table\n"); > > + return -ENOMEM; > > + } > > + > > + mstart = efi_config_table; > > + > > + if (efi_enabled(EFI_64BIT)) { > > + efi_system_table_64_t *stbl = (efi_system_table_64_t *)kaddr; > > + > > + mend = mstart + sizeof(efi_config_table_64_t) * stbl->nr_tables; > > + } else { > > + efi_system_table_32_t *stbl = (efi_system_table_32_t *)kaddr; > > + > > + mend = mstart + sizeof(efi_config_table_32_t) * stbl->nr_tables; > > + } > > + > > + memunmap(kaddr); > > + > > return kernel_ident_mapping_init(info, level4p, mstart, mend); > > #endif > > return 0; > > @@ -244,10 +271,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) > > } > > > > /* > > - * Prepare EFI systab and ACPI tables for kexec kernel since they are > > - * not covered by pfn_mapped. > > + * Prepare EFI systab, config table and ACPI tables for kexec kernel > > + * since they are not covered by pfn_mapped. > > */ > > - result = map_efi_systab(&info, level4p); > > + result = map_efi_sys_cfg_tab(&info, level4p); > > if (result) > > return result; > > > > -- > > 2.33.1 > > >
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c index 1a3e2c05a8a5..755aa12f583f 100644 --- a/arch/x86/kernel/machine_kexec_64.c +++ b/arch/x86/kernel/machine_kexec_64.c @@ -28,6 +28,7 @@ #include <asm/setup.h> #include <asm/set_memory.h> #include <asm/cpu.h> +#include <asm/efi.h> #ifdef CONFIG_ACPI /* @@ -86,10 +87,12 @@ const struct kexec_file_ops * const kexec_file_loaders[] = { #endif static int -map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) +map_efi_sys_cfg_tab(struct x86_mapping_info *info, pgd_t *level4p) { #ifdef CONFIG_EFI unsigned long mstart, mend; + void *kaddr; + int ret; if (!efi_enabled(EFI_BOOT)) return 0; @@ -105,6 +108,30 @@ map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p) if (!mstart) return 0; + ret = kernel_ident_mapping_init(info, level4p, mstart, mend); + if (ret) + return ret; + + kaddr = memremap(mstart, mend - mstart, MEMREMAP_WB); + if (!kaddr) { + pr_err("Could not map UEFI system table\n"); + return -ENOMEM; + } + + mstart = efi_config_table; + + if (efi_enabled(EFI_64BIT)) { + efi_system_table_64_t *stbl = (efi_system_table_64_t *)kaddr; + + mend = mstart + sizeof(efi_config_table_64_t) * stbl->nr_tables; + } else { + efi_system_table_32_t *stbl = (efi_system_table_32_t *)kaddr; + + mend = mstart + sizeof(efi_config_table_32_t) * stbl->nr_tables; + } + + memunmap(kaddr); + return kernel_ident_mapping_init(info, level4p, mstart, mend); #endif return 0; @@ -244,10 +271,10 @@ static int init_pgtable(struct kimage *image, unsigned long start_pgtable) } /* - * Prepare EFI systab and ACPI tables for kexec kernel since they are - * not covered by pfn_mapped. + * Prepare EFI systab, config table and ACPI tables for kexec kernel + * since they are not covered by pfn_mapped. */ - result = map_efi_systab(&info, level4p); + result = map_efi_sys_cfg_tab(&info, level4p); if (result) return result;