From: Laszlo Ersek <lersek@redhat.com>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "edk2-devel@lists.01.org" <edk2-devel@lists.01.org>,
Marc Zyngier <marc.zyngier@arm.com>,
Mark Rutland <mark.rutland@arm.com>,
Drew Jones <drjones@redhat.com>, Jon Masters <jcm@redhat.com>
Subject: Re: [PATCH v2] ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override
Date: Wed, 29 Mar 2017 21:35:45 +0200 [thread overview]
Message-ID: <41a87740-7634-bfde-d2fb-3767a5c33140@redhat.com> (raw)
In-Reply-To: <CAKv+Gu-=5P6u7nC-dWvMnZWKnXMQBy8tci6rGzvHRH_F_-qykw@mail.gmail.com>
On 03/29/17 21:10, Ard Biesheuvel wrote:
> On 29 March 2017 at 19:44, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 03/29/17 19:50, Ard Biesheuvel wrote:
>>> In general, we should not present two separate (and inevitably different)
>>> hardware descriptions to the OS, in the form of ACPI tables and a device
>>> tree blob. For this reason, we recently added the logic to ArmVirtQemu to
>>> only expose the ACPI 2.0 entry point if no DT binary is being passed, and
>>> vice versa.
>>>
>>> However, this is arguably a regression for those who relied on DT
>>> descriptions being available, even if the former behavior can be
>>> restored by passing the -no-acpi switch to QEMU.
>>>
>>> So allow a secret handshake with the UEFI Shell, to set a variable that
>>> will result in ACPI to be disabled on subsequent boots even if -no-acpi
>>> was not passed on the QEMU command line.
>>>
>>> setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceNoAcpi =01
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>> ArmVirtPkg/ArmVirtPkg.dec | 9 +++++++++
>>> ArmVirtPkg/ArmVirtQemu.dsc | 3 +++
>>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c | 2 ++
>>> ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 5 +++++
>>> 4 files changed, 19 insertions(+)
>>>
>>> diff --git a/ArmVirtPkg/ArmVirtPkg.dec b/ArmVirtPkg/ArmVirtPkg.dec
>>> index efe83a383d55..a8603e1b80e5 100644
>>> --- a/ArmVirtPkg/ArmVirtPkg.dec
>>> +++ b/ArmVirtPkg/ArmVirtPkg.dec
>>> @@ -34,6 +34,8 @@ [Guids.common]
>>> gArmVirtTokenSpaceGuid = { 0x0B6F5CA7, 0x4F53, 0x445A, { 0xB7, 0x6E, 0x2E, 0x36, 0x5B, 0x80, 0x63, 0x66 } }
>>> gEarlyPL011BaseAddressGuid = { 0xB199DEA9, 0xFD5C, 0x4A84, { 0x80, 0x82, 0x2F, 0x41, 0x70, 0x78, 0x03, 0x05 } }
>>>
>>> + gArmVirtVariableGuid = { 0x50bea1e5, 0xa2c5, 0x46e9, { 0x9b, 0x3a, 0x59, 0x59, 0x65, 0x16, 0xb0, 0x0a } }
>>> +
>>> [Protocols]
>>> gFdtClientProtocolGuid = { 0xE11FACA0, 0x4710, 0x4C8E, { 0xA7, 0xA2, 0x01, 0xBA, 0xA2, 0x59, 0x1B, 0x4C } }
>>>
>>> @@ -58,3 +60,10 @@ [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
>>> +
>>> +[PcdsDynamic]
>>> + #
>>> + # Whether to force disable ACPI, regardless of the fw_cfg settings
>>> + # exposed by QEMU
>>> + #
>>> + gArmVirtTokenSpaceGuid.PcdForceNoAcpi|0x0|BOOLEAN|0x00000003
>>> diff --git a/ArmVirtPkg/ArmVirtQemu.dsc b/ArmVirtPkg/ArmVirtQemu.dsc
>>> index 4075b92aa2cb..76a7908105ab 100644
>>> --- a/ArmVirtPkg/ArmVirtQemu.dsc
>>> +++ b/ArmVirtPkg/ArmVirtQemu.dsc
>>> @@ -210,6 +210,9 @@ [PcdsDynamicDefault.common]
>>> gEfiMdeModulePkgTokenSpaceGuid.PcdSmbiosDocRev|0x0
>>> gUefiOvmfPkgTokenSpaceGuid.PcdQemuSmbiosValidated|FALSE
>>>
>>> +[PcdsDynamicHii]
>>> + gArmVirtTokenSpaceGuid.PcdForceNoAcpi|L"ForceNoAcpi"|gArmVirtVariableGuid|0x0|FALSE|NV,BS
>>> +
>>> ################################################################################
>>> #
>>> # Components Section - list of all EDK II Modules needed by this Platform
>>> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
>>> index 8932dacabec5..da3cee645cfb 100644
>>> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
>>> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c
>>> @@ -17,6 +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>
>>>
>>> @@ -37,6 +38,7 @@ PlatformHasAcpiDt (
>>> // errors here.
>>> //
>>> if (MAX_UINTN == MAX_UINT64 &&
>>> + !PcdGetBool (PcdForceNoAcpi) &&
>>> !EFI_ERROR (
>>> QemuFwCfgFindFile (
>>> "etc/table-loader",
>>> diff --git a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>>> index 4466bead57c2..08025f0c3722 100644
>>> --- a/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>>> +++ b/ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf
>>> @@ -25,6 +25,7 @@ [Sources]
>>> PlatformHasAcpiDtDxe.c
>>>
>>> [Packages]
>>> + ArmVirtPkg/ArmVirtPkg.dec
>>> EmbeddedPkg/EmbeddedPkg.dec
>>> MdePkg/MdePkg.dec
>>> OvmfPkg/OvmfPkg.dec
>>> @@ -32,6 +33,7 @@ [Packages]
>>> [LibraryClasses]
>>> BaseLib
>>> DebugLib
>>> + PcdLib
>>> QemuFwCfgLib
>>> UefiBootServicesTableLib
>>> UefiDriverEntryPoint
>>> @@ -40,5 +42,8 @@ [Guids]
>>> gEdkiiPlatformHasAcpiGuid ## SOMETIMES_PRODUCES ## PROTOCOL
>>> gEdkiiPlatformHasDeviceTreeGuid ## SOMETIMES_PRODUCES ## PROTOCOL
>>>
>>> +[Pcd]
>>> + gArmVirtTokenSpaceGuid.PcdForceNoAcpi
>>> +
>>> [Depex]
>>> TRUE
>>>
>>
>> Technically the patch is sound. I continue to disagree with its goal though.
>>
>> Technically, the patch could be improved (towards its wrong goal) by
>> exposing the boolean knob with an HII checkbox, called "disable ACPI
>> regardless of what the QEMU command line says". That would mirror Marc's
>> comments from earlier.
>>
>> For now, I actually agree with you that we shouldn't expose the knob
>> through HII however. Your reason for not doing HII is to mitigate what
>> you perceive as a regression as quickly as possible.
>
> Not quite. I just think there is no reason to advertise the existence
> of this facility.
>
>> My reason is that I
>> want to keep this loophole out of public view as much as possible, and
>> the UEFI shell is arguably harder to approach than an HII form.
>>
>
> Indeed.
>
>> * Please extend the commit message with the UEFI shell command that
>> closes the loophole again.
>>
>> * Also, please get Marc and Mark to ACK this patch, using their @arm.com
>> email addresses. (I wish I could get Leif to ACK the patch as well, but
>> he's on vacation.)
>>
>> * Finally, please add:
>>
>> Abstained-by: Laszlo Ersek <lersek@redhat.com>
>>
>> before pushing the patch.
>>
>
> Thanks, I guess.
>
>> The commit log has to show that ARM people were okay with this, and that
>> my own self was opposed. I generally abhor regressions, but in this case
>> I feel the risk for the ecosystem is too large, so abstaining (in a
>> documented way) is the best I can do for you now. I'll re-state for one
>> last time that IMO this patch will contribute to the fragmentation that
>> we see in the hardware description space.
>>
>
> How on earth is having two ways to disable ACPI rather than one going
> to cause fragmentation? Unlike v1, this patch does not allow you to
> expose both DT and ACPI tables at the same time.
Oopsie daisy. You actually updated the commit message too. (I have now
formally diffed v1 vs. v2, including commit msg -- I generally do that
when reviewing incremental versions of patches, but it has been a very
long day, and I failed to get my mind off the track set up by v1). I got
really no good explanation for missing the fundamental logic change
between v1 and v2. As you say, version 2 preserves the mutual exclusion
between DT and ACPI that I'm so annoyingly obsessed about. Thank you for
the update.
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Laszlo
next prev parent reply other threads:[~2017-03-29 19:35 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-29 17:50 [PATCH v2] ArmVirtPkg/PlatformHasAcpiDtDxe: allow guest level ACPI disable override Ard Biesheuvel
2017-03-29 18:44 ` Laszlo Ersek
2017-03-29 19:10 ` Ard Biesheuvel
2017-03-29 19:35 ` Laszlo Ersek [this message]
2017-03-30 8:40 ` Ard Biesheuvel
2017-03-30 16:16 ` Laszlo Ersek
2017-03-31 10:48 ` Ard Biesheuvel
[not found] ` <e3ab9b91-8e0f-52ab-bb3a-53bd0cacf17c@arm.com>
2017-03-31 9:59 ` Laszlo Ersek
2017-03-31 10:10 ` Laszlo Ersek
2017-03-31 10:16 ` Ard Biesheuvel
2017-03-31 10:46 ` Laszlo Ersek
2017-03-31 10:52 ` Ard Biesheuvel
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=41a87740-7634-bfde-d2fb-3767a5c33140@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