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 451EF80472 for ; Tue, 21 Mar 2017 02:02:52 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ABACB7E9DF; Tue, 21 Mar 2017 09:02:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com ABACB7E9DF Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com ABACB7E9DF Received: from lacos-laptop-7.usersys.redhat.com (ovpn-116-42.phx2.redhat.com [10.3.116.42]) by smtp.corp.redhat.com (Postfix) with ESMTP id 35425D0458; Tue, 21 Mar 2017 09:02:51 +0000 (UTC) To: Ard Biesheuvel , "Zeng, Star" References: <20170317204731.31488-1-lersek@redhat.com> <20170317204731.31488-6-lersek@redhat.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B835B4B@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B8360CA@shsmsx102.ccr.corp.intel.com> <0C09AFA07DD0434D9E2A0C6AEB0483103B836569@shsmsx102.ccr.corp.intel.com> Cc: edk2-devel-01 , "Kinney, Michael D" , "Yao, Jiewen" , Leif Lindholm From: Laszlo Ersek Message-ID: <1f0f0141-b367-fbe9-8190-9c99671937d8@redhat.com> Date: Tue, 21 Mar 2017 10:02:49 +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.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 21 Mar 2017 09:02:52 +0000 (UTC) Subject: Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library 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: Tue, 21 Mar 2017 09:02:52 -0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 03/21/17 09:43, Ard Biesheuvel wrote: > On 21 March 2017 at 07:10, Ard Biesheuvel wrote: >> On 21 March 2017 at 02:27, Zeng, Star wrote: >>> Just an idea. >>> >> >> I like it! >> >>> There is a way to do not introduce a new PCD, but reuse PcdAcpiExposedTableVersions. >>> When PcdAcpiExposedTableVersions is configured to *0* (means no ANY ACPI table should be exposed), AcpiTableDxe returns EFI_UNSUPPORTED in the driver entrypoint. >>> >> >> So could we then upgrade the definition so it is possible to use a >> dynamic PCD for this? >> > > Oh, and how is the ordering ensured in this case? We need to set the > dynamic PCD at runtime, but obviously before AcpiTableDxe gets a > chance to load. If the only way to achieve this is another NULL class > library, then this is not much of an improvement. I've been silently waiting for this to get noticed :) In the ArmVirtQemu case, the PCD value would be set from fw_cfg. But in ArmVirtQemu, fw_cfg is not available in PEI, only in DXE, so yes, a NULL class library would be needed. In physical firmware (also in the planned "showcase QEMU" case), the toggle would be exposed by another DXE driver (a platform driver) using an HII form. Generally such a driver translates an nvvar to a PcdSet in its entry point, plus registers HII stuff that allows the nvvar to be toggled interactively in the setup browser, for the next boot. Either way, the PcdSet would again only happen in DXE. > Or could we detect > the table-loader node from PEI as well? Not at the moment; fw_cfg is currently not available in PEI, in ArmVirtQemu. ArmVirtQemu's PEI phase executes in-place from pflash. That means no writeable global variables (unless you make a PEIM, or the PEI library instance, dependent on the "memory discovered" PPI). Even using just the MMIO (no DMA) interface to fw_cfg, you'd have to parse the DTB on every invocation. (No writeable global variables imply you can't pre-parse the stuff in the library constructor.) A similar example is "ArmVirtPkg/Library/FdtPL011SerialPortLib/EarlyFdtPL011SerialPortLib.c", where each serial port write has to re-parse the base address from the DT. (OVMF is different because OVMF's PEI runs from memory.) So, whatever you saved on the PcdSet ordering in the DXE phase, you would triply lose in fw_cfg complexity in PEI. A new PEI library instance would be necessary for fw_cfg, which would either have to parse the DT on each invocation, or else depend on permanent PEI RAM availability (which would be the same (or worse) kind of ordering restriction that you're trying to avoid in DXE in the first place). Thanks Laszlo