From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 36E60208F7A5B for ; Wed, 29 Mar 2017 10:07:48 -0700 (PDT) Received: by mail-it0-x231.google.com with SMTP id e75so97640884itd.1 for ; Wed, 29 Mar 2017 10:07:48 -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=z+0QOlJPpROl8YyNdXHKp9T6tITavvksRaN3i+FpvcU=; b=QoRZe56FmEd7l9agQ/oIYVJgfejsVnRV8wWT22Kfu19bP58gf1kTF64Y/dGHCzVn1p Gna/IZudm2G47IWI3MKBO5jEJ4tE0XYQ7qRxDz40M7tbycl0Dal4V9Nh40tMFuc7YHet idwo5QI13B0otfTt9Fpr98Etb4uCm62S7ONac= 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=z+0QOlJPpROl8YyNdXHKp9T6tITavvksRaN3i+FpvcU=; b=dl2vU8/CnFP16+ct39UzmLqq+QoDW8fHSmhqGNBjJC1B+BEJL3d7i2uEbFs2vuUZL7 NrN+q3oIVRwwgAyBTUs/mR600AVmBF8JVNbeAM7Lt5TAfaG6xfxujkQlWcYzc4bQvD4j kxW6tMq1tyCSNWEnpnkE6t4Hj+yVXnZf1nNjANpszdVvT2CandCaplCxqTkmUyMVZ4cS hBr5GNk2xwa5lyOS8CcVTG6soaCY5CnIy8CXbckJqVBiX3NWUXlFQfICBkP4TcTTIDzc i9m/o9gt886X4F06K/T68j+P6ywTQ5AgcSrQ7dKGpW0YxvFOQhGUDufdrTQLfsNAsHw8 brDg== X-Gm-Message-State: AFeK/H3r27onVGfy437ndssgYOnxBC0f5LtwzdI87UVfD4n5D1YUlEQ0ZMsmgA+vtf25+mtvaDFugk98TEKNcne1 X-Received: by 10.36.207.212 with SMTP id y203mr1834125itf.63.1490807267357; Wed, 29 Mar 2017 10:07:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Wed, 29 Mar 2017 10:07:46 -0700 (PDT) In-Reply-To: <2fb8acda-2786-e3de-e035-32d13e3f5868@arm.com> References: <20170329151940.23397-1-ard.biesheuvel@linaro.org> <4bdde09a-cf2e-33fb-967e-97e69e5be892@redhat.com> <2fb8acda-2786-e3de-e035-32d13e3f5868@arm.com> From: Ard Biesheuvel Date: Wed, 29 Mar 2017 18:07:46 +0100 Message-ID: To: Marc Zyngier Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , 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 17:07:48 -0000 Content-Type: text/plain; charset=UTF-8 On 29 March 2017 at 18: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. > So to clarify, you want something sticky in the firmware settings rather than having to use the -no-acpi command line argument to 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 > DT is always available, so this condenses to > - PreferDT==0 and ACPI+DT present -> ACPI > - PreferDT==1 and ACPI+DT present -> DT unless -no-acpi is set, which gives us > - PreferDT==0 and DT present -> DT > - 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). > For symmetry, it would make sense to call it ForceNoAcpi then, after the command line param. > Could people agree on something like this? > Works for me.