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 99C4780283 for ; Thu, 9 Mar 2017 03:01:13 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 07F56C057FAC; Thu, 9 Mar 2017 11:01:14 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-67.phx2.redhat.com [10.3.116.67]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v29B1Car002693; Thu, 9 Mar 2017 06:01:13 -0500 To: Ard Biesheuvel References: <20170308190511.31195-1-lersek@redhat.com> Cc: edk2-devel-01 From: Laszlo Ersek Message-ID: <2936c55e-ac00-6595-95a8-d8cfdbd83cb8@redhat.com> Date: Thu, 9 Mar 2017 12:01:11 +0100 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.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Thu, 09 Mar 2017 11:01:14 +0000 (UTC) Subject: Re: [PATCH 0/6] ArmVirtPkg: don't forward the DT to the OS if QEMU provides ACPI X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 11:01:13 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/09/17 09:16, Ard Biesheuvel wrote: > On 8 March 2017 at 20:05, Laszlo Ersek wrote: >> This series replaces the PURE_ACPI_BOOT_ENABLE build option with dynamic >> behavior, matching QEMU's (inverse sense) "-no-acpi" switch. In >> particular, DT and ACPI are no longer exposed to the guest at the same >> time. (DT is exposed with "-no-acpi", or else ACPI is exposed without >> "-no-acpi".) >> >> Repo: https://github.com/lersek/edk2.git >> Branch: dynamic_pure_acpi >> RHBZ: https://bugzilla.redhat.com/show_bug.cgi?id=1430262 >> >> Tested with RHEL-7.3 for ARM and Fedora 24 guests (DT vs. ACPI). >> >> Cc: Ard Biesheuvel >> > > Hi Laszlo, > > This looks complicated to me. Given that it is arguably a policy to > only expose on h/w description or the other, couldn't we simply remove > the FDT config table in BDS if an ACPI/ACPI2.0 config table is > present? Technically we could do that, but I dislike it for two reasons: - BDS is often the first victim found when looking for a driver to add new code to that doesn't seem to fit very well elsewhere. That doesn't make BDS any better a recipient, however. "For lack of a better driver" is not a strong enough argument to dump code into BDS. If there's really no better "topical" driver, then the code usually goes to PlatformDxe. - Installing a sysconfig table (or any other system-wide resource) in one driver, then undoing it in another driver, should be avoided as much as possible, because it leads to non-trivial lifecycles and boggles our minds over the longer term. If we can come to a decision that the table shouldn't be installed in the first place, we should pursue that. Another approach we could look into is: move the installation of the sysconfig table from FdtClientDxe to AcpiPlatformDxe. Look for the ACPI payload first, and fall back to installing DT (from within AcpiPlatformDxe). However, DT should be installed even in builds (like ARM32) that don't contain AcpiPlatformDxe at all. This series indeed turned out a bit more complex than I had expected, but it was the one I could post with a good conscience. Can you perhaps identify the part(s) in more detail that seem overly complex to you? Thanks, Laszlo