From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 0EBA6803B1 for ; Wed, 22 Mar 2017 07:12:05 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id f84so65999082ioj.0 for ; Wed, 22 Mar 2017 07:12:05 -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=5HS9jrADhuu3la1e/YGcGiwXclSHtY5ygCceYPlB6aQ=; b=Tmg0Gp+d/nzCnIz2jhU1C8sQOpD3iZC7MqgUh5q82SJtE9vXWdub8I2w9yIdo4l3UQ 32XKQue+cAbpqrMC4nihX+NxXWu1ixC6V1BFqkAekoIsTgLeujO0wL8lwujpnUbNNSTC F6khTK4kanCVBz64bSGQa36llpM0b/4IPEnss= 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=5HS9jrADhuu3la1e/YGcGiwXclSHtY5ygCceYPlB6aQ=; b=QnXUY53IMheTL6My2A+D+dQbKlR3yq96qGPC7LDMhrjjjEpEvo4oyRLYlTnSfdg0OI 88nGJ6t/Ws1OfI3MaWKK4yuGMBFP58eMAAVAj4GJGiL1M30V/i9r+0It94NUmDu4duvK dUPSAwGaYFpq+qmz9s7jKZ1NzGXx3YeNmLFoRHV/rTTJAmz6y3Cqyzq3ToaujdGC0IYZ g6vDCW1FfHfYpYkOmbPnReQbUMDeRWNooBJ8Z0wVU6HxtqWk5TNI4/xBv4zM5/uEatnO 61hFzU5mW+SSY4qUt7HRtQa7ikWqqJeyxgY4UoZs/zFysmdPW/vCKfbnwgvjKRfxo2is R7mA== X-Gm-Message-State: AFeK/H0LPEHGfX6RHzjVEmm+Q6eq32QuHBK2APhEqCTQhnvT92Dz+P5kMRuQdJxzFj52KcWCgAJ6ebcENnQJftR7 X-Received: by 10.107.168.21 with SMTP id r21mr34656873ioe.45.1490191924361; Wed, 22 Mar 2017 07:12:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.27 with HTTP; Wed, 22 Mar 2017 07:12:03 -0700 (PDT) In-Reply-To: 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> From: Ard Biesheuvel Date: Wed, 22 Mar 2017 14:12:03 +0000 Message-ID: To: Laszlo Ersek Cc: "Zeng, Star" , "Kinney, Michael D" , edk2-devel-01 , "Yao, Jiewen" , Leif Lindholm 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: Wed, 22 Mar 2017 14:12:05 -0000 Content-Type: text/plain; charset=UTF-8 On 21 March 2017 at 18:00, Laszlo Ersek wrote: > 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? > I suppose, yes :-) I guess we will never have a perfect solution for this, and using library classes and protocol dependencies is much preferred over having to reason about when a dynamic PCD assumes its correct value.