Re: [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation

[Laszlo Ersek <lersek@redhat.com>]

On 03/29/17 18:02, Ard Biesheuvel wrote:
> On 29 March 2017 at 17:00, Laszlo Ersek <lersek@redhat.com> wrote:
>> On 03/29/17 17:19, 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 rely on both
>>> descriptions being available, even if the use cases in question are
>>> uncommon.
>>>
>>> So allow a secret handshake with the UEFI Shell, to set a variable that
>>> will result in both descriptions being exposed on the next boot, if
>>> executing in the default 'ACPI-only' mode.
>>>
>>>   setvar -nv -bs -guid 50bea1e5-a2c5-46e9-9b3a-59596516b00a ForceDt =01
>>>
>>> Contributed-under: TianoCore Contribution Agreement 1.0
>>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>>> ---
>>>  ArmVirtPkg/ArmVirtPkg.dec                                | 8 ++++++++
>>>  ArmVirtPkg/ArmVirtQemu.dsc                               | 3 +++
>>>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.c   | 7 ++++++-
>>>  ArmVirtPkg/PlatformHasAcpiDtDxe/PlatformHasAcpiDtDxe.inf | 5 +++++
>>>  4 files changed, 22 insertions(+), 1 deletion(-)
>>
>> Nacked-by: Laszlo Ersek <lersek@redhat.com>
>>
>> This will cause everyone *at all* to set the secret handshake, and we
>> will be back to square one, where everyone just exposes ACPI and DT at
>> the same time, and delegate the decision to the guest kernel.
>>
>> And then vendors will continue to ignore ACPI testing, and they will
>> continue shipping crap in their ACPI tables.
>>
>> We might as well rip out the recent patches that implement the mechanism
>> and the policy for the mutual exclusion.
>>
>> As Leif proved so eloquently (in the pub) in Budapest during Connect, no
>> OS needs both descriptions at the same time. Virt users can make up
>> their minds about what to expose. We (RH virt) had been worriedly
>> planning to make the same proposal to Leif, you, et al, and then we were
>> happy to see the violent agreement that ensued.
>>
>> Sorry for getting political, but the kernel's unwavering preference for
>> DT over ACPI is political, and the recent edk2 patches only exist to
>> rectify that, from the firmware side. Users don't lose DT. What they do
>> lose is the (harmful) freedom of not choosing one over the other. That
>> freedom has had a terrible effect on the quality of ACPI tables shipped
>> with *allegedly* SBBR-compliant hardware.
>>
>> Feel free to diverge from this in downstream distributions, but this
>> loophole has no place in upstream edk2.
>>
>> NACK
>>
> 
> OK, fair enough. How do you propose to handle this regression then?
> 

I don't.