Commit Graph

5 Commits

Author SHA1 Message Date
Andrea Bolognani
a97c56888c tests: Update firmware descriptor files
These are imported from Fedora 38's edk2 package.

The files that are being replaced date back to RHEL 7 and no
longer represent what libvirt is likely to encounter on an
actual production system.

Notably, the paths have all changed, with both x86_64 and
aarch64 builds now living under /usr/share/edk2 and the AAVMF
name being having been phased out.

Additionally, the 4MB qcow2 format builds have been introduced
on x86_64 and given high priority, effectively making qcow2
the default format across architectures.

The impact of these changes on the test suite is, predictably,
quite severe.

For the cases where paths to firmware files were explicitly
provided as part of the input, they have been adjusted so that
the modern paths are used instead of the legacy ones. Other
than that, input files have been left untouched.

The following expected changes can be seen in output files:

  * where qcow2 firmware was used on x86_64, Secure Boot
    support is now enabled;

  * all ABI_UPDATE test cases for x86_64 now use qcow2
    formatted firmware;

  * test cases where legacy paths were manually provided
    no longer get additional information about the firmware
    added to the output XML.

Some of the changes described above highlight why, in order
to guarantee a stable guest ABI over time and regardless of
changes to the host's configuration, it was necessary to move
firmware selection from VM startup time to VM creation time.

In a few cases, updating the firmware descriptors changes the
behavior in a way that's undesired and uncovers latent bugs
in libvirt:

  * firmware-manual-efi-secboot-legacy-paths ends up with
    Secure Boot disabled, despite the input XML specifically
    requesting it to be enabled;

  * firmware-manual-efi-rw-modern-paths loses the
    loader.readonly=no part of the configuration and starts
    using an NVRAM file;

  * firmware-manual-efi-nvram-template-nonstandard starts
    failing altogether with a fairly obscure error message.

We're going to address all these issues with upcoming changes.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-08-21 13:51:24 +02:00
Andrea Bolognani
66e5c43a03 tests: Add firmware-auto-efi-loader-path
This is identical to the existing
firmware-auto-efi-loader-path-nonstandard test case, but uses
a standard firmware path.

Right now the two test cases behave identically, but that's
going to change in the future.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-22 13:49:53 +01:00
Andrea Bolognani
bfb507853a tests: Rename a few firmware tests
This unifies the naming between the manual and automatic
selection cases, clarifies the contents of the tests and makes
room for more tests being added in the future.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-22 13:49:53 +01:00
Andrea Bolognani
1fa20cd87c tests: Unify input files for firmware tests
Most of the differences, such as those in the domain name or
amount of memory, are fairly harmless, but they still make it
more cumbersome than necessary to directly compare different
input (and output) files.

More importantly, the use of unversioned machine types in some
of the test cases results in the descriptor-based autoselection
logic being effectively skipped, because the compatible machine
types as listed in them are only the versioned variants.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-03 13:40:43 +01:00
Andrea Bolognani
de2a338dce conf: Validate firmware configuration more thoroughly
Generally speaking, when firmware autoselection is in use we
don't want any information to be provided manually. There are
two exceptions:

  * we still want the path to the NVRAM file to be customizable;

  * using <loader secure='yes'/> was how you would ask for a
    firmware that implements the Secure Boot feature in the
    original approach to firmware autoselection, so we want to
    keep that working.

Anything else should result in a descriptive error.

Resolves: https://gitlab.com/libvirt/libvirt/-/issues/327
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2022-07-01 15:10:34 +02:00