On 03/29/17 18:02, Ard Biesheuvel wrote: > 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? >
I don't. _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
