Exposing -fw_cfg?
Daniel P. Berrangé
berrange at redhat.com
Wed May 20 12:46:45 UTC 2020
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
>
> 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
I think this page shows the motivation:
https://coreos.com/os/docs/latest/booting-with-libvirt.html
They're telling people to use QEMU command line passthrough, which will
also need special handling for sVirt snce libvirt won't know about it.
<tangent>
....
BTW, it occurred to me that we should improve the QEMU passthrough to
deal with sVirt, eg
<qemu:commandline>
<qemu:arg value="-fw_cfg"/>
<qemu:arg value="name=opt/com.coreos/config,file=/var/lib/libvirt/container-linux/container-linux1/provision.ign"/>
<qemu:access path="/var/var/libvirt/container-lonux/container-linux1/provision.ign"/>
</qemu:commandline>
<qemu:permit/> would add the default read-write sVirt label but
could access an <seclabel> child element to override.
We could also have APIs to make monitor passthrough more viable
virDomainQemuPermitAccess(virDOmainPtr dom, const char *path, unsigned int flags)
virDomainQemuRevokeAccess(virDOmainPtr dom, const char *path, unsigned int flags)
</tangent>
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 :|
More information about the libvir-list
mailing list