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 A052720D2C3B9 for ; Wed, 29 Mar 2017 10:03:57 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 14B19A3B53; Wed, 29 Mar 2017 17:03:57 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 14B19A3B53 Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 14B19A3B53 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 85BDB7D9FC; Wed, 29 Mar 2017 17:03:54 +0000 (UTC) To: Marc Zyngier , Ard Biesheuvel References: <20170329151940.23397-1-ard.biesheuvel@linaro.org> <4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com> Cc: "edk2-devel@lists.01.org" , Jon Masters , Drew Jones From: Laszlo Ersek Message-ID: <9ec74bb8-f545-4ec2-ce2b-0f12bd7ffafe@redhat.com> Date: Wed, 29 Mar 2017 19:03:53 +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.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Wed, 29 Mar 2017 17:03:57 +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 17:03:57 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 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 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. > > 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/qemu-devel@nongnu.org/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