Re: Onboarding QEMU Firmware Configuration to other machines

["Daniel P. Berrangé" <berrange@redhat.com>]

On Sun, Nov 24, 2024 at 05:41:08PM +0000, Peter Maydell wrote:
> On Sun, 24 Nov 2024 at 14:24, Anne Macedo <retpolanne@posteo.net> wrote:
> > How should one port fw_cfg to other QEMU machines?
> >
> > Context:
> >
> > - I found a possible bug on the Debian builds for Raspberry Pi 4 that is
> >   only triggered when I try to launch it on QEMU;
> >
> > - I wrote an issue on systemd (I thought it had something to do with
> >   logind) and they requested me to only fill bugs if they show up on the
> >   upstream.
> >
> > - I tried baking systemd with mkosi – however, to test with mkosi and
> >   qemu, it uses fw_cfg [1] which seems specific to the virt machine on
> >   ARM.
> >
> > - Opened an issue [2] and started working on that [3]
> >
> > However, I still don't understand exactly how fw_cfg works. My current
> > understanding is that it is a device that, when connected some memory
> > mapping will happen on the guest so that it can access this memmap.
> >
> > TL;DR which steps should I take to onboard fw_cfg to machines such as
> > raspi4b?
> 
> fw_cfg is a device that is intended for setups where the guest
> knows it is running as a virtual machine. It provides a way
> for the guest to ask for e.g. particular files like a kernel
> for direct kernel boot, among other things. It's present on
> the Arm "virt" machine and on the x86 PC machine.
> 
> It doesn't and should not exist on the raspi4b model, because
> almost all QEMU machine types are supposed to model the real
> hardware, which doesn't have a fw_cfg.

To expand on this, by chance fw_cfg is visible to the guest OS, and thus
apps developers have (mis-)used this as a way to config data to the OS.
This should *not* be relied upon to work everywhere/anywhere. Adding it
to other targets / machines for general purpose application usage is a
non-goal for QEMU.

> I'm not sure exactly what mkosi is or does, but if it's supposed to be
> able to produce images that work with the raspberry pi then
> it needs to not require fw_cfg to exist (because on a real
> rpi it doesn't).

mkosi is a simple python tool for creating virtual disk images aka acronym
"MaKe Operating System Image".

What they need is a way to pass configuration metadata into the guest.

They already support a range of options, in order of preference looking
for SMBIOS (OEM strings),  fw_cfg, kernel command line:

  https://github.com/systemd/mkosi/blob/6c33859a1b445e0bff19d9e7f28158140893a3e4/mkosi/qemu.py#L1336

If none of those 3 options are viable, then a further option is to create
a virtual disk image containing a JSON file of the data needed and pass
that in. There are other options available too, virtiofs, 9p, usb-mtp,
virtio-serial, virtio-sock, all of which provide a ways to communicate
with the guest OS, with varying pros & cons. It is upto mkosi devs to
decide which best serve their needs, if they think their current 3 options
are insufficient.

With 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 :|