* Onboarding QEMU Firmware Configuration to other machines
@ 2024-11-24 14:22 Anne Macedo
2024-11-24 17:41 ` Peter Maydell
0 siblings, 1 reply; 3+ messages in thread
From: Anne Macedo @ 2024-11-24 14:22 UTC (permalink / raw)
To: qemu-devel
Hello!
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?
Thanks!
Anne
[1] https://github.com/systemd/mkosi/blob/6c33859a1b445e0bff19d9e7f28158140893a3e4/mkosi/config.py#L456
[2] https://gitlab.com/qemu-project/qemu/-/issues/2695
[3] https://gitlab.com/retpolanne/qemu/-/commit/86fca16555385c3685b7a1489a9cfaa255e148cf
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Onboarding QEMU Firmware Configuration to other machines
2024-11-24 14:22 Onboarding QEMU Firmware Configuration to other machines Anne Macedo
@ 2024-11-24 17:41 ` Peter Maydell
2024-11-25 9:47 ` Daniel P. Berrangé
0 siblings, 1 reply; 3+ messages in thread
From: Peter Maydell @ 2024-11-24 17:41 UTC (permalink / raw)
To: Anne Macedo; +Cc: qemu-devel
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.
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).
thanks
-- PMM
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Onboarding QEMU Firmware Configuration to other machines
2024-11-24 17:41 ` Peter Maydell
@ 2024-11-25 9:47 ` Daniel P. Berrangé
0 siblings, 0 replies; 3+ messages in thread
From: Daniel P. Berrangé @ 2024-11-25 9:47 UTC (permalink / raw)
To: Peter Maydell; +Cc: Anne Macedo, qemu-devel
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 :|
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2024-11-25 9:48 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-24 14:22 Onboarding QEMU Firmware Configuration to other machines Anne Macedo
2024-11-24 17:41 ` Peter Maydell
2024-11-25 9:47 ` Daniel P. Berrangé
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.