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-February/msg00278.html 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
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 :|
Attachment:
signature.asc
Description: PGP signature
