From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id 298D92050AAE1 for ; Wed, 29 Mar 2017 09:04:03 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 92413C01C787; Wed, 29 Mar 2017 16:04:02 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 92413C01C787 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 92413C01C787 Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-134.phx2.redhat.com [10.3.116.134]) by smtp.corp.redhat.com (Postfix) with ESMTP id DFA8A84702; Wed, 29 Mar 2017 16:03:59 +0000 (UTC) To: Ard Biesheuvel References: <20170329151940.23397-1-ard.biesheuvel@linaro.org> Cc: "edk2-devel@lists.01.org" , Marc Zyngier , Jon Masters , Drew Jones From: Laszlo Ersek Message-ID: <4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com> Date: Wed, 29 Mar 2017 18:03:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Wed, 29 Mar 2017 16:04:02 +0000 (UTC) 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:04:03 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/29/17 18:02, Ard Biesheuvel wrote: > 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? > I don't.