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 A7A8E8029B for ; Tue, 21 Mar 2017 11:00:33 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0820BBDD4; Tue, 21 Mar 2017 18:00:34 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0820BBDD4 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=lersek@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 0820BBDD4 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 52B1E7FB41; Tue, 21 Mar 2017 18:00:32 +0000 (UTC) To: Ard Biesheuvel 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> <1f0f0141-b367-fbe9-8190-9c99671937d8@redhat.com> Cc: "Zeng, Star" , "Kinney, Michael D" , edk2-devel-01 , "Yao, Jiewen" , Leif Lindholm From: Laszlo Ersek Message-ID: Date: Tue, 21 Mar 2017 19:00:30 +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: <1f0f0141-b367-fbe9-8190-9c99671937d8@redhat.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 21 Mar 2017 18:00:34 +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 18:00:33 -0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/21/17 10:02, Laszlo Ersek wrote: > 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). So... does that make this patch set (relatively) less "unwieldy" to you? Thanks, Laszlo