From: Laszlo Ersek <lersek@redhat.com>
To: edk2-devel-01 <edk2-devel@lists.01.org>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Leif Lindholm <leif.lindholm@linaro.org>
Subject: [PATCH v3 11/12] ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI
Date: Fri, 24 Mar 2017 23:38:18 +0100 [thread overview]
Message-ID: <20170324223819.11377-12-lersek@redhat.com> (raw)
In-Reply-To: <20170324223819.11377-1-lersek@redhat.com>
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=0x13bdb0000 ACPI 2.0=0x138440000
> MEMATTR=0x13a675018
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=0x13bdb0000 MEMATTR=0x138caa018
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 <ard.biesheuvel@linaro.org>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1430262
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
---
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/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
index e77bb04e2e9d..3fcbb6b080d8 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
@@ -25,15 +25,15 @@ [Sources]
PlatformHasAcpiDtDxe.c
[Packages]
- ArmVirtPkg/ArmVirtPkg.dec
EmbeddedPkg/EmbeddedPkg.dec
MdeModulePkg/MdeModulePkg.dec
MdePkg/MdePkg.dec
+ OvmfPkg/OvmfPkg.dec
[LibraryClasses]
BaseLib
DebugLib
- PcdLib
+ QemuFwCfgLib
UefiBootServicesTableLib
UefiDriverEntryPoint
@@ -41,8 +41,5 @@ [Guids]
gEdkiiPlatformHasAcpiGuid ## SOMETIMES_PRODUCES ## PROTOCOL
gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
-[FeaturePcd]
- gArmVirtTokenSpaceGuid.PcdPureAcpiBoot ## CONSUMES
-
[Depex]
TRUE
diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
index a718ce1b5a7b..8932dacabec5 100644
--- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
+++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
@@ -17,7 +17,7 @@
#include <Guid/PlatformHasDeviceTree.h>
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
-#include <Library/PcdLib.h>
+#include <Library/QemuFwCfgLib.h>
#include <Library/UefiBootServicesTableLib.h>
EFI_STATUS
@@ -27,18 +27,27 @@ PlatformHasAcpiDt (
IN EFI_SYSTEM_TABLE *SystemTable
)
{
- EFI_STATUS Status;
-
- Status = EFI_SUCCESS;
+ EFI_STATUS Status;
+ FIRMWARE_CONFIG_ITEM FwCfgItem;
+ UINTN FwCfgSize;
//
// If we fail to install any of the necessary protocols below, the OS will be
// unbootable anyway (due to lacking hardware description), so tolerate no
// errors here.
//
- // Always make ACPI available on 64-bit systems.
- //
- if (MAX_UINTN == MAX_UINT64) {
+ if (MAX_UINTN == MAX_UINT64 &&
+ !EFI_ERROR (
+ QemuFwCfgFindFile (
+ "etc/table-loader",
+ &FwCfgItem,
+ &FwCfgSize
+ )
+ )) {
+ //
+ // Only make ACPI available on 64-bit systems, and only if QEMU generates
+ // (a subset of) the ACPI tables.
+ //
Status = gBS->InstallProtocolInterface (
&ImageHandle,
&gEdkiiPlatformHasAcpiGuid,
@@ -48,21 +57,21 @@ PlatformHasAcpiDt (
if (EFI_ERROR (Status)) {
goto Failed;
}
+
+ return Status;
}
//
- // Expose the Device Tree unless PcdPureAcpiBoot is set.
+ // Expose the Device Tree otherwise.
//
- if (!FeaturePcdGet (PcdPureAcpiBoot)) {
- Status = gBS->InstallProtocolInterface (
- &ImageHandle,
- &gEdkiiPlatformHasDeviceTreeGuid,
- EFI_NATIVE_INTERFACE,
- NULL
- );
- if (EFI_ERROR (Status)) {
- goto Failed;
- }
+ Status = gBS->InstallProtocolInterface (
+ &ImageHandle,
+ &gEdkiiPlatformHasDeviceTreeGuid,
+ EFI_NATIVE_INTERFACE,
+ NULL
+ );
+ if (EFI_ERROR (Status)) {
+ goto Failed;
}
return Status;
--
2.9.3
next prev parent reply other threads:[~2017-03-24 22:38 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-24 22:38 [PATCH v3 00/12] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI Laszlo Ersek
2017-03-24 22:38 ` [PATCH v3 01/12] Revert "ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent" Laszlo Ersek
2017-03-24 22:38 ` [PATCH v3 02/12] Revert "ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot" Laszlo Ersek
2017-03-24 22:38 ` [PATCH v3 03/12] ArmVirtPkg/XenAcpiPlatformDxe: don't cast UINT64 to pointer directly Laszlo Ersek
2017-03-24 22:38 ` [PATCH v3 04/12] MdeModulePkg: introduce EDKII Platform Has ACPI GUID Laszlo Ersek
2017-03-24 22:41 ` Ard Biesheuvel
2017-03-28 8:20 ` Laszlo Ersek
2017-03-24 22:38 ` [PATCH v3 05/12] ArmPkg: introduce PlatformHasAcpiLib Laszlo Ersek
2017-03-24 22:42 ` Ard Biesheuvel
2017-03-24 22:38 ` [PATCH v3 06/12] EmbeddedPkg: introduce EDKII Platform Has Device Tree GUID Laszlo Ersek
2017-03-24 22:42 ` Ard Biesheuvel
2017-03-24 22:38 ` [PATCH v3 07/12] ArmVirtPkg: add PlatformHasAcpiDtDxe Laszlo Ersek
2017-03-24 22:38 ` [PATCH v3 08/12] ArmVirtPkg: add XenPlatformHasAcpiDtDxe Laszlo Ersek
2017-03-24 22:38 ` [PATCH v3 09/12] ArmVirtPkg: enable AcpiTableDxe and EFI_ACPI_TABLE_PROTOCOL dynamically Laszlo Ersek
2017-03-24 22:43 ` Ard Biesheuvel
2017-03-24 22:38 ` [PATCH v3 10/12] ArmVirtPkg/FdtClientDxe: install DT as sysconfig table in protocol notify Laszlo Ersek
2017-03-24 22:38 ` Laszlo Ersek [this message]
2017-03-24 22:38 ` [PATCH v3 12/12] ArmVirtPkg: remove PURE_ACPI_BOOT_ENABLE and PcdPureAcpiBoot Laszlo Ersek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170324223819.11377-12-lersek@redhat.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox