[bug#77110,1/2] gnu: ovmf-x86-64: Install QEMU firmware metadata file.

  * gnu/packages/firmware.scm (ovmf-x86-64)
[phases] {install-qemu-firmware-metadata}: New phase.
(ovmf-aux-file): New procedure.
* gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json: New file.
* Makefile.am (AUX_FILES): Register it.

Change-Id: I301eac8b79aed523f3b4cdedb7b3925d8fd0ad3d
---

 Makefile.am                                   |  1 +
 .../ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json    | 36 +++++++++++++++++++
 gnu/packages/firmware.scm                     | 24 ++++++++++++-
 3 files changed, 60 insertions(+), 1 deletion(-)
 create mode 100644 gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json


base-commit: fa39695bbc0c5f79838cbca55d55eebd821a8efa
  

51-edk2-ovmf-2m-raw-x64-nosb.json is very similar to a file shipped by
qemu, in the sources in pc-bios/descriptors¹.

On Wed, Mar 19, 2025 at 09:45:12PM +0900, Maxim Cournoyer wrote:
> * gnu/packages/firmware.scm (ovmf-x86-64)
> [phases] {install-qemu-firmware-metadata}: New phase.
> (ovmf-aux-file): New procedure.
> * gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json: New file.
> * Makefile.am (AUX_FILES): Register it.
> 
> Change-Id: I301eac8b79aed523f3b4cdedb7b3925d8fd0ad3d
> ---
> 
>  Makefile.am                                   |  1 +
>  .../ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json    | 36 +++++++++++++++++++
>  gnu/packages/firmware.scm                     | 24 ++++++++++++-
>  3 files changed, 60 insertions(+), 1 deletion(-)
>  create mode 100644 gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json
> 
> diff --git a/Makefile.am b/Makefile.am
> index c668b96a37..f2f4a9643e 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -472,6 +472,7 @@ AUX_FILES =						\
>    gnu/packages/aux-files/linux-libre/5.4-arm64.conf	\
>    gnu/packages/aux-files/linux-libre/5.4-i686.conf	\
>    gnu/packages/aux-files/linux-libre/5.4-x86_64.conf	\
> +  gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json	\
>    gnu/packages/aux-files/pack-audit.c			\
>    gnu/packages/aux-files/python/sanity-check.py		\
>    gnu/packages/aux-files/python/sitecustomize.py	\
> diff --git a/gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json b/gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json
> new file mode 100644
> index 0000000000..050853e2b8
> --- /dev/null
> +++ b/gnu/packages/aux-files/ovmf/51-edk2-ovmf-2m-raw-x64-nosb.json
> @@ -0,0 +1,36 @@
> +{
> +    "description": "OVMF without SB+SMM, empty varstore",
> +    "interface-types": [
> +        "uefi"
> +    ],
> +    "mapping": {
> +        "device": "flash",
> +        "mode" : "split",
> +        "executable": {
> +            "filename": "/usr/share/edk2/ovmf/OVMF_CODE.fd",
> +            "format": "raw"
> +        },
> +        "nvram-template": {
> +            "filename": "/usr/share/edk2/ovmf/OVMF_VARS.fd",
> +            "format": "raw"
> +        }
> +    },
> +    "targets": [
> +        {
> +            "architecture": "x86_64",
> +            "machines": [
> +                "pc-i440fx-*",
> +                "pc-q35-*"
> +            ]
> +        }
> +    ],
> +    "features": [
> +        "acpi-s3",
> +        "amd-sev",
> +        "amd-sev-es",
> +        "verbose-dynamic"
> +    ],
> +    "tags": [
> +
> +    ]
> +}
> 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.

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.

> +              (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?

>  
>  (define-public ovmf-i686
>    (let ((base (make-ovmf-firmware "i686")))
> 
> base-commit: fa39695bbc0c5f79838cbca55d55eebd821a8efa
> -- 
> 2.48.1
> 

¹ https://gitlab.com/qemu-project/qemu/-/blob/v9.1.3/pc-bios/descriptors/60-edk2-x86_64.json
² https://gitlab.com/qemu-project/qemu/-/blob/v9.1.3/roms/edk2-build.config#L62
  

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.
  

On Thu, Mar 20, 2025 at 03:48:34PM +0900, Maxim Cournoyer wrote:
> 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).

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
  

Hi Efraim,

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

> On Thu, Mar 20, 2025 at 03:48:34PM +0900, Maxim Cournoyer wrote:
>> 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).
>
> 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).
  

Hi,

I've now applied this series, thank you for reviewing it!