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

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

On 29 March 2017 at 17:03, Laszlo Ersek <lersek@redhat.com> wrote:
> 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.

I think I am entitled to a more constructive attitude from you. I
don't care about politics, but I do care about not breaking people's
workflows. So if you insist on getting on your high horse and throw
capitalized NACKs at me, you could at least *pretend* to care about
other users than *your* downstream, and come up with some alternative.