On Sun, Nov 24, 2024 at 05:41:08PM +0000, Peter Maydell wrote: > On Sun, 24 Nov 2024 at 14:24, Anne Macedo <retpola...@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 :|
