Re: Exposing -fw_cfg?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux