From nobody Fri May 9 07:35:10 2025
Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com
[148.163.143.35])
(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 3A4CDE552
for <linux-kernel@vger.kernel.org>; Mon, 20 May 2024 19:09:47 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=148.163.143.35
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1716232191; cv=none;
b=o2ERzdjHYQnCylCufFz3FwfhAxLYrwKn3DBaiYENQK+CZfnoN0ZrkWQHStUQDKdMLnibplNvLBsE96ONI0OUJ+wU44DVeP08e2y7n3BbG/ETZyxaGpp7d8W1Y+qTmASchIEHtiKRiZ0B2OKw7J23ZeCppw54xyuPHOe6fihA/VA=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1716232191; c=relaxed/simple;
bh=RFucRZVB2b79ftg7v7SXtwcVJIdleSVk5br/SotgogM=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version;
b=qKUZ80KGDKFQtPwC772N8Wy9TzdZQTlXEEg9OzVb8f80X2tETXnAsfc3SxiLWJxBwqqx2c0yi3jzU3V31H0o2nTyPrhGED3rkFgDFvJLKoiqj1xR/9VN3ozlou3lzP+wQHOfyAkssdOZStgn32IEKzEun6sK+vRmqwpAejYCWyY=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=hpe.com;
spf=pass smtp.mailfrom=hpe.com;
dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com
header.b=H/XQlQ8U; arc=none smtp.client-ip=148.163.143.35
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=hpe.com
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=hpe.com
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com
header.b="H/XQlQ8U"
Received: from pps.filterd (m0148664.ppops.net [127.0.0.1])
by mx0b-002e3701.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id
44KBhg8x032700;
Mon, 20 May 2024 18:36:41 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com;
h=from : to : cc : subject
: date : message-id : in-reply-to : references : mime-version :
content-transfer-encoding; s=pps0720;
bh=zoS0sr6JM2PIVecEiJNHlY75llQlYfv3A2SsNH8FUVI=;
b=H/XQlQ8UHvkY02FYQa5o0LvmvnyO9VSTOQfZAOs897DZki8HOjr5G5EioEw/SyUecJYr
tMJbCRC6Mby9J8Q1vSCR8/s4M4ODR6xG/HWoC7JIIPkuciQ0t772Yp6M1rtnaQch0a39
3HOH+WzWvVor3icaFXPhH5mQEbQx4Fq4GmfOdgaUpqOxHXWI1zhDohgc2Sb+RXAIs+Zm
cxlrlFnUvL2G6bNYWglfIP0r0my4L6/VG/FllVNpN66XwhUvlcq3eUYzsab7iqEFDNj8
3hzET2ZE+5n8nPkfRPsQbAPHLllzGqnn/G4O2iIv+W+l0u/pV8thUMDcAwGUIx+HgFd1 eQ==
Received: from p1lg14881.it.hpe.com ([16.230.97.202])
by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 3y85vx3bce-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Mon, 20 May 2024 18:36:41 +0000
Received: from p1lg14886.dc01.its.hpecorp.net (unknown [10.119.18.237])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
SHA256)
(No client certificate requested)
by p1lg14881.it.hpe.com (Postfix) with ESMTPS id 87016805EB5;
Mon, 20 May 2024 18:36:39 +0000 (UTC)
Received: from dog.eag.rdlabs.hpecorp.net (unknown [16.231.227.39])
by p1lg14886.dc01.its.hpecorp.net (Postfix) with ESMTP id 6B0CB80E710;
Mon, 20 May 2024 18:36:37 +0000 (UTC)
Received: by dog.eag.rdlabs.hpecorp.net (Postfix, from userid 200934)
id AD446300009B5; Mon, 20 May 2024 13:36:33 -0500 (CDT)
From: Steve Wahl <steve.wahl@hpe.com>
To: Steve Wahl <steve.wahl@hpe.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>, x86@kernel.org,
"H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org,
Pavin Joseph <me@pavinjoseph.com>, Eric Hagberg <ehagberg@gmail.com>
Cc: Simon Horman <horms@verge.net.au>, Eric Biederman <ebiederm@xmission.com>,
Dave Young <dyoung@redhat.com>, Sarah Brofeldt <srhb@dbc.dk>,
Russ Anderson <rja@hpe.com>, Dimitri Sivanich <sivanich@hpe.com>,
Hou Wenlong <houwenlong.hwl@antgroup.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>,
Yuntao Wang <ytcoode@gmail.com>, Bjorn Helgaas <bhelgaas@google.com>,
Joerg Roedel <jroedel@suse.de>, Michael Roth <michael.roth@amd.com>
Subject: [PATCH 1/3] x86/kexec: Add EFI config table identity mapping for
kexec kernel
Date: Mon, 20 May 2024 13:36:31 -0500
Message-Id: <20240520183633.1457687-2-steve.wahl@hpe.com>
X-Mailer: git-send-email 2.26.2
In-Reply-To: <20240520183633.1457687-1-steve.wahl@hpe.com>
References: <20240520183633.1457687-1-steve.wahl@hpe.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-GUID: 3Y20lcDBObhdOi5eJeK6zNtXUHZ6EvQ1
X-Proofpoint-ORIG-GUID: 3Y20lcDBObhdOi5eJeK6zNtXUHZ6EvQ1
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16
definitions=2024-05-20_09,2024-05-17_03,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
clxscore=1015 impostorscore=0
malwarescore=0 adultscore=0 suspectscore=0 mlxscore=0 bulkscore=0
spamscore=0 mlxlogscore=999 priorityscore=1501 phishscore=0
lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.12.0-2405010000 definitions=main-2405200149
Content-Type: text/plain; charset="utf-8"
From: Tao Liu <ltao@redhat.com>
A kexec kernel boot failure is sometimes observed on AMD CPUs due to
unmapped EFI config table. This is seen when "nogbpages" is on the
kernel command line, and has been observed as a full BIOS reboot
rather than a successful kexec.
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")
The following 2 commits caused the EFI config table to be accessed
when enabling SEV at kernel startup.
commit ec1c66af3a30 ("x86/compressed/64: Detect/setup SEV/SME features
earlier during boot")
commit c01fce9cef84 ("x86/compressed: Add SEV-SNP feature
detection/setup")
This may result in a page fault due to EFI config table's unmapped
address. Since the page fault occurs before the new kernel establishes
its own identity map and page fault routines, it is unrecoverable and
kexec fails.
The issue doesn't appear on all systems, because the pages used by
kexec to create the identity map are usually large 1GB pages that, by
luck, end up including the needed address space when other nearby
areas are explicitly mapped.
However if nogbpages is set, the reduced page size (2 MB) used to
create the identity map means it's less likely that the EFI config
table's address space ends up mapped by mapping requests for nearby
areas.
Therefore, explicitly include the EFI config table in the kexec
identity map.
Signed-off-by: Tao Liu <ltao@redhat.com>
Tested-by: Pavin Joseph <me@pavinjoseph.com>
Tested-by: Sarah Brofeldt <srhb@dbc.dk>
Tested-by: Eric Hagberg <ehagberg@gmail.com>
---
arch/x86/kernel/machine_kexec_64.c | 35 ++++++++++++++++++++++++++----
1 file changed, 31 insertions(+), 4 deletions(-)
I (Steve Wahl) modified the above commit message, but did not modify
the code. I am not clear if that requires additional Co-developed-by:
and Signed-off-by: lines. If so, copy them from here:
Co-developed-by: Steve Wahl <steve.wahl@hpe.com>
Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_k=
exec_64.c
index b180d8e497c3..d89942307659 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>
=20
#ifdef CONFIG_ACPI
/*
@@ -83,10 +84,12 @@ const struct kexec_file_ops * const kexec_file_loaders[=
] =3D {
#endif
=20
static int
-map_efi_systab(struct x86_mapping_info *info, pgd_t *level4p)
+map_efi_tables(struct x86_mapping_info *info, pgd_t *level4p)
{
#ifdef CONFIG_EFI
unsigned long mstart, mend;
+ void *kaddr;
+ int ret;
=20
if (!efi_enabled(EFI_BOOT))
return 0;
@@ -102,6 +105,30 @@ map_efi_systab(struct x86_mapping_info *info, pgd_t *l=
evel4p)
if (!mstart)
return 0;
=20
+ ret =3D kernel_ident_mapping_init(info, level4p, mstart, mend);
+ if (ret)
+ return ret;
+
+ kaddr =3D memremap(mstart, mend - mstart, MEMREMAP_WB);
+ if (!kaddr) {
+ pr_err("Could not map UEFI system table\n");
+ return -ENOMEM;
+ }
+
+ mstart =3D efi_config_table;
+
+ if (efi_enabled(EFI_64BIT)) {
+ efi_system_table_64_t *stbl =3D (efi_system_table_64_t *)kaddr;
+
+ mend =3D mstart + sizeof(efi_config_table_64_t) * stbl->nr_tables;
+ } else {
+ efi_system_table_32_t *stbl =3D (efi_system_table_32_t *)kaddr;
+
+ mend =3D mstart + sizeof(efi_config_table_32_t) * stbl->nr_tables;
+ }
+
+ memunmap(kaddr);
+
return kernel_ident_mapping_init(info, level4p, mstart, mend);
#endif
return 0;
@@ -241,10 +268,10 @@ static int init_pgtable(struct kimage *image, unsigne=
d long start_pgtable)
}
=20
/*
- * 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 =3D map_efi_systab(&info, level4p);
+ result =3D map_efi_tables(&info, level4p);
if (result)
return result;
=20
--=20
2.26.2
From nobody Fri May 9 07:35:10 2025
Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com
[148.163.143.35])
(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 0946AE552
for <linux-kernel@vger.kernel.org>; Mon, 20 May 2024 19:13:35 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=148.163.143.35
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1716232417; cv=none;
b=UHos+OdNDoAVJlHh/Gfolk1t0TaioB0na1SajxQiThcMlUnnWbJ4oJp1TsSsAO3SlWhxJ0Z1hVZ3eOHzzTGJ7J3cPxDxhauvTYxA39TTTs7DhEQKTHephVaarZnSlZBKdiTa2VZnLZ1+LHOrsgEB9uIYgpGhleiIIgDo/TqS1/Y=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1716232417; c=relaxed/simple;
bh=BAeLUJ3nqsO8dJX0BxxVNPUiiLjJK0aAAQw4lrODvI8=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version;
b=DOPnraIGRRR00sQ0mk9LWUSNrvwQzBROPt9BeHlUbauvAQFGhkW0E8ZbGnsQxbxbi4/uhP3ZusG5r0KG/UwJGu7Iza2cdqUBEa29sgQDP7XESx5TMBAtu+h/lZpKEwaJWYEvbKacVZac4cp9ps2W23vsU6QId47mvIZYjTaY3NY=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=hpe.com;
spf=pass smtp.mailfrom=hpe.com;
dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com
header.b=NB2nmjEI; arc=none smtp.client-ip=148.163.143.35
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=hpe.com
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=hpe.com
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com
header.b="NB2nmjEI"
Received: from pps.filterd (m0134424.ppops.net [127.0.0.1])
by mx0b-002e3701.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id
44KISQSj009531;
Mon, 20 May 2024 18:36:41 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com;
h=from : to : cc : subject
: date : message-id : in-reply-to : references : mime-version :
content-transfer-encoding; s=pps0720;
bh=gAeKZTtAY9OBlRuNw6pwsX4ALpDGRNYLZRYeGk5XNeI=;
b=NB2nmjEIeK2oi4Me2MgeATfD3JcZ5YEE4vZIQyN1PUYr4I/aQ150iu3X6FMWuyBN1inr
DW9SgIOG5YDL7pvFtbRkzwXpuRj8UV/0+68XjhsQESjcssTlPxE7nvDBv4wpCvnYamvW
3e+saFHWKZzQ5o1IZstwBqHi/mymac2wZZo83mz+j1NjBM209MJJjfw6Do2qZhHrpEpZ
/QK2uPr0w1EoYq0xo9sTOYJiko0o9xv8iNvN+53aZ9Mytc016gv0Qlvv2Vxd9EQ52bRK
hI1BxxC97OrsRDZsBVE/QqjfP4SA0ZXEBqafAJy1KDlvwd+04ZDg/czhi8miuLFC4BIh rg==
Received: from p1lg14880.it.hpe.com ([16.230.97.201])
by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 3y8btrg23c-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Mon, 20 May 2024 18:36:41 +0000
Received: from p1lg14885.dc01.its.hpecorp.net (unknown [10.119.18.236])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
SHA256)
(No client certificate requested)
by p1lg14880.it.hpe.com (Postfix) with ESMTPS id 7B5A08005D2;
Mon, 20 May 2024 18:36:39 +0000 (UTC)
Received: from dog.eag.rdlabs.hpecorp.net (unknown [16.231.227.39])
by p1lg14885.dc01.its.hpecorp.net (Postfix) with ESMTP id 6AFAC80502B;
Mon, 20 May 2024 18:36:37 +0000 (UTC)
Received: by dog.eag.rdlabs.hpecorp.net (Postfix, from userid 200934)
id AE9F130000BA2; Mon, 20 May 2024 13:36:33 -0500 (CDT)
From: Steve Wahl <steve.wahl@hpe.com>
To: Steve Wahl <steve.wahl@hpe.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>, x86@kernel.org,
"H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org,
Pavin Joseph <me@pavinjoseph.com>, Eric Hagberg <ehagberg@gmail.com>
Cc: Simon Horman <horms@verge.net.au>, Eric Biederman <ebiederm@xmission.com>,
Dave Young <dyoung@redhat.com>, Sarah Brofeldt <srhb@dbc.dk>,
Russ Anderson <rja@hpe.com>, Dimitri Sivanich <sivanich@hpe.com>,
Hou Wenlong <houwenlong.hwl@antgroup.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>,
Yuntao Wang <ytcoode@gmail.com>, Bjorn Helgaas <bhelgaas@google.com>,
Joerg Roedel <jroedel@suse.de>, Michael Roth <michael.roth@amd.com>
Subject: [PATCH 2/3] x86/kexec: Add EFI Confidential Computing blob to kexec
identity mapping.
Date: Mon, 20 May 2024 13:36:32 -0500
Message-Id: <20240520183633.1457687-3-steve.wahl@hpe.com>
X-Mailer: git-send-email 2.26.2
In-Reply-To: <20240520183633.1457687-1-steve.wahl@hpe.com>
References: <20240520183633.1457687-1-steve.wahl@hpe.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-ORIG-GUID: aO2MSBNr8QnlwANVQUbhEPErA966XHQ9
X-Proofpoint-GUID: aO2MSBNr8QnlwANVQUbhEPErA966XHQ9
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16
definitions=2024-05-20_09,2024-05-17_03,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
mlxlogscore=999
malwarescore=0 priorityscore=1501 suspectscore=0 spamscore=0 mlxscore=0
phishscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 adultscore=0
clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.12.0-2405010000 definitions=main-2405200149
Content-Type: text/plain; charset="utf-8"
Like the EFI config table itself, the Confidential Computing blob entry
in that table, if it exists, is referenced by the kexec kernel before
it establishes its own identity map.
This could potentially cause a kexec failure if the CC blob is not
located close to other identity map areas. Such a failure is more
likely with the nogbpages command line option.
So, explicitly add the CC blob to the kexec identity map.
Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
Tested-by: Pavin Joseph <me@pavinjoseph.com>
Tested-by: Sarah Brofeldt <srhb@dbc.dk>
Tested-by: Eric Hagberg <ehagberg@gmail.com>
---
arch/x86/kernel/machine_kexec_64.c | 47 +++++++++++++++++++++++++++++-
1 file changed, 46 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_k=
exec_64.c
index d89942307659..bb68d86ecafe 100644
--- a/arch/x86/kernel/machine_kexec_64.c
+++ b/arch/x86/kernel/machine_kexec_64.c
@@ -29,6 +29,7 @@
#include <asm/set_memory.h>
#include <asm/cpu.h>
#include <asm/efi.h>
+#include <asm/sev.h>
=20
#ifdef CONFIG_ACPI
/*
@@ -90,6 +91,7 @@ map_efi_tables(struct x86_mapping_info *info, pgd_t *leve=
l4p)
unsigned long mstart, mend;
void *kaddr;
int ret;
+ unsigned int cfg_tbl_len;
=20
if (!efi_enabled(EFI_BOOT))
return 0;
@@ -120,16 +122,59 @@ map_efi_tables(struct x86_mapping_info *info, pgd_t *=
level4p)
if (efi_enabled(EFI_64BIT)) {
efi_system_table_64_t *stbl =3D (efi_system_table_64_t *)kaddr;
=20
+ cfg_tbl_len =3D stbl->nr_tables;
mend =3D mstart + sizeof(efi_config_table_64_t) * stbl->nr_tables;
} else {
efi_system_table_32_t *stbl =3D (efi_system_table_32_t *)kaddr;
=20
+ cfg_tbl_len =3D stbl->nr_tables;
mend =3D mstart + sizeof(efi_config_table_32_t) * stbl->nr_tables;
}
=20
memunmap(kaddr);
=20
- return kernel_ident_mapping_init(info, level4p, mstart, mend);
+ ret =3D kernel_ident_mapping_init(info, level4p, mstart, mend);
+ if (ret)
+ return ret;
+
+ /*
+ * CC blob is referenced in kernel startup before the new
+ * kernel creates it's own identity map, so make sure it's
+ * included in the kexec identity map.
+ */
+ kaddr =3D memremap(mstart, mend - mstart, MEMREMAP_WB);
+ if (!kaddr) {
+ pr_err("Could not map UEFI config table\n");
+ return -ENOMEM;
+ }
+
+ mstart =3D 0;
+ if (efi_enabled(EFI_64BIT)) {
+ efi_config_table_64_t *ctbl =3D (void *) kaddr;
+ int i;
+
+ for (i =3D 0; i < cfg_tbl_len; i++) {
+ if (!efi_guidcmp(EFI_CC_BLOB_GUID, ctbl[i].guid)) {
+ mstart =3D ctbl[i].table;
+ mend =3D mstart + sizeof(struct cc_blob_sev_info);
+ break;
+ }
+ }
+ } else {
+ efi_config_table_32_t *ctbl =3D (void *) kaddr;
+ int i;
+
+ for (i =3D 0; i < cfg_tbl_len; i++) {
+ if (!efi_guidcmp(EFI_CC_BLOB_GUID, ctbl[i].guid)) {
+ mstart =3D ctbl[i].table;
+ mend =3D mstart + sizeof(struct cc_blob_sev_info);
+ break;
+ }
+ }
+ }
+ memunmap(kaddr);
+ if (mstart)
+ return kernel_ident_mapping_init(info, level4p, mstart, mend);
#endif
return 0;
}
--=20
2.26.2
From nobody Fri May 9 07:35:10 2025
Received: from mx0b-002e3701.pphosted.com (mx0b-002e3701.pphosted.com
[148.163.143.35])
(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 6888FE552
for <linux-kernel@vger.kernel.org>; Mon, 20 May 2024 19:10:25 +0000 (UTC)
Authentication-Results: smtp.subspace.kernel.org;
arc=none smtp.client-ip=148.163.143.35
ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116;
t=1716232228; cv=none;
b=HGkPT+p9R+kEwmztWJTCmsJinIRGDR9D2Y5RRaCR77CQox1X3xjjpcIF7LlWExQGT919IMBXohVnEkbv1u7sWDSkPUJz6V/sL2c218lGlqT8Iw1ruCZ6n20boFDITD+T9Bz4HEhbq9XISzNruA9BHE52BnqMwU1V7ihpwEAILno=
ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org;
s=arc-20240116; t=1716232228; c=relaxed/simple;
bh=AMpZ/XE+XtDZfE0FuZLIM9BLqIRsVCI+b6KrxaoT1js=;
h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References:
MIME-Version;
b=kzFsEtfcUnb0hpyraRljw5RrXaZrVLGUT0CyGO6PwRiCkDkHWWXW4sE9rtpP0uvPJuNJRL8pjCJ1yJcxyVnEVQ4kL9aNjFKFrUJsb+F2mvMhiz+MO4aKnk6fxIeezRIIxteUk6AkciVIsfr+zmxVfjcCoaj5S9oC+wDyTe9BCiY=
ARC-Authentication-Results: i=1; smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=hpe.com;
spf=pass smtp.mailfrom=hpe.com;
dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com
header.b=GoJrVK0Y; arc=none smtp.client-ip=148.163.143.35
Authentication-Results: smtp.subspace.kernel.org;
dmarc=pass (p=none dis=none) header.from=hpe.com
Authentication-Results: smtp.subspace.kernel.org;
spf=pass smtp.mailfrom=hpe.com
Authentication-Results: smtp.subspace.kernel.org;
dkim=pass (2048-bit key) header.d=hpe.com header.i=@hpe.com
header.b="GoJrVK0Y"
Received: from pps.filterd (m0134425.ppops.net [127.0.0.1])
by mx0b-002e3701.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id
44KFWZME010874;
Mon, 20 May 2024 18:36:41 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hpe.com;
h=from : to : cc : subject
: date : message-id : in-reply-to : references : mime-version :
content-transfer-encoding; s=pps0720;
bh=5wnYJKVBAgZHtm4apI+o0UClri+N/eR13sz7FUVRYjw=;
b=GoJrVK0YAPbMJ++h0//zbHUPoyWODEUHcPq9LwYJRi8NoufXV5RRUUyR0YYDDIn9Lan7
B0Rp12H/84E6tuR+jrX8oirE0fj/esxTR4UU4zXmAxrI+zZnFSA+js2QUO7rjp8QuHL+
MA9Vo7e/08Mgcqh+jdxlHc7uWBbbeKKD/aSm9WWPWwYkKvG1PZeN8jhFdhOtMCJ8PdUP
N5G9ikkJzPjIMqn+tIPU5FTC1We7X2OzwfDPSM+d99wKtMidUFArtZDrxf0SEhJgo0Rs
ZTw74+eNscP+xivYPFMKmLjjzaN2r0zM5TRJsVo713xCOzHLD3sE1HyMQdFSnYOIqJ8B NQ==
Received: from p1lg14880.it.hpe.com ([16.230.97.201])
by mx0b-002e3701.pphosted.com (PPS) with ESMTPS id 3y831p4x7x-1
(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT);
Mon, 20 May 2024 18:36:41 +0000
Received: from p1lg14885.dc01.its.hpecorp.net (unknown [10.119.18.236])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest
SHA256)
(No client certificate requested)
by p1lg14880.it.hpe.com (Postfix) with ESMTPS id 776798005CD;
Mon, 20 May 2024 18:36:39 +0000 (UTC)
Received: from dog.eag.rdlabs.hpecorp.net (unknown [16.231.227.36])
by p1lg14885.dc01.its.hpecorp.net (Postfix) with ESMTP id 6AC5080476C;
Mon, 20 May 2024 18:36:37 +0000 (UTC)
Received: by dog.eag.rdlabs.hpecorp.net (Postfix, from userid 200934)
id B26F630000BAA; Mon, 20 May 2024 13:36:33 -0500 (CDT)
From: Steve Wahl <steve.wahl@hpe.com>
To: Steve Wahl <steve.wahl@hpe.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
Borislav Petkov <bp@alien8.de>, x86@kernel.org,
"H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org,
Pavin Joseph <me@pavinjoseph.com>, Eric Hagberg <ehagberg@gmail.com>
Cc: Simon Horman <horms@verge.net.au>, Eric Biederman <ebiederm@xmission.com>,
Dave Young <dyoung@redhat.com>, Sarah Brofeldt <srhb@dbc.dk>,
Russ Anderson <rja@hpe.com>, Dimitri Sivanich <sivanich@hpe.com>,
Hou Wenlong <houwenlong.hwl@antgroup.com>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>,
Yuntao Wang <ytcoode@gmail.com>, Bjorn Helgaas <bhelgaas@google.com>,
Joerg Roedel <jroedel@suse.de>, Michael Roth <michael.roth@amd.com>
Subject: [PATCH 3/3] x86/mm/ident_map: Use gbpages only where full GB page
should be mapped.
Date: Mon, 20 May 2024 13:36:33 -0500
Message-Id: <20240520183633.1457687-4-steve.wahl@hpe.com>
X-Mailer: git-send-email 2.26.2
In-Reply-To: <20240520183633.1457687-1-steve.wahl@hpe.com>
References: <20240520183633.1457687-1-steve.wahl@hpe.com>
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
List-Id: <linux-kernel.vger.kernel.org>
List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org>
List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Proofpoint-ORIG-GUID: kB2OdoC0ioKZxcX2bg6EmVmECzcjw9UW
X-Proofpoint-GUID: kB2OdoC0ioKZxcX2bg6EmVmECzcjw9UW
X-HPE-SCL: -1
X-Proofpoint-Virus-Version: vendor=baseguard
engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.650,FMLib:17.12.28.16
definitions=2024-05-20_09,2024-05-17_03,2024-05-17_01
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0
bulkscore=0 malwarescore=0
clxscore=1015 adultscore=0 priorityscore=1501 phishscore=0 mlxscore=0
suspectscore=0 spamscore=0 lowpriorityscore=0 impostorscore=0
mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1
engine=8.12.0-2405010000 definitions=main-2405200149
Content-Type: text/plain; charset="utf-8"
When ident_pud_init() uses only gbpages to create identity maps, large
ranges of addresses not actually requested can be included in the
resulting table; a 4K request will map a full GB. On UV systems, this
ends up including regions that will cause hardware to halt the system
if accessed (these are marked "reserved" by BIOS). Even processor
speculation into these regions is enough to trigger the system halt.
Only use gbpages when map creation requests include the full GB page
of space. Fall back to using smaller 2M pages when only portions of a
GB page are included in the request.
No attempt is made to coalesce mapping requests. If a request requires
a map entry at the 2M (pmd) level, subsequent mapping requests within
the same 1G region will also be at the pmd level, even if adjacent or
overlapping such requests could have been combined to map a full
gbpage. Existing usage starts with larger regions and then adds
smaller regions, so this should not have any great consequence.
Signed-off-by: Steve Wahl <steve.wahl@hpe.com>
Tested-by: Pavin Joseph <me@pavinjoseph.com>
Tested-by: Sarah Brofeldt <srhb@dbc.dk>
Tested-by: Eric Hagberg <ehagberg@gmail.com>
---
arch/x86/mm/ident_map.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/ident_map.c b/arch/x86/mm/ident_map.c
index 968d7005f4a7..a204a332c71f 100644
--- a/arch/x86/mm/ident_map.c
+++ b/arch/x86/mm/ident_map.c
@@ -26,18 +26,31 @@ static int ident_pud_init(struct x86_mapping_info *info=
, pud_t *pud_page,
for (; addr < end; addr =3D next) {
pud_t *pud =3D pud_page + pud_index(addr);
pmd_t *pmd;
+ bool use_gbpage;
=20
next =3D (addr & PUD_MASK) + PUD_SIZE;
if (next > end)
next =3D end;
=20
- if (info->direct_gbpages) {
- pud_t pudval;
+ /* if this is already a gbpage, this portion is already mapped */
+ if (pud_leaf(*pud))
+ continue;
+
+ /* Is using a gbpage allowed? */
+ use_gbpage =3D info->direct_gbpages;
=20
- if (pud_present(*pud))
- continue;
+ /* Don't use gbpage if it maps more than the requested region. */
+ /* at the beginning: */
+ use_gbpage &=3D ((addr & ~PUD_MASK) =3D=3D 0);
+ /* ... or at the end: */
+ use_gbpage &=3D ((next & ~PUD_MASK) =3D=3D 0);
+
+ /* Never overwrite existing mappings */
+ use_gbpage &=3D !pud_present(*pud);
+
+ if (use_gbpage) {
+ pud_t pudval;
=20
- addr &=3D PUD_MASK;
pudval =3D __pud((addr - info->offset) | info->page_flag);
set_pud(pud, pudval);
continue;
--=20
2.26.2