On Wed, May 20, 2020 at 02:16:24PM +0200, Michal Privoznik wrote: > 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). FYI, the QEMU maintainers do not want to see applications using fw-cfg for general purpose data passthrough. This interface is primarily there for QEMU to communicate with the BIOS. There are a limited number of data slots available, so they're reasonably precious, and QEMU is using more over time. This is the key reason why I implemented support for "OEM Strings" feature in the QEMU. From POV of an application, this provides the same functionality as fw_cfg, but via SMBIOS data tables instead, so doesn't have the same limits as fw_cfg. This data can be queried using the "dmidecode" tool in the guest eg "dmidecode --oem-string count", and "dmidecode --oem-string NNN". You could just parse the raw SMBOIS table from sysfs instead and ignore "dmidecode" tool, but that's a bit more gross. Linux exposes some, but not all, SMBIOS fields in sysfs, but lacks OEM strings currently. I made a half-hearted attempt to add linux support for OEM strings in sysfs, but never completed it. > 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. I don't object to exposing fw_cfg in the XML, since there are existing users like Ignition that could benefit. I think we should be documenting that its usage is strongly discouraged though, in favour of OEM strings.

Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|

On Wed, May 20, 2020 at 01:24:36PM +0100, Daniel P. Berrangé wrote: > On Wed, May 20, 2020 at 02:16:24PM +0200, Michal Privoznik wrote: > > 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). > > FYI, the QEMU maintainers do not want to see applications using fw-cfg > for general purpose data passthrough. This interface is primarily there > for QEMU to communicate with the BIOS. There are a limited number of data > slots available, so they're reasonably precious, and QEMU is using more > over time. > > This is the key reason why I implemented support for "OEM Strings" feature > in the QEMU. From POV of an application, this provides the same functionality > as fw_cfg, but via SMBIOS data tables instead, so doesn't have the same > limits as fw_cfg. This data can be queried using the "dmidecode" tool in > the guest eg "dmidecode --oem-string count", and > "dmidecode --oem-string NNN". You could just parse the raw SMBOIS table > from sysfs instead and ignore "dmidecode" tool, but that's a bit more > gross. > > Linux exposes some, but not all, SMBIOS fields in sysfs, but lacks OEM > strings currently. I made a half-hearted attempt to add linux support > for OEM strings in sysfs, but never completed it. > > > 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. > > I don't object to exposing fw_cfg in the XML, since there are existing > users like Ignition that could benefit. I think we should be documenting > that its usage is strongly discouraged though, in favour of OEM strings. > For some other (albeit older) info: https://post-office.corp.redhat.com/mailman/private/virt-devel/2017-Febru... I also recall someone was thinking this could be usable for cloud-init data. If someone needs this, then it would be nice to provide some background and/or justification here: https://bugzilla.redhat.com/show_bug.cgi?id=1422831