From nobody Sat Nov 2 12:27:38 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 1490709072673334.3801434288712; Tue, 28 Mar 2017 06:51:12 -0700 (PDT) Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 16F0421DFA91E; Tue, 28 Mar 2017 06:50:58 -0700 (PDT) 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 ABA8D200840DC for ; Tue, 28 Mar 2017 06:50:56 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2501E4DD5F; Tue, 28 Mar 2017 13:50:56 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-89.phx2.redhat.com [10.3.116.89]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1552F7DB71; Tue, 28 Mar 2017 13:50:54 +0000 (UTC) X-Original-To: edk2-devel@lists.01.org DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2501E4DD5F Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2501E4DD5F From: Laszlo Ersek To: edk2-devel-01 Date: Tue, 28 Mar 2017 15:50:32 +0200 Message-Id: <20170328135033.24238-12-lersek@redhat.com> In-Reply-To: <20170328135033.24238-1-lersek@redhat.com> References: <20170328135033.24238-1-lersek@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Tue, 28 Mar 2017 13:50:56 +0000 (UTC) Subject: [edk2] [PATCH v4 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Leif Lindholm , Ard Biesheuvel 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 will let QEMU's "-no-acpi" option exclusively expose DT vs. ACPI to the guest. Showing both is never needed (it is actually detrimental to the adoption of standards, such as SBSA / SBBR). * Without "-no-acpi", the firmware logs (from PlatformHasAcpiDtDxe) > Found FwCfg @ 0x9020008/0x9020000 > Found FwCfg DMA @ 0x9020010 > InstallProtocolInterface: [EdkiiPlatformHasAcpi] 0 plus the usual messages. Later the guest kernel logs > [ 0.000000] efi: SMBIOS 3.0=3D0x13bdb0000 ACPI 2.0=3D0x138440000 > MEMATTR=3D0x13a675018 before it lists the ACPI tables one by one. In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern matches no files, while the "/sys/firmware/acpi/tables/*" pattern matches the ACPI tables. * With "-no-acpi", the firmware logs: > PlatformHasAcpiDtDxe | Found FwCfg @ 0x9020008/0x9020000 > PlatformHasAcpiDtDxe | Found FwCfg DMA @ 0x9020010 > PlatformHasAcpiDtDxe | InstallProtocolInterface: > PlatformHasAcpiDtDxe | [EdkiiPlatformHasDeviceTree] 0 > FdtClientDxe | OnPlatformHasDeviceTree: exposing DTB @ > FdtClientDxe | 0x13FFBF000 to OS > ... > DXE_CORE | Driver [AcpiTableDxe] was discovered but not > DXE_CORE | loaded!! > DXE_CORE | Driver [QemuFwCfgAcpiPlatform] was discovered but > DXE_CORE | not loaded!! > ... > RamDiskDxe | RamDiskAcpiCheck: Cannot locate the EFI ACPI > RamDiskDxe | Table Protocol, unable to publish RAM disks to > RamDiskDxe | NFIT. (BootGraphicsResourceTableDxe's ReadyToBoot callback -- InstallBootGraphicsResourceTable() -- handles the lack of EFI_ACPI_TABLE_PROTOCOL silently.) Later the guest kernel logs > [ 0.000000] efi: SMBIOS 3.0=3D0x13bdb0000 MEMATTR=3D0x138caa018 In addition, in the guest, the "/sys/firmware/devicetree/*" shell pattern matches the directory "/sys/firmware/devicetree/base", which contains a large number of DT nodes, while the "/sys/firmware/acpi/tables/*" pattern matches no files. Cc: Ard Biesheuvel Cc: Leif Lindholm Ref: https://bugzilla.redhat.com/show_bug.cgi?id=3D1430262 Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek Reviewed-by: Ard Biesheuvel --- Notes: v3: - pick up MEMATTR log from repeated testing with Fedora guest (ACPI case) [Ard] - extend the commit message with "/sys/firmware/devicetree/*" and "/sys/firmware/acpi/tables/*" pattern matching in the guest - drop ArmVirtPkg.dec package dependency -- with the removal of the "pure ACPI boot" PCD dependency, ArmVirtPkg.dec actually becomes superfluous - adapt patch to protocol -> generic GUID renaming - pick up Ard's R-b ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 7 +-- ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 45 ++++++++++++= -------- 2 files changed, 29 insertions(+), 23 deletions(-) diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/Arm= VirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf index 2450500b3f0e..4466bead57c2 100644 --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf @@ -25,14 +25,14 @@ [Sources] PlatformHasAcpiDtDxe.c =20 [Packages] - ArmVirtPkg/ArmVirtPkg.dec EmbeddedPkg/EmbeddedPkg.dec MdePkg/MdePkg.dec + OvmfPkg/OvmfPkg.dec =20 [LibraryClasses] BaseLib DebugLib - PcdLib + QemuFwCfgLib UefiBootServicesTableLib UefiDriverEntryPoint =20 @@ -40,8 +40,5 @@ [Guids] gEdkiiPlatformHasAcpiGuid ## SOMETIMES_PRODUCES ## PROTOCOL gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL =20 -[FeaturePcd] - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES - [Depex] TRUE diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVi= rtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c index a718ce1b5a7b..8932dacabec5 100644 --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c @@ -17,7 +17,7 @@ #include #include #include -#include +#include #include =20 EFI_STATUS @@ -27,18 +27,27 @@ PlatformHasAcpiDt ( IN EFI_SYSTEM_TABLE *SystemTable ) { - EFI_STATUS Status; - - Status =3D EFI_SUCCESS; + EFI_STATUS Status; + FIRMWARE_CONFIG_ITEM FwCfgItem; + UINTN FwCfgSize; =20 // // If we fail to install any of the necessary protocols below, the OS wi= ll be // unbootable anyway (due to lacking hardware description), so tolerate = no // errors here. // - // Always make ACPI available on 64-bit systems. - // - if (MAX_UINTN =3D=3D MAX_UINT64) { + if (MAX_UINTN =3D=3D MAX_UINT64 && + !EFI_ERROR ( + QemuFwCfgFindFile ( + "etc/table-loader", + &FwCfgItem, + &FwCfgSize + ) + )) { + // + // Only make ACPI available on 64-bit systems, and only if QEMU genera= tes + // (a subset of) the ACPI tables. + // Status =3D gBS->InstallProtocolInterface ( &ImageHandle, &gEdkiiPlatformHasAcpiGuid, @@ -48,21 +57,21 @@ PlatformHasAcpiDt ( if (EFI_ERROR (Status)) { goto Failed; } + + return Status; } =20 // - // Expose the Device Tree unless PcdPureAcpiBoot is set. + // Expose the Device Tree otherwise. // - if (!FeaturePcdGet (PcdPureAcpiBoot)) { - Status =3D gBS->InstallProtocolInterface ( - &ImageHandle, - &gEdkiiPlatformHasDeviceTreeGuid, - EFI_NATIVE_INTERFACE, - NULL - ); - if (EFI_ERROR (Status)) { - goto Failed; - } + Status =3D gBS->InstallProtocolInterface ( + &ImageHandle, + &gEdkiiPlatformHasDeviceTreeGuid, + EFI_NATIVE_INTERFACE, + NULL + ); + if (EFI_ERROR (Status)) { + goto Failed; } =20 return Status; --=20 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel