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 <[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. > > 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/[email protected]/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 _______________________________________________ edk2-devel mailing list [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
