audk/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c

89 lines
2.4 KiB
C
Raw Normal View History

/** @file
Decide whether the firmware should expose an ACPI- and/or a Device Tree-based
hardware description to the operating system.
Copyright (c) 2017, Red Hat, Inc.
This program and the accompanying materials are licensed and made available
under the terms and conditions of the BSD License which accompanies this
distribution. The full text of the license may be found at
http://opensource.org/licenses/bsd-license.php
THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS, WITHOUT
WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
**/
#include <Guid/PlatformHasAcpi.h>
#include <Guid/PlatformHasDeviceTree.h>
#include <Library/BaseLib.h>
#include <Library/DebugLib.h>
#include <Library/PcdLib.h>
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI 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>
2017-03-17 17:50:24 +01:00
#include <Library/QemuFwCfgLib.h>
#include <Library/UefiBootServicesTableLib.h>
EFI_STATUS
EFIAPI
PlatformHasAcpiDt (
IN EFI_HANDLE ImageHandle,
IN EFI_SYSTEM_TABLE *SystemTable
)
{
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI 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>
2017-03-17 17:50:24 +01:00
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.
//
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI 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>
2017-03-17 17:50:24 +01:00
if (MAX_UINTN == MAX_UINT64 &&
!PcdGetBool (PcdForceNoAcpi) &&
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI 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>
2017-03-17 17:50:24 +01:00
!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,
EFI_NATIVE_INTERFACE,
NULL
);
if (EFI_ERROR (Status)) {
goto Failed;
}
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI 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>
2017-03-17 17:50:24 +01:00
return Status;
}
//
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI 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>
2017-03-17 17:50:24 +01:00
// Expose the Device Tree otherwise.
//
ArmVirtPkg/PlatformHasAcpiDtDxe: don't expose DT if QEMU provides ACPI 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>
2017-03-17 17:50:24 +01:00
Status = gBS->InstallProtocolInterface (
&ImageHandle,
&gEdkiiPlatformHasDeviceTreeGuid,
EFI_NATIVE_INTERFACE,
NULL
);
if (EFI_ERROR (Status)) {
goto Failed;
}
return Status;
Failed:
ASSERT_EFI_ERROR (Status);
CpuDeadLoop ();
//
// Keep compilers happy.
//
return Status;
}