GNU bug report logs - #77110
[PATCH 0/2] Add UEFI firmware support in libvirt.

Previous Next

Package: guix-patches;

Reported by: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Date: Wed, 19 Mar 2025 07:17:02 UTC

Severity: normal

Tags: patch

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #23 received at 77110 <at> debbugs.gnu.org (full text, mbox):

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: Vagrant Cascadian <vagrant <at> debian.org>, 77110 <at> debbugs.gnu.org
Subject: Re: [bug#77110] [PATCH 1/2] gnu: ovmf-x86-64: Install QEMU firmware
 metadata file.
Date: Thu, 20 Mar 2025 23:36:27 +0900
Hi Efraim,

Efraim Flashner <efraim <at> flashner.co.il> writes:

> On Thu, Mar 20, 2025 at 03:48:34PM +0900, Maxim Cournoyer wrote:
>> Hi Efraim,
>> 
>> Efraim Flashner <efraim <at> flashner.co.il> writes:
>> 
>> > 51-edk2-ovmf-2m-raw-x64-nosb.json is very similar to a file shipped by
>> > qemu, in the sources in pc-bios/descriptors¹.
>> 
>> Indeed, I found out the firmwares currently bundled with QEMU (see
>> bug#77092) come with firmware descriptors.  Are you suggesting we use
>> these instead?  I don't mind too much, except that's a lot of source to
>> unpack to grab a template file, which seems inefficient to me, and that
>> accessing source archives is a bit annoying currently in Guix (because
>> it may be a tarball, or a directory, or it may change if patches get
>> later added... but that's an issue for another time).
>
> It looks like they're also installed in $out/share/qemu/firmware.  At
> that point they have their paths pointing to qemu's location for the
> firmware, but we could change that at build time to point to firmware
> we've built or as part of a service to point to a different location.
>
> Reminding myself again that we're looking at the firmware itself, I
> think we shouldn't install a VM configuration file as part of the
> firmware.

That's what most distributions appears to do, for example Fedora [0],
and it makes sense to me.  QEMU itself should come without firmwares if
we want to keep its size in check, and it can't include the descriptor
files if it doesn't ship the firmware as the descriptor files reference
the file names (well, we could point to some place where they eventually
land, and have this provisioned by a service, but that's inelegant).

[0]  https://src.fedoraproject.org/rpms/edk2/blob/rawhide/f/edk2.spec#_569

[...]

>> Libvirt has no search path for that.  IIRC, it uses
>> $XDG_CONFIG_HOME/qemu/firmware if you run it as a simple user, and
>> otherwise /usr/share/qemu/firmware on FHS, with /etc/qemu/firmware as a
>> fallback to discover the firmware metadata files for QEMU.
>
> The libvirt service does have a qemu field. Perhaps we could make use of
> that somehow?

It's useful to have qemu a distinct field to firmwares; it points to the
qemu package/binary used by libvirt while firmwares allow you to specify
which firmware files are made available.  Note that since QEMU currently
bundles many firmwares with their descriptors, you can currently add
'qemu' to the list of firmwares and it'll make them available to libvirt
(though I wouldn't advertise this too much as the goal should be to move
them to their own distinct packages).

-- 
Thanks,
Maxim




This bug report was last modified 52 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.