From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Laszlo Ersek <lersek@redhat.com>
Cc: edk2-devel@ml01.01.org, drjones@redhat.com, leif.lindholm@linaro.org
Subject: Re: [PATCH 3/3] ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent
Date: Sat, 11 Mar 2017 08:30:53 +0100 [thread overview]
Message-ID: <5A0A8801-DC29-4F20-B9C7-323B7E7D55EA@linaro.org> (raw)
In-Reply-To: <feac8850-256f-5bb6-cd94-8330f8d9a976@redhat.com>
> On 11 Mar 2017, at 08:21, Laszlo Ersek <lersek@redhat.com> wrote:
>
>> On 03/11/17 06:55, Laszlo Ersek wrote:
>>> On 03/09/17 17:04, Ard Biesheuvel wrote:
>>> Instead of having a build time switch to prevent the FDT configuration
>>> table from being installed, make this behavior dependent on whether we
>>> are passing ACPI tables to the OS. This is done by looking for the
>>> ACPI 2.0 configuration table, and only installing the FDT one if the
>>> ACPI one cannot be found.
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>> ArmVirtPkg/ArmVirtPkg.dec | 10 ----------
>>> ArmVirtPkg/ArmVirtQemu.dsc | 5 -----
>>> ArmVirtPkg/FdtClientDxe/FdtClientDxe.c | 15 ++++++++++-----
>>> ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf | 5 ++---
>>> 4 files changed, 12 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
>>> index a5ec42166445..efe83a383d55 100644
>>> --- a/ArmVirtPkg/ArmVirtPkg.dec
>>> +++ b/ArmVirtPkg/ArmVirtPkg.dec
>>> @@ -58,13 +58,3 @@ [PcdsFixedAtBuild, PcdsPatchableInModule]
>>> # EFI_VT_100_GUID.
>>> #
>>> gArmVirtTokenSpaceGuid.PcdTerminalTypeGuidBuffer|{0x65, 0x60, 0xA6, 0xDF, 0x19, 0xB4, 0xD3, 0x11, 0x9A, 0x2D, 0x00, 0x90, 0x27, 0x3F, 0xC1, 0x4D}|VOID*|0x00000007
>>> -
>>> -[PcdsFeatureFlag]
>>> - #
>>> - # Pure ACPI boot
>>> - #
>>> - # Inhibit installation of the FDT as a configuration table if this feature
>>> - # PCD is TRUE. Otherwise, the OS is presented with both a DT and an ACPI
>>> - # description of the platform, and it is up to the OS to choose.
>>> - #
>>> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|FALSE|BOOLEAN|0x0000000a
>>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>>> index 477dfdcfc764..7b266b98b949 100644
>>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>>> @@ -34,7 +34,6 @@ [Defines]
>>> # -D FLAG=VALUE
>>> #
>>> DEFINE SECURE_BOOT_ENABLE = FALSE
>>> - DEFINE PURE_ACPI_BOOT_ENABLE = FALSE
>>>
>>> !include ArmVirtPkg/ArmVirt.dsc.inc
>>>
>>> @@ -94,10 +93,6 @@ [PcdsFeatureFlag.common]
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutGopSupport|TRUE
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdConOutUgaSupport|FALSE
>>>
>>> -!if $(PURE_ACPI_BOOT_ENABLE) == TRUE
>>> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot|TRUE
>>> -!endif
>>> -
>>> [PcdsFixedAtBuild.common]
>>> gArmPlatformTokenSpaceGuid.PcdCoreCount|1
>>> !if $(ARCH) == AARCH64
>>> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
>>> index 0327af5739f2..2981977f3d20 100644
>>> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
>>> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.c
>>> @@ -17,6 +17,7 @@
>>> #include <Library/DebugLib.h>
>>> #include <Library/UefiDriverEntryPoint.h>
>>> #include <Library/UefiBootServicesTableLib.h>
>>> +#include <Library/UefiLib.h>
>>> #include <Library/HobLib.h>
>>> #include <libfdt.h>
>>>
>>> @@ -312,12 +313,16 @@ OnReadyToBoot (
>>> )
>>> {
>>> EFI_STATUS Status;
>>> + VOID *Table;
>>>
>>> - if (!FeaturePcdGet (PcdPureAcpiBoot)) {
>>> - //
>>> - // Only install the FDT as a configuration table if we want to leave it up
>>> - // to the OS to decide whether it prefers ACPI over DT.
>>> - //
>>> + //
>>> + // Only install the FDT as a configuration table if we are not exposing
>>> + // ACPI 2.0 (or later) tables. Note that the legacy ACPI table GUID has
>>> + // no meaning on ARM since we need at least ACPI 5.0 support, and the
>>> + // 64-bit ACPI 2.0 table GUID is mandatory in that case.
>>> + //
>>> + Status = EfiGetSystemConfigurationTable (&gEfiAcpi20TableGuid, &Table);
>>> + if (EFI_ERROR (Status) || Table == NULL) {
>>> Status = gBS->InstallConfigurationTable (&gFdtTableGuid, mDeviceTreeBase);
>>> ASSERT_EFI_ERROR (Status);
>>> }
>>
>> This code breaks the DT-only ("-no-acpi") boot with boot graphics
>> (virtio-gpu) enabled.
>>
>> Namely, we recently included BootGraphicsResourceTableDxe in the build.
>> That driver calls InstallAcpiTable() for BGRT, which in turn causes
>> AcpiTableDxe to call InstallConfigurationTable(), via PublishTables().
>>
>> We all missed that just because QEMU doesn't produce ACPI payload (and
>> we consequently don't install it), other drivers in edk2 may
>> unconditionally install "auxiliary" ACPI tables, which minimally trigger
>> the presence of the RSD PTR, RSDT and XSDT, and prevent DT installation.
>> Such a crippled set of ACPI tables isn't sufficient for booting however.
>>
>> We have functions like FindAcpiFacsTableByAcpiGuid(), ScanTableInXSDT()
>> and ScanTableInRSDT() in
>> "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c". I
>> think the above check should be reworked to look for the FADT
>> (EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) with code lifted
>> from these helper functions. No driver outside of
>> QemuFwCfgAcpiPlatformDxe will install the FADT. And, the FADT will
>> always be part of QEMU's ACPI payload, if it generates one.
>
> ... BTW this is exactly the kind of hard-to-predict unreliability of
> ReadyToBoot callbacks that I was worried about. The patches that I
> posted looked for the "etc/table-loader" fw_cfg file, which directly
> corresponds to the absence of the "-no-acpi" switch. With a ReadyToBoot
> callback, we depend on a larger, and fuzzier, pile of state.
>
> I'm not suggesting that we return to my series -- I think this one can
> be fixed up by looking for the FADT in particular --, I'd just like if
> we all grew a healthy aversion and distrust to ReadyToBoot callbacks.
> Their perceived simplicity is deceptive.
>
Point taken. But couldn't we still check the existence of that at ReadyToBoot?
>
>>
>>> diff --git a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
>>> index 00017727c32c..9861f41e968b 100644
>>> --- a/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
>>> +++ b/ArmVirtPkg/FdtClientDxe/FdtClientDxe.inf
>>> @@ -37,17 +37,16 @@ [LibraryClasses]
>>> HobLib
>>> UefiBootServicesTableLib
>>> UefiDriverEntryPoint
>>> + UefiLib
>>>
>>> [Protocols]
>>> gFdtClientProtocolGuid ## PRODUCES
>>>
>>> [Guids]
>>> + gEfiAcpi20TableGuid
>>> gEfiEventReadyToBootGuid
>>> gFdtHobGuid
>>> gFdtTableGuid
>>>
>>> -[FeaturePcd]
>>> - gArmVirtTokenSpaceGuid.PcdPureAcpiBoot
>>> -
>>> [Depex]
>>> TRUE
>>>
>>
>> _______________________________________________
>> edk2-devel mailing list
>> edk2-devel@lists.01.org
>> https://lists.01.org/mailman/listinfo/edk2-devel
>>
>
next prev parent reply other threads:[~2017-03-11 7:30 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-09 16:03 [PATCH 0/3] ArmVirtQemu: make DT vs ACPI support mutually exclusive Ard Biesheuvel
2017-03-09 16:03 ` [PATCH 1/3] ArmVirtPkg/ArmVirtPL031FdtClientLib: unconditionally disable DT node Ard Biesheuvel
2017-03-09 16:25 ` Leif Lindholm
2017-03-09 16:51 ` Laszlo Ersek
2017-03-09 16:04 ` [PATCH 2/3] ArmVirtPkg/FdtClientDxe: install DT configuration table at ReadyToBoot Ard Biesheuvel
2017-03-09 16:31 ` Leif Lindholm
2017-03-09 16:55 ` Laszlo Ersek
2017-03-09 16:04 ` [PATCH 3/3] ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent Ard Biesheuvel
2017-03-09 16:33 ` Leif Lindholm
2017-03-09 17:07 ` Laszlo Ersek
2017-03-11 5:55 ` Laszlo Ersek
2017-03-11 6:57 ` Ard Biesheuvel
2017-03-11 7:38 ` Laszlo Ersek
2017-03-11 10:26 ` Leif Lindholm
2017-03-13 10:23 ` Ard Biesheuvel
2017-03-13 14:53 ` Laszlo Ersek
2017-03-13 14:59 ` Ard Biesheuvel
2017-03-13 20:39 ` Laszlo Ersek
2017-03-13 20:55 ` Laszlo Ersek
2017-03-13 20:55 ` Ard Biesheuvel
2017-03-11 7:21 ` Laszlo Ersek
2017-03-11 7:30 ` Ard Biesheuvel [this message]
2017-03-11 7:41 ` Laszlo Ersek
2017-03-11 9:19 ` Ard Biesheuvel
2017-03-11 10:06 ` 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=5A0A8801-DC29-4F20-B9C7-323B7E7D55EA@linaro.org \
--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