Re: [PATCH v2 05/12] ArmPkg: introduce EDKII Platform Has ACPI Protocol, and plug-in library

[Laszlo Ersek <lersek@redhat.com>]

On 03/21/17 09:43, Ard Biesheuvel wrote:
> On 21 March 2017 at 07:10, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:
>> On 21 March 2017 at 02:27, Zeng, Star <star.zeng@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).

Thanks
Laszlo