From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 13EA4802AF for ; Thu, 9 Mar 2017 04:26:16 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id m27so68346296iti.0 for ; Thu, 09 Mar 2017 04:26:16 -0800 (PST) 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=si+4DsHaRquF+OzosCaF02+LdQCru3SU+DHrEn/w+vs=; b=Ey2HTgyP/x5br6nwWEk2QsmzmDbqQSqRnlVXY17UjX9MSTiFeushAvTOx3MLBQ21yy Bs8lqKznXuyHZP+wROUj5GaDHWqPOZ5JSTRQxFtnmwq85oE1/lbdIJIWHHITFm5O35xd 5nnd7NHthUVT34wgFPBJAupDTvhJ24lrsPmKM= 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=si+4DsHaRquF+OzosCaF02+LdQCru3SU+DHrEn/w+vs=; b=RgSFal1O2HPn/6ELVVZlUmyR+hevLH+78+BK2rJ9osriRYdJ6aQOFIjfWWojKdHhvt DbVksLAfR4cg36GkRIXjONoPR5w3IYn6zRW9bfFTKhJYeJ0dCuw7uvGVMIy1K5utCUhW 6jStNYqcNIObdhyVhPE6ZizA13RrKkhQg7YE5fxVWjAoRZ3u6L117QbFCKpdx+iTg2ds eIMt7aXKmjDrQjjD7NCi2rkrx4wvEboYr1lMzr7ehxG3/73c6ejmhZq2XcEAhUUizIh+ hmeD+wYtpdSaDv/3mGsEddQGJdwhbwv4+Un3I0qNgpcHrFEvBPp54gfh/K5bTIKFieZt KLhQ== X-Gm-Message-State: AMke39kZdouMjBuPcq0/tu07OYCNJAtJHC4Xt6+FWdRIqBeVSFlmpMG4jYMYrE1kIJ76GRLgH/Msf7OQ4TAiVCKO X-Received: by 10.36.137.4 with SMTP id s4mr29324207itd.63.1489062375327; Thu, 09 Mar 2017 04:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Thu, 9 Mar 2017 04:26:14 -0800 (PST) In-Reply-To: <2936c55e-ac00-6595-95a8-d8cfdbd83cb8@redhat.com> References: <20170308190511.31195-1-lersek@redhat.com> <2936c55e-ac00-6595-95a8-d8cfdbd83cb8@redhat.com> From: Ard Biesheuvel Date: Thu, 9 Mar 2017 13:26:14 +0100 Message-ID: To: Laszlo Ersek Cc: edk2-devel-01 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 12:26:16 -0000 Content-Type: text/plain; charset=UTF-8 On 9 March 2017 at 12:01, Laszlo Ersek wrote: > 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. > Or we could hook to the ReadyToBoot event in FdtClientDxe, and install the DT config table if there is no ACPI/ACPI2.0 table registered. > 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? > Building the same library in two different ways, having to call a library constructor explicitly in some cases and muck about with TPL levels to prevent a protocol notify from triggering are all things I would really like to avoid tbh