GNU bug report logs -
#77110
[PATCH 0/2] Add UEFI firmware support in libvirt.
Previous Next
Full log
Message #20 received at 77110 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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.
> [...]
>
> >> diff --git a/gnu/packages/firmware.scm b/gnu/packages/firmware.scm
> >> index 63f767f72b..c1d8ba3719 100644
> >> --- a/gnu/packages/firmware.scm
> >> +++ b/gnu/packages/firmware.scm
> >> @@ -1001,6 +1001,10 @@ (define* (make-ovmf-firmware arch)
> >> (license (list license:expat
> >> license:bsd-2 license:bsd-3 license:bsd-4)))))
> >>
> >> +(define (ovmf-aux-file name)
> >> + "Return as a gexp the auxiliary OVMF file corresponding to NAME."
> >> + (local-file (search-auxiliary-file (string-append "ovmf/" name))))
> >> +
> >> (define-public ovmf-x86-64
> >> (let ((base (make-ovmf-firmware "x86_64")))
> >> (package
> >> @@ -1022,7 +1026,25 @@ (define-public ovmf-x86-64
> >> (string-append fmw "/" (string-downcase file) "_x64.bin")))
> >> (list "OVMF"
> >> "OVMF_CODE"
> >> - "OVMF_VARS"))))))))))))
> >> + "OVMF_VARS")))))
> >
> > These 3 files we rename from OVMF* to ovmf*_x64.bin, but based on
> > roms/edk2-build.config from the qemu sources² OVMF_CODE would become
> > edk2-x86_64-code.fd. I think we should standardize on using Qemu's
> > naming scheme for the files.
>
> I think we should go ever farther and standardize on *not* renaming them
> at all. This would remove the arbitrary nature of renaming them to
> something else that is bound to surprise users. On most distributions
> they are kept under their original names. The JSON firmware
> metadata/descriptors files can refer to any name anyway, so outside of
> following conventions, the name is not too important.
>
> But I'd prefer to keep this renaming business for another time, perhaps
> when I get to add more UEFI firmware variants (at which point it may be
> more efficient to build them all at once and split them in various
> outputs).
Sounds like a good idea.
> > Also we currently install these files to %output/share/firmware and
> > there are other files we install to %output/share/qemu and we should
> > probably standardize between them.
>
> The location of the files should match the prevalent convention, which I
> think is share/firmware. QEMU firmware metadata files on the other hand
> must be under share/qemu/firmware/, as this is where libvirt expects to
> find them (actually it won't because we aren't FHS, but that's where it
> would otherwise :-)).
>
> >> + (add-after 'install 'install-qemu-firmware-metadata
> >> + (lambda _
> >> + ;; The QEMU firmware metadata files are taken from the
> >> + ;; Fedora project (see:
> >> + ;; https://src.fedoraproject.org/rpms/edk2/tree/rawhide).
> >> + (let ((51-edk2-ovmf-2m-raw-x64-nosb.json-source
> >> + #$(ovmf-aux-file "51-edk2-ovmf-2m-raw-x64-nosb.json"))
> >> + (51-edk2-ovmf-2m-raw-x64-nosb.json-dest
> >> + (string-append #$output "/share/qemu/firmware/"
> >> + "51-edk2-ovmf-2m-raw-x64-nosb.json")))
> >> + (mkdir-p (dirname 51-edk2-ovmf-2m-raw-x64-nosb.json-dest))
> >> + (copy-file 51-edk2-ovmf-2m-raw-x64-nosb.json-source
> >> + 51-edk2-ovmf-2m-raw-x64-nosb.json-dest)
> >> + (substitute* 51-edk2-ovmf-2m-raw-x64-nosb.json-dest
> >> + (("/usr/share/edk2/ovmf/OVMF_(CODE|VARS).fd" _ kind)
> >> + (string-append
> >> + #$output "/share/firmware/ovmf_"
> >> + (string-downcase kind) "_x64.bin")))))))))))))
> >
> > Would it be possible to instead use the search-path to find the
> > firmwares or is that not really possible?
>
> 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?
> --
> Thanks,
> Maxim
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
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.