On 29 March 2017 at 17:00, Laszlo Ersek <[email protected]> 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 <[email protected]> >> --- >> 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 <[email protected]> > > 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? _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
