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 3CE442050AAF6 for ; Wed, 29 Mar 2017 11:04:45 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A96622EF188; Wed, 29 Mar 2017 18:04:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com A96622EF188 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com A96622EF188 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 2DE21173A2; Wed, 29 Mar 2017 18:04:42 +0000 (UTC) To: Marc Zyngier , Ard Biesheuvel References: <20170329151940.23397-1-ard.biesheuvel@linaro.org> <4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com> <2fb8acda-2786-e3de-e035-32d13e3f5868@arm.com> <010325b6-1c23-5da7-9df5-337619c519bb@arm.com> Cc: "edk2-devel@lists.01.org" , Jon Masters , Drew Jones From: Laszlo Ersek Message-ID: Date: Wed, 29 Mar 2017 20:04:42 +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: <010325b6-1c23-5da7-9df5-337619c519bb@arm.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 29 Mar 2017 18:04:44 +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 18:04:45 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/29/17 19:30, Marc Zyngier wrote: > On 29/03/17 18:15, Laszlo Ersek wrote: >> On 03/29/17 19:01, Marc Zyngier wrote: >>> On 29/03/17 17:40, Laszlo Ersek wrote: >>>> On 03/29/17 18:07, Ard Biesheuvel wrote: >>>>> On 29 March 2017 at 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(-) >>>>>>>> >>> >>> [snip the policy argumentation, I only care about the technical aspects] >>> >>>> On the technical side: >>>> >>>> - I think a dynamic boolean PCD would be superior, if that is possible >>>> with HII (= directly nvvar-backed) PCDs -- absence of the variable >>>> should map to FALSE. I'm unsure though if that were as easy to set from >>>> the UEFI shell as a UINT8. So stick with the current data type if you >>>> deem that superior (maybe comment on it in the commit message). >>>> >>>> - please include in the C source, to reflect the >>>> [LibraryClasses] update in the INF. >>> >>> My personal choice would be *not* to expose both tables at the same >>> time, but instead to be able to shift the preference from one side or >>> the other, similarly to what a menu on a bare metal system would do. >> >> Umm... Are we in violent agreement? This works already. >> >> If you invoke QEMU with the normal command like, like you've always >> done, you get ACPI only (right now). >> >> If you pass the "-no-acpi" switch in addition to your normal command >> line, you get DT only. This is documented in detail on the following commit: >> >> https://github.com/tianocore/edk2/commit/110316a995ed >> >> If you pass -no-acpi on your QEMU command line, you can perform the >> whole guest kernel bisection using purely DT, without ever having to >> re-launch QEMU. >> >>> >>> Lets call the variable PreferDT (rather than ForceDT), with the >>> following (exhaustive) behaviour : >>> >>> - PreferDT==0 and ACPI+DT present -> ACPI >>> - PreferDT==0 and ACPI present -> ACPI >>> - PreferDT==0 and DT present -> DT >>> - PreferDT==1 and ACPI+DT present -> DT >>> - PreferDT==1 and ACPI present -> ACPI >>> - PreferDT==1 and DT present -> DT >>> >>> It allows people with existing setups to still have something that works >>> with minimal effort (still need to set this variable though). >>> >>> Could people agree on something like this? >> >> It's overly complex. With QEMU (and the current edk2 master state) you >> already have a single (host-side) master knob for controlling the ACPI >> vs. DT exposure. > > You're missing the essential bit. I don't want a knob in QEMU. Having to > mess with QEMU means that I can't have a uniform way of running a VM. I > want one way of booting a VM, and let the VM pick the description it has > been configured for. > > On bare metal, I can switch UEFI from a menu entry to pick ACPI or DT. > And that's good. I want the same freedom in a VM, at the same level. > There is no technical reason to have a different behaviour. Correct, you can have the exact same menu entry (which is what I've been calling the HII checkbox) in virtual firmware, assuming someone writes the platform DXE driver that implements this kind of policy. As I wrote, I expected Ard to submit (at some undeterminate time in the future) such a driver, which would replace the current policy drivers in: - the Xen build of ArmVirtQemu, which has no access to fw_cfg, and - the upcoming "showcase QEMU" platform, which would entirely ignore fw_cfg for this purpose. Laszlo