On Wednesday, March 20, 2024 6:05 PM Gerd Hoffmann wrote:
>
> We don't need to read + cache all fw_cfg data. We only need to cache the
> entries which (a) must be measured, and (b) will not be measured in some
> other way.
>
I am afraid that it is difficult to determine which fw_cfg items
are need to be cached and measured, since there are some fw_cfg items are
optional with special qemu cmd.
Example :
fw_cfg item: opt/ovmf/X-PciMmio64Mb
depends on qemu command: "-fw_cfg name=opt/ovmf/X-PciMmio64Mb,string=N"
> The big entries I'm aware of are:
> (1) kernel for direct boot (no fw_cfg measurement needed, binary
> will be measured before launch).
> (2) ACPI tables (no fw_cfg measurement needed, acpi tables are
> measured when installed).
> (3) smbios tables (to be decided, could be handled similar to ACPI).
>
> Anything else where you have size concerns?
So far I don't find other big entries.
>
> > Further more this is not a lazy mode which means some fw_cfg data may
> > be read but it is not to be consumed later.
>
> The problem with lazy mode is that the measurement order is not fixed.
We'd better define what's the "fixed measurement order".
Think about such scenario:
There are 5 fw_cfg items ("A-B-C-D-E"), and C is an optional one which depends
on special qemu cmd
(example : etc/boot-menu-wait depends on qemu command: " -boot
menu=on,splash-time=N").
So, there are two measurement orders in different qemu command:
1, "A-B-C-D-E" (with qemu command "-boot menu=on,splash-time=N ")
2, "A-B-D-E" (without qemu command "-boot menu=on,splash-time=N ")
Is the "A-B-C-D-E" or "A-B-D-E" fixed order ?
What's your thoughts ?
>
> > We propose below solution :
> >
> > Add a new API in QemuFwCfgLib,
> > RETURN_STATUS QemuFwCfgGetData(fw_cfg_name, *size, *value,
> FW_CFG_GET_DATA_FLAG flag).
>
> I'd suggest to *not* touch the existing interfaces for reading entries.
> Instead change the existing functions to first check the cache, in case there
> is
> no cache entry go read from fw_cfg.
Actually we don't touch the existing interface for reading entries.
The API is newly added.
>
> Add a new interface for adding fw_cfg entries to the cache, with optional
> measurement.
Do you mean to add a new API (example : QemuFwCfgReadBytes2(*size, *buffer,
Flag))
with optional measurement to cache fw_cfg data?
>
> > And it can reduce the code complexity because it pack 3 fw_cfg call
> > (QemuFwCfgFindFile/QemuFwCfgSelectItem/QemuFwCfgReadBytes) into one
> call.
>
> There are a few places in the code which expect they can read fw_cfg files in
> multiple chunks (i.e. call QemuFwCfgReadBytes multiple times).
>
Actually we can handle the case with the new API.
For example, etc/e820 is read in chunks.
Current code like below:
QemuFwCfgSelectItem (FwCfgItem);
for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) {
QemuFwCfgReadBytes (sizeof E820Entry, &E820Entry);
Callback (&E820Entry, PlatformInfoHob);
}
We can update it like below:
QemuFwCfgGetData("etc/e820", &FwCfgSize, Buffer, Flag);
for (Processed = 0; Processed < FwCfgSize; Processed += sizeof E820Entry) {
EFI_E820_ENTRY64 *E820Entry = (EFI_E820_ENTRY64 *)(Buffer + Processed);
Callback (E820Entry, PlatformInfoHob);
}
> Also note that not all fw_cfg entries are (pseudo-)files.
I am not sure what you mean about (pseudo-)files.
Could you give some instructions?
Base on your comments, does this mean there are other fw_cfg data
which are read from QEMU via different method (not
QemuFwCfgFindFile/QemuFwCfgSelectItem/QemuFwCfgReadBytes) ?
If it is the case, could you please give an example?
Thanks
Ceping
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#116950): https://edk2.groups.io/g/devel/message/116950
Mute This Topic: https://groups.io/mt/104880546/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
