List,
QEMU has capability to inject various blobs into firmware that configure
how firmware configures itself. However, it can be also used to
passthrough a specific file into the guest. For instance:
-fw_cfg value=name=opt/com.example,file=/tmp/ign
will make the /tmp/ign file accessible in the guest under:
/sys/firmware/qemu_fw_cfg/by_name/opt/com.example/raw
the @name is important here as it defines what knob is touched. For
instance, /opt/ovmf tweaks OVMF, /bootorder changes the boot order, and
so on. But, if the @name is in /opt/reverse.fully.qualified.domain form
than this is a blob that is exposed into the guest and does not affect
ACPI, SMBIOS, ... And IMO this is what makes the interface horrible.
While I definitely would not expose the FW configuration knobs (we
already provide a way to configure things like bootroder), the file
passthrough is actually used. So far I have found out that RHCOS uses it
to give the guest so called ignition file (for the sake of argument we
can assume it's like a kickstart that the OS reads on the first boot and
configures itself up), but there are some other potential users (for
users it looks intriguing, it's a simple API that makes a file show up
at well defined location inside the guest).
Therefore I vouch for exposing the file passthorugh (and definitely do
not mention firmware in the element or docs in any way, to not encourage
users to use FW tweaking mode). However, before I design something, I'd
like to hear your opinion.
Michal
