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

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

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?