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

[Laszlo Ersek <lersek@redhat.com>]

On 03/29/17 18:16, Marc Zyngier wrote:
> On 29/03/17 17:03, Laszlo Ersek 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.
> 
> Well, we then have an issue here. As a user of QEMU+UEFI, I expect my
> existing VM images to continue to work (mostly because I'm trying to
> track regression in KVM itself). And some are pretty old (circa 4.2). I
> upgrade my "firmware" (which is QEMU+UEFI), and my VM doesn't boot
> anymore, because someone decided that ACPI was better for my soul.

I understand. In my opinion, this can be considered an advanced enough
use case that justifies rebuilding the firmware on your side. The same
way I rebuild both QEMU and (occasionally) the kernel when I try to
track down something related to, or exposed by, the guest firmware.

(
Case in point:

https://www.mail-archive.com/qemu-devel@nongnu.org/msg440255.html

To me it seems like a recent vhost regression in the host kernel, and
I'd already be bisecting the kernel if I had hardware in my home where
the issue reproduces. But, I digress; a team mate is doing that now.
)

> I'm sorry, but I don't think that's the right thing to do. If RH decides
> to mandate ACPI VMs, that's RH's call. You can eviscerate DT support
> from your build of QEMU and UEFI, and I'm fine with it. Imposing this on
> all users with existing setups is just wrong.

What is wrong is the *practical* effect of the freedom that ACPI+DT
together provide. It undermines SBBR conformance in the wild. If people
*can* not care, they *will* not care. And SBBR is not just an RH preference.

(Sorry about the over-use of bold -- I'm not excited, just trying to get
the emphases over the wire.)

> I appreciate you may not care, but I had to say it.

I appreciate that you said it!

Thanks,
Laszlo