From nobody Fri Mar 29 06:56:10 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zoho.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1489003139020921.4003221596099; Wed, 8 Mar 2017 11:58:59 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id D5D0F80375; Wed, 8 Mar 2017 11:58:56 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id C6AB780375 for ; Wed, 8 Mar 2017 11:58:54 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 37C4FC05B1D1; Wed, 8 Mar 2017 19:58:50 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-47.phx2.redhat.com [10.3.117.47]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v28Jwh7t003421; Wed, 8 Mar 2017 14:58:47 -0500 X-Original-To: edk2-devel@ml01.01.org From: Laszlo Ersek To: edk2-devel-01 Date: Wed, 8 Mar 2017 20:58:38 +0100 Message-Id: <20170308195839.18689-2-lersek@redhat.com> In-Reply-To: <20170308195839.18689-1-lersek@redhat.com> References: <20170308195839.18689-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 08 Mar 2017 19:58:54 +0000 (UTC) Subject: [edk2] [PATCH v2 1/2] MdeModulePkg/AcpiTableDxe: condense whitespace around FADT.{DSDT, X_DSDT} X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Feng Tian , Michael Tsirkin , Ard Biesheuvel , Phil Dennis-Jordan , Leo Duran , Jiewen Yao , Al Stone , Star Zeng MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" This patch incurs no functional changes, it just removes some whitespace, and also makes sure we always assign AcpiTableInstance->Fadt3->Dsdt first, and AcpiTableInstance->Fadt3->XDsdt second. The goal is to separate the syntactic changes from the functional changes implemented by the next patch. Cc: Al Stone Cc: Ard Biesheuvel Cc: Feng Tian Cc: Igor Mammedov Cc: Jiewen Yao Cc: Leo Duran Cc: Michael Tsirkin Cc: Phil Dennis-Jordan Cc: Star Zeng Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Thomas Huth Reviewed-by: Feng Tian Reviewed-by: Star Zeng Reviewed-by: jiewen.yao@Intel.com --- Notes: v2: - no changes - pick up R-b's from Thomas and Feng =20 v1: NOTE for people on the CC list: =20 If you are not presently subscribed to edk2-devel and wish to comment on this patch publicly, you need to subscribe first, and wait for the subscription request to *complete* (see your inbox), *before* sending your followup. This is not ideal, but edk2-devel requires subscription before reflecting messages from someone. =20 Subscribe at . Thanks. MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 20 ++++++--= ------------ 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c b= /MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c index 7f95b9dc709d..7795ff7269ca 100644 --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c @@ -646,16 +646,12 @@ AddTableToList ( AcpiTableInstance->Fadt3->FirmwareCtrl =3D 0; } if ((UINT64)(UINTN)AcpiTableInstance->Dsdt3 < BASE_4GB) { - AcpiTableInstance->Fadt3->Dsdt =3D (UINT32) (UINTN) AcpiTableInst= ance->Dsdt3; + AcpiTableInstance->Fadt3->Dsdt =3D (UINT32) (UINTN) AcpiTableInsta= nce->Dsdt3; ZeroMem (&AcpiTableInstance->Fadt3->XDsdt, sizeof (UINT64)); } else { - Buffer64 =3D (UINT64) (UINTN) AcpiTableIn= stance->Dsdt3; - CopyMem ( - &AcpiTableInstance->Fadt3->XDsdt, - &Buffer64, - sizeof (UINT64) - ); AcpiTableInstance->Fadt3->Dsdt =3D 0; + Buffer64 =3D (UINT64) (UINTN) AcpiTableInstance->Dsdt3; + CopyMem (&AcpiTableInstance->Fadt3->XDsdt, &Buffer64, sizeof (UINT= 64)); } =20 // @@ -850,14 +846,10 @@ AddTableToList ( // if (AcpiTableInstance->Fadt3 !=3D NULL) { if ((UINT64)(UINTN)AcpiTableInstance->Dsdt3 < BASE_4GB) { - AcpiTableInstance->Fadt3->Dsdt =3D (UINT32) (UINTN) AcpiTableIn= stance->Dsdt3; + AcpiTableInstance->Fadt3->Dsdt =3D (UINT32) (UINTN) AcpiTableIns= tance->Dsdt3; } - Buffer64 =3D (UINT64) (UINTN) AcpiTableIn= stance->Dsdt3; - CopyMem ( - &AcpiTableInstance->Fadt3->XDsdt, - &Buffer64, - sizeof (UINT64) - ); + Buffer64 =3D (UINT64) (UINTN) AcpiTableInstance->Dsdt3; + CopyMem (&AcpiTableInstance->Fadt3->XDsdt, &Buffer64, sizeof (UINT= 64)); =20 // // Checksum FADT table --=20 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel From nobody Fri Mar 29 06:56:10 2024 Delivered-To: importer@patchew.org Received-SPF: none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) client-ip=198.145.21.10; envelope-from=edk2-devel-bounces@lists.01.org; helo=ml01.01.org; Authentication-Results: mx.zoho.com; spf=none (zoho.com: 198.145.21.10 is neither permitted nor denied by domain of lists.01.org) smtp.mailfrom=edk2-devel-bounces@lists.01.org; Return-Path: Received: from ml01.01.org (ml01.01.org [198.145.21.10]) by mx.zohomail.com with SMTPS id 1489003135796629.3895461783604; Wed, 8 Mar 2017 11:58:55 -0800 (PST) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 7B20680372; Wed, 8 Mar 2017 11:58:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id E188D802A8 for ; Wed, 8 Mar 2017 11:58:52 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 70916461C3; Wed, 8 Mar 2017 19:58:53 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-47.phx2.redhat.com [10.3.117.47]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v28Jwh7u003421; Wed, 8 Mar 2017 14:58:50 -0500 X-Original-To: edk2-devel@ml01.01.org From: Laszlo Ersek To: edk2-devel-01 Date: Wed, 8 Mar 2017 20:58:39 +0100 Message-Id: <20170308195839.18689-3-lersek@redhat.com> In-Reply-To: <20170308195839.18689-1-lersek@redhat.com> References: <20170308195839.18689-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 08 Mar 2017 19:58:53 +0000 (UTC) Subject: [edk2] [PATCH v2 2/2] MdeModulePkg/AcpiTableDxe: improve FADT.{DSDT, X_DSDT} mutual exclusion X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Feng Tian , Michael Tsirkin , Ard Biesheuvel , Phil Dennis-Jordan , Leo Duran , Jiewen Yao , Al Stone , Star Zeng MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" X-ZohoMail: RSF_4 Z_629925259 SPT_0 Content-Type: text/plain; charset="utf-8" The ACPI specification, up to and including revision 5.1 Errata A, allows the DSDT and X_DSDT fields to be both set in the FADT. (Obviously, this only makes sense if the DSDT address is representable in 4 bytes.) Starting with 5.1 Errata B, specifically for Mantis 1393 , the spec requires at most one of DSDT and X_DSDT to be set to a nonzero value. MdeModulePkg/AcpiTableDxe handles this mutual exclusion somewhat inconsistently. - If the caller of EFI_ACPI_TABLE_PROTOCOL.InstallAcpiTable() installs the tables in "DSDT, FADT" order, then we enforce the exclusion between the DSDT and X_DSDT fields: DSDT under 4GB FADT.DSDT FADT.X_DSDT [VARIANT B] -------------- --------- ----------- yes set clear no clear set This behavior conforms to 5.1 Errata B. (And it's not required by earlier versions of the spec.) - If the caller passes in the tables in "FADT, DSDT" relative order, then we do not enforce the exclusion: DSDT under 4GB FADT.DSDT FADT.X_DSDT [VARIANT A] -------------- --------- ----------- yes set set no clear set This satisfies 5.1 Errata A and earlier, but breaks 5.1 Errata B and later. Unify the handling of both relative orders. In particular, check the major and minor version numbers in the FADT. If the FADT version is strictly before 5.1, then implement [VARIANT A]. If the FADT version is equal to or larger than 5.1, then implement [VARIANT B]. We make three observations: - We can't check the FADT table version precisely against "5.1 Errata B"; erratum levels are not captured in the table. We err in the safe direction, namely we enforce the exclusion for "5.1" and "5.1 Errata A". - The same applies to "6.0" versus "6.0 Errata A". Because we cannot distinguish these two, we consider "6.0" to be "equal to or larger than 5.1", and apply [VARIANT B], enforcing the exclusion. - While a blanket [VARIANT B] would be simpler, there is a significant benefit to [VARIANT A], under the spec versions that permit it: compatibility with a wider range of OSPMs (typically, older ones). For example, Igor reported about a "DELL R430 system with rev4 FADT where DSDT and X_DSDT are pointing to the same address". Michael also reported about several systems that exhibit the same. Regression tested with the following KVM guests (QEMU built at ata0def594286d, "Merge remote-tracking branch 'remotes/bonzini/tags/for-upstream' into staging", 2017-01-30): - OVMF: boot and S3 suspend/resume - Ia32, Q35, SMM - Fedlet 20141209 - Ia32X64, Q35, SMM - Fedora 22 - Windows 7 - Windows 8.1 - Windows 10 - Windows Server 2008 R2 - Windows Server 2012 R2 - Windows Server 2016 Tech Preview 4 - X64, I440FX, no SMM - Fedora 24 - RHEL-6.7 - RHEL-7.2-ish - ArmVirtQemu: boot test with virtio-gpu - AARCH64 - Fedora 24 - RHELSA-7.3 - openSUSE Tumbleweed (4.8.4-based) This change is connected to ASWG ticket , which is now closed/fixed. Cc: Al Stone Cc: Ard Biesheuvel Cc: Feng Tian Cc: Igor Mammedov Cc: Jiewen Yao Cc: Leo Duran Cc: Michael Tsirkin Cc: Phil Dennis-Jordan Cc: Star Zeng Reported-by: Phil Dennis-Jordan Suggested-by: Igor Mammedov Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Phil Dennis-Jordan Reviewed-by: Star Zeng Reviewed-by: jiewen.yao@Intel.com --- Notes: v2: - simplify logic in RequireDsdtXDsdtExclusion() [Jiewen] - pick up Phil's R-b nonetheless (the above change is a minimal reformulation of code, with no behavioral difference) - add reference to Mantis#1757 to the commit message =20 v1: NOTE for people on the CC list: =20 If you are not presently subscribed to edk2-devel and wish to comment on this patch publicly, you need to subscribe first, and wait for the subscription request to *complete* (see your inbox), *before* sending your followup. This is not ideal, but edk2-devel requires subscription before reflecting messages from someone. =20 Subscribe at . Thanks. MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 62 ++++++++= +++++++++++- 1 file changed, 59 insertions(+), 3 deletions(-) diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c b= /MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c index 7795ff7269ca..4bb848df5203 100644 --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c @@ -430,6 +430,51 @@ ReallocateAcpiTableBuffer ( mEfiAcpiMaxNumTables =3D NewMaxTableNumber; return EFI_SUCCESS; } + +/** + Determine whether the FADT table passed in as parameter requires mutual + exclusion between the DSDT and X_DSDT fields. (That is, whether there ex= ists + an explicit requirement that at most one of those fields is permitted to= be + nonzero.) + + @param[in] Fadt The EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE object to + check. + + @retval TRUE Fadt requires mutual exclusion between DSDT and X_DSDT. + @retval FALSE Otherwise. +**/ +BOOLEAN +RequireDsdtXDsdtExclusion ( + IN EFI_ACPI_3_0_FIXED_ACPI_DESCRIPTION_TABLE *Fadt + ) +{ + // + // Mantis ticket #1393 was addressed in ACPI 5.1 Errata B. Unfortunately= , we + // can't tell apart 5.1 Errata A and 5.1 Errata B just from looking at t= he + // FADT table. Therefore let's require exclusion for table versions >=3D= 5.1. + // + // While this needlessly covers 5.1 and 5.1A too, it is safer to require + // DSDT<->X_DSDT exclusion for lax (5.1, 5.1A) versions of the spec than= to + // permit DSDT<->X_DSDT duplication for strict (5.1B) versions of the sp= ec. + // + // The same applies to 6.0 vs. 6.0A. While 6.0 does not require the + // exclusion, 6.0A and 6.1 do. Since we cannot distinguish 6.0 from 6.0A + // based on just the FADT, we lump 6.0 in with the rest of >=3D 5.1. + // + if ((Fadt->Header.Revision < 5) || + ((Fadt->Header.Revision =3D=3D 5) && + (((EFI_ACPI_5_1_FIXED_ACPI_DESCRIPTION_TABLE *)Fadt)->MinorVersion = =3D=3D 0))) { + // + // version <=3D 5.0 + // + return FALSE; + } + // + // version >=3D 5.1 + // + return TRUE; +} + /** This function adds an ACPI table to the table list. It will detect FACS= and allocate the correct type of memory and properly align the table. @@ -647,12 +692,16 @@ AddTableToList ( } if ((UINT64)(UINTN)AcpiTableInstance->Dsdt3 < BASE_4GB) { AcpiTableInstance->Fadt3->Dsdt =3D (UINT32) (UINTN) AcpiTableInsta= nce->Dsdt3; - ZeroMem (&AcpiTableInstance->Fadt3->XDsdt, sizeof (UINT64)); + if (RequireDsdtXDsdtExclusion (AcpiTableInstance->Fadt3)) { + Buffer64 =3D 0; + } else { + Buffer64 =3D AcpiTableInstance->Fadt3->Dsdt; + } } else { AcpiTableInstance->Fadt3->Dsdt =3D 0; Buffer64 =3D (UINT64) (UINTN) AcpiTableInstance->Dsdt3; - CopyMem (&AcpiTableInstance->Fadt3->XDsdt, &Buffer64, sizeof (UINT= 64)); } + CopyMem (&AcpiTableInstance->Fadt3->XDsdt, &Buffer64, sizeof (UINT64= )); =20 // // RSDP OEM information is updated to match the FADT OEM information @@ -847,8 +896,15 @@ AddTableToList ( if (AcpiTableInstance->Fadt3 !=3D NULL) { if ((UINT64)(UINTN)AcpiTableInstance->Dsdt3 < BASE_4GB) { AcpiTableInstance->Fadt3->Dsdt =3D (UINT32) (UINTN) AcpiTableIns= tance->Dsdt3; + if (RequireDsdtXDsdtExclusion (AcpiTableInstance->Fadt3)) { + Buffer64 =3D 0; + } else { + Buffer64 =3D AcpiTableInstance->Fadt3->Dsdt; + } + } else { + AcpiTableInstance->Fadt3->Dsdt =3D 0; + Buffer64 =3D (UINT64) (UINTN) AcpiTableInstance->Dsdt3; } - Buffer64 =3D (UINT64) (UINTN) AcpiTableInstance->Dsdt3; CopyMem (&AcpiTableInstance->Fadt3->XDsdt, &Buffer64, sizeof (UINT= 64)); =20 // --=20 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel