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>
Specify the memory size by using '-m size=2048k' instead of just '-m 2'.
The new syntax is used when memory hotplug is enabled. To preserve
memory sizing, if memory hotplug is disabled the size is rounded down to
the nearest mebibyte.
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
These are allegedly necessary to keep the output consistent,
but now that we're using a privileged config for the driver we
get the desired behavior out of the box, and as a bonus the
paths match what you would actually see on a regular host.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Martin Kletzander <mkletzan@redhat.com>
QEMU deprecated the '-no-acpi' option, thus we should switch to the
modern way to use '-machine'.
Certain ARM machine types don't support ACPI. Given our historically
broken design of using '<acpi/>' without attribute to enable ACPI and
qemu's default of enabling it without '-no-acpi' such configurations
would not work.
Now when qemu reports whether given machine type supports ACPI we can do
a better decision and un-break those configs. Unfortunately not
retroactively.
Resolves: https://gitlab.com/libvirt/libvirt/-/issues/297
Signed-off-by: Peter Krempa <pkrempa@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
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>
The iTCO watchdog is part of the q35 machine type since its inception,
we just did not add it implicitly.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2137346
Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate memory related arguments into
qemuAppendDomainMemoryMachineParams(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which arguments are generated is changed.
But there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
The qemuBuildMachineCommandLine() function is needlessly long.
Separate out parts that generate arguments based on
domainDef->features[] into
qemuAppendDomainFeaturesMachineParam(). Unfortunately, expected
outputs for some qemuxml2argvdata cases needed to be updated
because the order in which features are generated is changed. But
there's no functional change.
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Peter Krempa <pkrempa@redhat.com>
Currently, a firmware configuration such as
<os firmware='efi'>
<firmware>
<feature enabled='yes' name='enrolled-keys'/>
</firmware>
</os>
will correctly pick a firmware that implements the Secure Boot
feature and initialize the NVRAM file so that it contains the
keys necessary to enforce the signing requirements. However, the
lack of a
<loader secure='yes'/>
element makes it possible for pflash writes to happen outside
of SMM mode. This means that the authenticated UEFI variables
where the keys are stored could potentially be overwritten by
malicious code running in the guest, thus making it possible to
circumvent Secure Boot.
To prevent that from happening, automatically turn on the
loader.secure feature whenever a firmware that implements Secure
Boot is chosen by the firmware autoselection logic. This is
identical to the way we already automatically enable SMM in such
a scenario.
Note that, while this is technically a guest-visible change, it
will not affect migration of existings VMs and will not prevent
legitimate guest code from running.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
This does the opposite of
commit 392292cd99
Author: Daniel P. Berrangé <berrange@redhat.com>
Date: Wed Feb 23 12:45:51 2022 +0000
tests: don't use auto-generated NVRAM path in tests
in order to minimize input files.
We're going to add a test case specifically covering the use of
custom NVRAM paths with firmware autoselection in an upcoming
commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
When testing firmware selection, we don't really care about any
of the hardware assigned to the VM, and in fact it's better to
keep it as minimal as possible to make sure that the focus
remains on the firmware bits.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
Group all tests related to firmware selection together and give
them consistent names that leave room for further tests to be
added in an upcoming commit.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
