Exposing -fw_cfg?

[Martin Kletzander]

On Wed, May 20, 2020 at 02:39:25PM +0200, Martin Kletzander wrote:
>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
>

Sorry, I meant this, I had some other thing in the selection buffer.

http://post-office.corp.redhat.com/archives/rh-openstack-dev/2017-February/msg00325.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 :|
>>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200520/0ce040ba/attachment-0001.sig>