From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 A0F4E803B0 for ; Mon, 13 Mar 2017 03:23:46 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m27so25960140iti.0 for ; Mon, 13 Mar 2017 03:23:46 -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=7ygZa6sTip1f48VOHZPXWQHX5A+jzbf865N5E7aa480=; b=UqNPBex8NCLm24Ax0ybx81/9dHBZeEZu7rP+XbkIpMMzlJikB/it/SB+tpiuxGSFsc aJO1T7o3cUu+N4qiTtvPasMpZDYQtJlpzpF5tIhBvaDF8C1V8UU93cLWloCuQE33kyo7 bNz/diecKYwARUJ3mLNSWghsepjDYPFZGDhgc= 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=7ygZa6sTip1f48VOHZPXWQHX5A+jzbf865N5E7aa480=; b=rbHK1CVG5jvFBsC3xq2D7D1BrO9vrEP0pqGJfISKp6qw1gK6KrZO2n7ItiMgLONAet Ec11qAEh2LEIW7qPgffFw19fB2/PE/5912HoxudkGpzIORtdKMqI7+GKkH39T2SjNAlK wdbFL3pkH09ey+3albKEWA16HRjibbGHxbyyj+SVyeWILhssflA8oLR7Aumm0hypox9I vf3VwU57xTJ1Vg1nC5lQR6VpuW1X0Nqri12U3/497ODmhf1Oe3uLCetkJh/DRUxjxzbj 2qqWf4MI5Yp2ViFbmqNlza+d1mxCB5KPoyySyGHXLkfyOZ3Vcwpi+egnnNqvpGCj97QM dxHg== X-Gm-Message-State: AFeK/H0Fo0Imo9KJ7bkp+ruB/E1T6VorGlbH+gW/bjNUW+vJJa+GGCCAUaO0dWEVdxySm7fcNJiZ3NgOdbnDFt5x X-Received: by 10.36.169.69 with SMTP id x5mr9187678iti.37.1489400625899; Mon, 13 Mar 2017 03:23:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Mon, 13 Mar 2017 03:23:45 -0700 (PDT) In-Reply-To: <20170311102640.GK16034@bivouac.eciton.net> References: <1489075441-23745-1-git-send-email-ard.biesheuvel@linaro.org> <1489075441-23745-4-git-send-email-ard.biesheuvel@linaro.org> <19f70c3d-4220-957b-24cd-bd2d41e45909@redhat.com> <5bdc3cc1-b292-8da3-f858-83c752016941@redhat.com> <20170311102640.GK16034@bivouac.eciton.net> From: Ard Biesheuvel Date: Mon, 13 Mar 2017 10:23:45 +0000 Message-ID: To: Leif Lindholm Cc: Laszlo Ersek , "edk2-devel@lists.01.org" , Andrew Jones Subject: Re: [PATCH 3/3] ArmVirtPkg/FdtClientDxe: make DT table installation !ACPI dependent 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: Mon, 13 Mar 2017 10:23:46 -0000 Content-Type: text/plain; charset=UTF-8 On 11 March 2017 at 10:26, Leif Lindholm wrote: > On Sat, Mar 11, 2017 at 08:38:19AM +0100, Laszlo Ersek wrote: >> >> "MdeModulePkg/Universal/Acpi/S3SaveStateDxe/AcpiS3ContextSave.c". I >> >> think the above check should be reworked to look for the FADT >> >> (EFI_ACPI_2_0_FIXED_ACPI_DESCRIPTION_TABLE_SIGNATURE) with code lifted >> >> from these helper functions. No driver outside of >> >> QemuFwCfgAcpiPlatformDxe will install the FADT. And, the FADT will >> >> always be part of QEMU's ACPI payload, if it generates one. >> > >> > OK, that would get things working again, I suppose. But do we want >> > neutered ACPI tables to be exposed at all, even if there is a DT in >> > that case to boot from? >> >> I think the neutered ACPI tables (on -no-acpi) should be fine. The >> upstream Linux guest will prefer DT if it is present; > > Yes, but we've already determined that this situation is suboptimal, > which was what triggered this changeset to begin with. > Indeed. Having an ACPI entry point config table installed, but not having the essential tables that allow you to boot is a situation that we should try very hard to avoid IMO