From patchwork Sat Mar 18 20:58:24 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ard Biesheuvel X-Patchwork-Id: 95448 Delivered-To: patch@linaro.org Received: by 10.140.89.233 with SMTP id v96csp325065qgd; Sat, 18 Mar 2017 13:58:43 -0700 (PDT) X-Received: by 10.99.149.9 with SMTP id p9mr22745025pgd.112.1489870723515; Sat, 18 Mar 2017 13:58:43 -0700 (PDT) Return-Path: Received: from ml01.01.org (ml01.01.org. [198.145.21.10]) by mx.google.com with ESMTPS id e39si12500579plg.309.2017.03.18.13.58.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Mar 2017 13:58:43 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) client-ip=198.145.21.10; Authentication-Results: mx.google.com; dkim=neutral (body hash did not verify) header.i=@linaro.org; spf=pass (google.com: best guess record for domain of edk2-devel-bounces@lists.01.org designates 198.145.21.10 as permitted sender) smtp.mailfrom=edk2-devel-bounces@lists.01.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from [127.0.0.1] (localhost [IPv6:::1]) by ml01.01.org (Postfix) with ESMTP id 9221E803BD; Sat, 18 Mar 2017 13:58:42 -0700 (PDT) X-Original-To: edk2-devel@lists.01.org Delivered-To: edk2-devel@lists.01.org Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 0A484803B3 for ; Sat, 18 Mar 2017 13:58:41 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id t189so38773651wmt.1 for ; Sat, 18 Mar 2017 13:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id; bh=+ps34SgAyNMzR23wec6HcKcCf9KfVrHgtsMGXFQ1LIk=; b=UhJQWXmcjTnL5RETSi0BQ5GPu0W/fJH6OSzJIWyOmrJcLGoSB4Yk6OeV+/mEq4FDjP rNUkNkW64e46JSdr3hzmJDoma//x40GA26FIZxXrv/gQUb0SHx2higplc7Omyn3qbjTm +lebygR1Bs+zPVqOToaWqwNDikVN5p5MSO3h8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=+ps34SgAyNMzR23wec6HcKcCf9KfVrHgtsMGXFQ1LIk=; b=azpLYX0+YL0mBQ2efsEWEba1VY/bBgCh1UpZDKVvDXd9ZkACb9V1lL+n8+Ej00O4Gc Pn+fqKdPjYq0RF7q76QHZ6gvAZ7nAz5uR/+Z+g+Og+3pfC+9tu4zaQ71ZiJkUuSh6XRE 6OB86ehTcPZpJ4SysWNBjWcXbHnw980HatBLnJTRemf+BcHARGrUIjdi3pjzBbTC5X0s mJPIk8Ip3Hi93go9MacVhd1oCfxvf9k2I+RSfcnw9n5OKnWZcr+gAKJDe34t95Dxo1C0 gUwH2sRvM69oYyfpyCqQJTFiRf0mLfKiJyyAgj7uYUC8JkQc68JF/k6vdUFdrH40t2xI DtjQ== X-Gm-Message-State: AFeK/H0wo8FIl2cz42sv1eFSlAfpu32J+GN9DQKWeOkN87Un6o0AJi7ZaC4NgHQFvNuSwn74 X-Received: by 10.28.18.73 with SMTP id 70mr3612637wms.41.1489870718807; Sat, 18 Mar 2017 13:58:38 -0700 (PDT) Received: from localhost.localdomain ([105.144.205.163]) by smtp.gmail.com with ESMTPSA id b199sm7475832wmb.13.2017.03.18.13.58.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 18 Mar 2017 13:58:38 -0700 (PDT) From: Ard Biesheuvel To: edk2-devel@lists.01.org, lersek@redhat.com, leif.lindholm@linaro.org, star.zeng@intel.com Date: Sat, 18 Mar 2017 20:58:24 +0000 Message-Id: <20170318205824.13326-1-ard.biesheuvel@linaro.org> X-Mailer: git-send-email 2.9.3 Subject: [edk2] [RFC PATCH] MdeModulePkg/AcpiTableDxe: inhibit table publication until we have a FADT 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: , Cc: feng.tian@intel.com, Ard Biesheuvel MIME-Version: 1.0 Errors-To: edk2-devel-bounces@lists.01.org Sender: "edk2-devel" Since commit 78c41ff519b1 ("ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent"), we inhibit the installation of the core ACPI tables when booting in DT mode, to relieve the OS from having to decide which hardware description to use. However, as it turns out, in presence of the RamdiskDxe or BGRT drivers, some ACPI tables are still registered with the protocol, and published under the ACPI entry point configuration tables, ignoring the fact that there is no way the OS can boot with only NFIT and BGRT tables present. So let's only publish the ACPI tables if we can reasonably assume that the tables that the OS requires have been registered with the protocol, by checking that we have either FADT1 or FADT3 table (or both) before installing the configuration tables. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Ard Biesheuvel --- This is a counterproposal for Laszlo's series [0], which is technically sound, but a bit unwieldy. Instead of making ARM the odd one out, and tweaking universal modules via NULL library class resolution, we can prevent AcpiTableDxe from publishing the entry points when only NFIT or BGRT tables are present (which sounds like a strange thing to do in any case) I am aware that this still leaves some loose ends when it comes to ordering and the ReadyToBoot callback, which I agree we should solve regardless, but I hope we can do so without putting the burden on the ARM platforms to always carry a set of NULL class libraries to keep sane behavior. [0] https://lists.01.org/pipermail/edk2-devel/2017-March/008684.html MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) -- 2.9.3 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel Signed-off-by: Ard Biesheuvel diff --git a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c index 4bb848df5203..4c9921f69a8a 100644 --- a/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c +++ b/MdeModulePkg/Universal/Acpi/AcpiTableDxe/AcpiTableProtocol.c @@ -130,6 +130,21 @@ PublishTables ( UINT64 Buffer64; // + // Don't publish anything yet if we don't have a FADT table. This table is + // mandatory for all ACPI compatible OSes, and installing the ACPI entry + // point configuration table without a full set of ACPI tables may confuse + // some OSes (Linux/arm64). (This may happen when the BGRT or ramdisk drivers + // publish their respective ACPI tables without regard for whether ACPI boot + // is currently enabled.) + // + if (AcpiTableInstance->Fadt1 == NULL && AcpiTableInstance->Fadt3 == NULL) { + DEBUG ((DEBUG_INFO, + "%a: not publishing ACPI tables [yet], no FADT table installed\n", + __FUNCTION__)); + return EFI_SUCCESS; + } + + // // Reorder tables as some operating systems don't seem to find the // FADT correctly if it is not in the first few entries //