From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 77F6C20D2C3B9 for ; Wed, 29 Mar 2017 09:02:07 -0700 (PDT) Received: by mail-it0-x22e.google.com with SMTP id 68so3991111itx.0 for ; Wed, 29 Mar 2017 09:02:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DNhhm0nIUmDJd9xFha1Fic+zeBtbMmXRebYD36W55rA=; b=Ccvg7ps3/PRDc+vqywQU0kGu+qDPA1CsuOhWznLrwfryP4ZIcHH8eVRdwCu8Bw0xhK OnKCx/XEmVm4Jh6bN2z2846sT1EN3oi6whgUeH6aCD7mwKeVVXEbpdbR7JJwKjsNJ/u3 BZyvwyaAsWOXpQRcj8veaFlh6+Be9r3u4UfGk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DNhhm0nIUmDJd9xFha1Fic+zeBtbMmXRebYD36W55rA=; b=XQ4hvVNhXy6iZqATKwiM6QMmwabFuZ8lXLDaoO0TFATklWNu3z9hQyKXYu2hhWzPyi +eigebC8NLdsTNJHKlNe3rA9HnjqMWw/F5gN12cfEyYc1X9nRUNinPMaBD30NqBHgV9z 56kC0HM0zfuLOITtqViwMwuWY5lfYEQM9hRxxYeni2UvxLmMhtC+k4A6vBYDjRd/FsUg JrAWBTo9319+DbegqaCF0cIwHiIHZ/TEsxeVyGONlwxWHdMGiJF8oZvVYvrVINTERmYv BLhcNwHmJegQLlPLEmKkH2s6BKhKFk2orXfnXsIP0vUPtKIhMIHN2GTDRe1k1wxFx+5Z bqyA== X-Gm-Message-State: AFeK/H1zQAKejmdry/UeolK6saD7fhxdhFbRCECREE3UKXlFaXQ7H/48LkMVBPJiFhGHP4z1DI6I0j1pPpw/izVs X-Received: by 10.36.23.74 with SMTP id 71mr1855663ith.37.1490803326713; Wed, 29 Mar 2017 09:02:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Wed, 29 Mar 2017 09:02:06 -0700 (PDT) In-Reply-To: References: <20170329151940.23397-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Wed, 29 Mar 2017 17:02:06 +0100 Message-ID: To: Laszlo Ersek Cc: "edk2-devel@lists.01.org" , Marc Zyngier , Jon Masters , Drew Jones Subject: Re: [PATCH] ArmVirtPkg/PlatformHasAcpiDtDxe: allow manual override for DT installation X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 16:02:07 -0000 Content-Type: text/plain; charset=UTF-8 On 29 March 2017 at 17:00, Laszlo Ersek 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 >> --- >> 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 > > 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?