[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#77110] [PATCH 1/2] gnu: ovmf-x86-64: Install QEMU firmware metadata
From: |
Maxim Cournoyer |
Subject: |
[bug#77110] [PATCH 1/2] gnu: ovmf-x86-64: Install QEMU firmware metadata file. |
Date: |
Thu, 20 Mar 2025 15:48:34 +0900 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Efraim,
Efraim Flashner <efraim@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).
[...]
>> 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).
> 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.
--
Thanks,
Maxim