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 <ard.biesheu...@linaro.org> wrote: >>> On 21 March 2017 at 02:27, Zeng, Star <star.z...@intel.com> 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 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
