From nobody Fri May 17 20:20:09 2024 Delivered-To: importer@patchew.org Received-SPF: pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) client-ip=192.237.175.120; envelope-from=xen-devel-bounces@lists.xenproject.org; helo=lists.xenproject.org; Authentication-Results: mx.zohomail.com; spf=pass (zohomail.com: domain of lists.xenproject.org designates 192.237.175.120 as permitted sender) smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Return-Path: Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) by mx.zohomail.com with SMTPS id 166545978186885.23896301739387; Mon, 10 Oct 2022 20:43:01 -0700 (PDT) Received: from list by lists.xenproject.org with outflank-mailman.419422.664195 (Exim 4.92) (envelope-from ) id 1oi69q-0004e9-KU; Tue, 11 Oct 2022 03:42:18 +0000 Received: by outflank-mailman (output) from mailman id 419422.664195; Tue, 11 Oct 2022 03:42:18 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oi69q-0004e2-G6; Tue, 11 Oct 2022 03:42:18 +0000 Received: by outflank-mailman (input) for mailman id 419422; Tue, 11 Oct 2022 03:42:16 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1oi69o-0004dw-61 for xen-devel@lists.xenproject.org; Tue, 11 Oct 2022 03:42:16 +0000 Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id b0cda750-4916-11ed-91b4-6bf2151ebd3b; Tue, 11 Oct 2022 05:42:13 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id EFE665C0151; Mon, 10 Oct 2022 23:42:11 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 10 Oct 2022 23:42:11 -0400 Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 10 Oct 2022 23:42:11 -0400 (EDT) X-Outflank-Mailman: Message body and most headers restored to incoming version 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" X-Inumbo-ID: b0cda750-4916-11ed-91b4-6bf2151ebd3b DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= invisiblethingslab.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1665459731; x=1665546131; bh=PNRzeYBxnqmwQZTl997sPEK/gSvhfY9baZ4 KGgodxYk=; b=NUsRfSiQHRdJpvyEuXFl0W3rLydfl68+aLCgmUKBS/KGQCZMfKU c/oajzF/woMQzNTW5jjMdsQ/bgnBiR4rl90TOeLb5x6/31h+YeCRjmHonNRmGVtR miM+AEKPxjPRLI26+V9tOfIeN/tqIczQttgtucP/ipb6OhPF8wC07IpDO2vWbXfJ hOgv13YkOTCvMzaesN/adJS+W4qSpucfcPKXIDQt/QBCu7uR/teCRvHYPhRLi54I mH4gEOAscAAmJzfaAkap6QkuloOtTkxbbWnFgz5V5vMZNyo9rgEA68N51hgsY1wm FHr2dYPszgnzAC/R6YLFTVuZtcnK0N+HUsQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:message-id:mime-version:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; t=1665459731; x=1665546131; bh=PNRzeYBxnqmwQ ZTl997sPEK/gSvhfY9baZ4KGgodxYk=; b=fxu690SRE8UDM/+dQ9J4CwvlydXFg g4S0qhCXW2FKOJfsUaAl/b+W5gK9KdVZGPcYZEd2xe10fjSw6rCG9/8c+NbapH7G 1XSkQQLe8zSw+6TN1vnkKy96R2sOcCpfygofWCOzvkcXXb5jiJyc7tAU283PjNH+ y9fISvzvSBTDaguVwMH/QfKRFTipfPvuy2CQRTImpYKFZBlR6wEDlt3xyVO/MikO r9eFzRssDE65zTkrQbONYzAHLXzlzoUzBWKYcrTQj7alyOI2RITHSUGlrOB/0pfm ZrJ2WFgssnqA/lq/DJ1uZX97232dldU+UFwoNk+Nk2pEMvWr7w0ZU1EWQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeejhedgjedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkofggtgfgsehtkeertdertdejnecuhfhrohhmpeffvghmihcu ofgrrhhivgcuqfgsvghnohhurhcuoeguvghmihesihhnvhhishhisghlvghthhhinhhgsh hlrggsrdgtohhmqeenucggtffrrghtthgvrhhnpedvhfeltddtgedvtdefvdelteehtdeh teeugfdtjeehleffkedvjeevkeejkeekgfenucffohhmrghinhepgigvnhhprhhojhgvtg htrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhho mhepuggvmhhisehinhhvihhsihgslhgvthhhihhnghhslhgrsgdrtghomh X-ME-Proxy: Feedback-ID: iac594737:Fastmail From: Demi Marie Obenour To: Xen developer discussion Cc: Demi Marie Obenour , Jan Beulich , Ard Biesheuval Subject: [PATCH v2] Use EfiACPIReclaimMemory for ESRT Date: Mon, 10 Oct 2022 23:42:03 -0400 Message-Id: X-Mailer: git-send-email 2.37.3 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-ZM-MESSAGEID: 1665459782463100001 A previous patch tried to get Linux to use the ESRT under Xen if it is in memory of type EfiRuntimeServicesData. However, this turns out to be a bad idea. Ard Biesheuvel pointed out that EfiRuntimeServices* memory winds up fragmenting both the EFI page tables and the direct map, and that EfiACPIReclaimMemory is a much better choice for this purpose. Link: https://lists.xenproject.org/archives/html/xen-devel/2022-09/msg01365= .html Signed-off-by: Demi Marie Obenour Acked-by: Jan Beulich --- Changes since v1: - Add link to Ard Biesheuvel=E2=80=99s post on xen-devel - Expand comment to mention buggy firmware that place the ESRT in EfiBootServicesData. xen/common/efi/boot.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/xen/common/efi/boot.c b/xen/common/efi/boot.c index db0340c8e2628314226c618dda11ede4c62fdf3b..b3de1011ee58a67a82a94da050e= b1343f4e37faa 100644 --- a/xen/common/efi/boot.c +++ b/xen/common/efi/boot.c @@ -601,11 +601,14 @@ static size_t __init get_esrt_size(const EFI_MEMORY_D= ESCRIPTOR *desc) if ( physical_start > esrt || esrt - physical_start >=3D len ) return 0; /* - * The specification requires EfiBootServicesData, but accept - * EfiRuntimeServicesData, which is a more logical choice. + * The specification requires EfiBootServicesData, but also accept + * EfiRuntimeServicesData (for compatibility with buggy firmware) + * and EfiACPIReclaimMemory (which will contain the tables after + * successful kexec). */ if ( (desc->Type !=3D EfiRuntimeServicesData) && - (desc->Type !=3D EfiBootServicesData) ) + (desc->Type !=3D EfiBootServicesData) && + (desc->Type !=3D EfiACPIReclaimMemory) ) return 0; available_len =3D len - (esrt - physical_start); if ( available_len <=3D offsetof(EFI_SYSTEM_RESOURCE_TABLE, Entries) ) @@ -1144,18 +1147,19 @@ static void __init efi_relocate_esrt(EFI_SYSTEM_TAB= LE *SystemTable) for ( i =3D 0; i < info_size; i +=3D mdesc_size ) { /* - * ESRT needs to be moved to memory of type EfiRuntimeServicesData + * ESRT needs to be moved to memory of type EfiACPIReclaimMemory * so that the memory it is in will not be used for other purposes. */ void *new_esrt =3D NULL; - size_t esrt_size =3D get_esrt_size(memory_map + i); + const EFI_MEMORY_DESCRIPTOR *desc =3D memory_map + i; + size_t esrt_size =3D get_esrt_size(desc); =20 if ( !esrt_size ) continue; - if ( ((EFI_MEMORY_DESCRIPTOR *)(memory_map + i))->Type =3D=3D - EfiRuntimeServicesData ) + if ( desc->Type =3D=3D EfiRuntimeServicesData || + desc->Type =3D=3D EfiACPIReclaimMemory ) break; /* ESRT already safe from reuse */ - status =3D efi_bs->AllocatePool(EfiRuntimeServicesData, esrt_size, + status =3D efi_bs->AllocatePool(EfiACPIReclaimMemory, esrt_size, &new_esrt); if ( status =3D=3D EFI_SUCCESS && new_esrt ) { --=20 Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab