External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-11-05 21:01:13 +00:00
Code Issues Packages Projects Releases Wiki Activity
a24ab56da8
libvirt/tests/qemufirmwaretest.c

315 lines
12 KiB
C
Raw Normal View History

test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
#include <config.h>
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
#include <inttypes.h>
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
#include "testutils.h"
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
#include "virfilewrapper.h"
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
#include "qemu/qemu_firmware.h"
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
#include "configmake.h"
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
#define VIR_FROM_THIS VIR_FROM_QEMU
/* A very basic test. Parse given JSON firmware description into
* an internal structure, format it back and compare with the
* contents of the file (minus some keys that are not parsed).
*/
static int
testParseFormatFW(const void *opaque)
{
const char *filename = opaque;
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-03 13:43:18 +00:00
g_autofree char *inpath = NULL;
g_autofree char *outpath = NULL;
Use g_autoptr instead of VIR_AUTOPTR Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOPTR aliases to g_autoptr. Replace all of its use by the GLib macro version. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 12:47:50 +00:00
g_autoptr(qemuFirmware) fw = NULL;
g_autoptr(virJSONValue) json = NULL;
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *expected = NULL;
g_autofree char *actual = NULL;
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-03 13:43:18 +00:00
g_autofree char *buf = NULL;
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-03 13:43:18 +00:00
inpath = g_strdup_printf("%s/qemufirmwaredata/%s", abs_srcdir, filename);
outpath = g_strdup_printf("%s/qemufirmwaredata/out/%s", abs_srcdir, filename);
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-03 13:43:18 +00:00
if (!(fw = qemuFirmwareParse(inpath)))
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
return -1;
qemu: support firmware descriptor flash 'mode' for optional NVRAM Currently the 'nvram_template' entry is mandatory when parsing the firmware descriptor based on flash. QEMU is extending the firmware descriptor spec to make the 'nvram_template' optional, depending on the value of a new 'mode' field: - "split" * "executable" contains read-only CODE * "nvram_template" contains read-write VARS - "combined" * "executable" contains read-write CODE and VARs * "nvram_template" not present - "stateless" * "executable" contains read-only CODE and VARs * "nvram_template" not present In the latter case, the guest OS can write vars but the firmware will make no attempt to persist them, so any changes will be lost at poweroff. For now we parse this new 'mode' but discard any firmware which is not 'mode=split' when matching for a domain. In the tests we have a mixture of files with and without the mode attribute. Reviewed-by: Michal Privoznik <mprivozn@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2022-02-03 13:43:18 +00:00
if (virFileExists(outpath)) {
if (virFileReadAll(outpath,
1024 * 1024, /* 1MiB */
&buf) < 0)
return -1;
} else {
if (virFileReadAll(inpath,
1024 * 1024, /* 1MiB */
&buf) < 0)
return -1;
}
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
if (!(json = virJSONValueFromString(buf)))
return -1;
/* Description and tags are not parsed. */
if (virJSONValueObjectRemoveKey(json, "description", NULL) < 0 ||
virJSONValueObjectRemoveKey(json, "tags", NULL) < 0)
return -1;
if (!(expected = virJSONValueToString(json, true)))
return -1;
if (!(actual = qemuFirmwareFormat(fw)))
return -1;
return virTestCompareToString(expected, actual);
}
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
static int
tests: use G_GNUC_UNUSED Use G_GNUC_UNUSED from GLib instead of ATTRIBUTE_UNUSED. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-14 12:45:03 +00:00
testFWPrecedence(const void *opaque G_GNUC_UNUSED)
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
{
Use g_autofree instead of VIR_AUTOFREE Since commit 44e7f029159ed701b4a1739ac711507ee53790ed util: rewrite auto cleanup macros to use glib's equivalent VIR_AUTOFREE is just an alias for g_autofree. Use the GLib macros directly instead of our custom aliases. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 13:16:31 +00:00
g_autofree char *fakehome = NULL;
lib: Replace VIR_AUTOSTRINGLIST with GStrv Glib provides g_auto(GStrv) which is in-place replacement of our VIR_AUTOSTRINGLIST. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2020-12-01 08:21:32 +00:00
g_auto(GStrv) fwList = NULL;
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
const char *expected[] = {
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-05-11 16:29:17 +00:00
SYSCONFDIR "/qemu/firmware/20-bios.json",
PREFIX "/share/qemu/firmware/30-edk2-ovmf-4m-qcow2-x64-sb-enrolled.json",
PREFIX "/share/qemu/firmware/31-edk2-ovmf-2m-raw-x64-sb-enrolled.json",
PREFIX "/share/qemu/firmware/40-edk2-ovmf-4m-qcow2-x64-sb.json",
PREFIX "/share/qemu/firmware/41-edk2-ovmf-2m-raw-x64-sb.json",
PREFIX "/share/qemu/firmware/50-edk2-aarch64-qcow2.json",
PREFIX "/share/qemu/firmware/50-edk2-ovmf-4m-qcow2-x64-nosb.json",
PREFIX "/share/qemu/firmware/50-edk2-ovmf-x64-microvm.json",
PREFIX "/share/qemu/firmware/51-edk2-aarch64-raw.json",
PREFIX "/share/qemu/firmware/51-edk2-ovmf-2m-raw-x64-nosb.json",
PREFIX "/share/qemu/firmware/52-edk2-aarch64-verbose-qcow2.json",
PREFIX "/share/qemu/firmware/53-edk2-aarch64-verbose-raw.json",
SYSCONFDIR "/qemu/firmware/59-combined.json",
PREFIX "/share/qemu/firmware/60-edk2-ovmf-x64-amdsev.json",
PREFIX "/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json",
PREFIX "/share/qemu/firmware/90-combined.json",
PREFIX "/share/qemu/firmware/91-bios.json",
qemufirmwaretest: Base iteration on string lists Remove the need to calculate list lengths. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-05 16:34:13 +00:00
NULL
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
};
qemufirmwaretest: Base iteration on string lists Remove the need to calculate list lengths. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-05 16:34:13 +00:00
const char **e;
GStrv f;
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
tests: use g_strdup instead of VIR_STRDUP Replace all occurrences of if (VIR_STRDUP(a, b) < 0) /* effectively dead code */ with: a = g_strdup(b); Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-20 11:49:46 +00:00
fakehome = g_strdup(abs_srcdir "/qemufirmwaredata/home/user/.config");
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
src: switch to use g_setenv/g_unsetenv Eliminate direct use of normal setenv/unsetenv calls in favour of GLib's wrapper. This eliminates two gnulib modules Reviewed-by: Fabiano Fidêncio <fidencio@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
2019-12-18 17:16:19 +00:00
g_setenv("XDG_CONFIG_HOME", fakehome, TRUE);
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
if (qemuFirmwareFetchConfigs(&fwList, false) < 0)
return -1;
if (!fwList) {
fprintf(stderr, "Expected a non-NULL result, but got a NULL result\n");
return -1;
}
qemufirmwaretest: Base iteration on string lists Remove the need to calculate list lengths. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-05 16:34:13 +00:00
for (e = expected, f = fwList; *f || *e;) {
if (STRNEQ_NULLABLE(*f, *e)) {
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
fprintf(stderr,
qemufirmwaretest: Base iteration on string lists Remove the need to calculate list lengths. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-05 16:34:13 +00:00
"Unexpected path. Expected %s got %s \n",
NULLSTR(*e), NULLSTR(*f));
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
return -1;
}
qemufirmwaretest: Base iteration on string lists Remove the need to calculate list lengths. Signed-off-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2021-02-05 16:34:13 +00:00
if (*f)
f++;
if (*e)
e++;
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
}
return 0;
}
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
struct supportedData {
const char *machine;
virArch arch;
bool secure;
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
const char *fwlist;
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
unsigned int *interfaces;
size_t ninterfaces;
};
static int
testSupportedFW(const void *opaque)
{
const struct supportedData *data = opaque;
uint64_t actualInterfaces;
uint64_t expectedInterfaces = 0;
bool actualSecure;
lib: Drop internal virXXXPtr typedefs Historically, we declared pointer type to our types: typedef struct _virXXX virXXX; typedef virXXX *virXXXPtr; But usefulness of such declaration is questionable, at best. Unfortunately, we can't drop every such declaration - we have to carry some over, because they are part of public API (e.g. virDomainPtr). But for internal types - we can do drop them and use what every other C project uses 'virXXX *'. This change was generated by a very ugly shell script that generated sed script which was then called over each file in the repository. For the shell script refer to the cover letter: https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-03-11 07:16:13 +00:00
virFirmware **expFWs = NULL;
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
size_t nexpFWs = 0;
lib: Drop internal virXXXPtr typedefs Historically, we declared pointer type to our types: typedef struct _virXXX virXXX; typedef virXXX *virXXXPtr; But usefulness of such declaration is questionable, at best. Unfortunately, we can't drop every such declaration - we have to carry some over, because they are part of public API (e.g. virDomainPtr). But for internal types - we can do drop them and use what every other C project uses 'virXXX *'. This change was generated by a very ugly shell script that generated sed script which was then called over each file in the repository. For the shell script refer to the cover letter: https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-03-11 07:16:13 +00:00
virFirmware **actFWs = NULL;
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
size_t nactFWs = 0;
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
size_t i;
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
int ret = -1;
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
for (i = 0; i < data->ninterfaces; i++)
expectedInterfaces |= 1ULL << data->interfaces[i];
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
if (virFirmwareParseList(data->fwlist, &expFWs, &nexpFWs) < 0) {
fprintf(stderr, "Unable to parse list of expected FW paths\n");
return -1;
}
/* virFirmwareParseList() expects to see pairs of paths: ${FW}:${NVRAM}.
* Well, some images don't have a NVRAM store. In that case NULL was passed:
* ${FW}:NULL. Now iterate over expected firmwares and fix this. */
for (i = 0; i < nexpFWs; i++) {
lib: Drop internal virXXXPtr typedefs Historically, we declared pointer type to our types: typedef struct _virXXX virXXX; typedef virXXX *virXXXPtr; But usefulness of such declaration is questionable, at best. Unfortunately, we can't drop every such declaration - we have to carry some over, because they are part of public API (e.g. virDomainPtr). But for internal types - we can do drop them and use what every other C project uses 'virXXX *'. This change was generated by a very ugly shell script that generated sed script which was then called over each file in the repository. For the shell script refer to the cover letter: https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-03-11 07:16:13 +00:00
virFirmware *tmp = expFWs[i];
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
if (STREQ(tmp->nvram, "NULL"))
VIR_FREE(tmp->nvram);
}
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
if (qemuFirmwareGetSupported(data->machine, data->arch, false,
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
&actualInterfaces, &actualSecure, &actFWs, &nactFWs) < 0) {
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
fprintf(stderr, "Unable to get list of supported interfaces\n");
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
goto cleanup;
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
}
if (actualInterfaces != expectedInterfaces) {
fprintf(stderr,
"Mismatch in supported interfaces. "
"Expected 0x%" PRIx64 " got 0x%" PRIx64 "\n",
expectedInterfaces, actualInterfaces);
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
goto cleanup;
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
}
if (actualSecure != data->secure) {
fprintf(stderr,
"Mismatch in SMM requirement/support. "
"Expected %d got %d\n",
data->secure, actualSecure);
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
goto cleanup;
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
}
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
for (i = 0; i < nactFWs; i++) {
lib: Drop internal virXXXPtr typedefs Historically, we declared pointer type to our types: typedef struct _virXXX virXXX; typedef virXXX *virXXXPtr; But usefulness of such declaration is questionable, at best. Unfortunately, we can't drop every such declaration - we have to carry some over, because they are part of public API (e.g. virDomainPtr). But for internal types - we can do drop them and use what every other C project uses 'virXXX *'. This change was generated by a very ugly shell script that generated sed script which was then called over each file in the repository. For the shell script refer to the cover letter: https://listman.redhat.com/archives/libvir-list/2021-March/msg00537.html Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Peter Krempa <pkrempa@redhat.com>
2021-03-11 07:16:13 +00:00
virFirmware *actFW = actFWs[i];
virFirmware *expFW = NULL;
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
if (i >= nexpFWs) {
fprintf(stderr, "Unexpected FW image: %s NVRAM: %s\n",
actFW->name, NULLSTR(actFW->nvram));
goto cleanup;
}
expFW = expFWs[i];
if (STRNEQ(actFW->name, expFW->name) ||
STRNEQ_NULLABLE(actFW->nvram, expFW->nvram)) {
fprintf(stderr, "Unexpected FW image: %s NVRAM: %s\n"
"Expected: %s NVRAM: %s\n",
actFW->name, NULLSTR(actFW->nvram),
expFW->name, NULLSTR(expFW->nvram));
goto cleanup;
}
}
if (i < nexpFWs) {
fprintf(stderr, "Expected FW image: %s NVRAM: %s got nothing\n",
expFWs[i]->name, NULLSTR(expFWs[i]->nvram));
goto cleanup;
}
ret = 0;
cleanup:
virFirmwareFreeList(actFWs, nactFWs);
virFirmwareFreeList(expFWs, nexpFWs);
return ret;
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
}
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
static int
mymain(void)
{
int ret = 0;
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
virFileWrapperAddPrefix(SYSCONFDIR "/qemu/firmware",
abs_srcdir "/qemufirmwaredata/etc/qemu/firmware");
virFileWrapperAddPrefix(PREFIX "/share/qemu/firmware",
abs_srcdir "/qemufirmwaredata/usr/share/qemu/firmware");
virFileWrapperAddPrefix("/home/user/.config/qemu/firmware",
abs_srcdir "/qemufirmwaredata/home/user/.config/qemu/firmware");
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
#define DO_PARSE_TEST(filename) \
do { \
if (virTestRun("QEMU FW " filename, \
testParseFormatFW, filename) < 0) \
ret = -1; \
} while (0)
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-05-11 16:29:17 +00:00
DO_PARSE_TEST("usr/share/qemu/firmware/30-edk2-ovmf-4m-qcow2-x64-sb-enrolled.json");
DO_PARSE_TEST("usr/share/qemu/firmware/31-edk2-ovmf-2m-raw-x64-sb-enrolled.json");
DO_PARSE_TEST("usr/share/qemu/firmware/40-edk2-ovmf-4m-qcow2-x64-sb.json");
DO_PARSE_TEST("usr/share/qemu/firmware/41-edk2-ovmf-2m-raw-x64-sb.json");
DO_PARSE_TEST("usr/share/qemu/firmware/50-edk2-aarch64-qcow2.json");
DO_PARSE_TEST("usr/share/qemu/firmware/50-edk2-ovmf-4m-qcow2-x64-nosb.json");
DO_PARSE_TEST("usr/share/qemu/firmware/50-edk2-ovmf-x64-microvm.json");
DO_PARSE_TEST("usr/share/qemu/firmware/51-edk2-aarch64-raw.json");
DO_PARSE_TEST("usr/share/qemu/firmware/51-edk2-ovmf-2m-raw-x64-nosb.json");
DO_PARSE_TEST("usr/share/qemu/firmware/52-edk2-aarch64-verbose-qcow2.json");
DO_PARSE_TEST("usr/share/qemu/firmware/53-edk2-aarch64-verbose-raw.json");
DO_PARSE_TEST("usr/share/qemu/firmware/60-edk2-ovmf-x64-amdsev.json");
DO_PARSE_TEST("usr/share/qemu/firmware/60-edk2-ovmf-x64-inteltdx.json");
DO_PARSE_TEST("usr/share/qemu/firmware/90-combined.json");
DO_PARSE_TEST("usr/share/qemu/firmware/91-bios.json");
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 14:24:00 +00:00
if (virTestRun("QEMU FW precedence test", testFWPrecedence, NULL) < 0)
ret = -1;
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
/* The @fwlist contains pairs of ${FW}:${NVRAM}. If there's
* no NVRAM expected pass literal "NULL" and test fixes that
* later. */
#define DO_SUPPORTED_TEST(machine, arch, secure, fwlist, ...) \
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
do { \
unsigned int interfaces[] = {__VA_ARGS__}; \
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
struct supportedData data = {machine, arch, secure, fwlist, \
Use G_N_ELEMENTS instead of ARRAY_CARDINALITY Prefer the GLib version of the macro. Signed-off-by: Ján Tomko <jtomko@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2019-10-15 11:55:26 +00:00
interfaces, G_N_ELEMENTS(interfaces)}; \
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
if (virTestRun("QEMU FW SUPPORTED " machine " " #arch, \
testSupportedFW, &data) < 0) \
ret = -1; \
} while (0)
DO_SUPPORTED_TEST("pc-i440fx-3.1", VIR_ARCH_X86_64, false,
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
"/usr/share/seabios/bios-256k.bin:NULL:"
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-05-11 16:29:17 +00:00
"/usr/share/edk2/ovmf/OVMF_CODE_4M.qcow2:/usr/share/edk2/ovmf/OVMF_VARS_4M.qcow2:"
"/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd",
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS,
VIR_DOMAIN_OS_DEF_FIRMWARE_EFI);
DO_SUPPORTED_TEST("pc-i440fx-3.1", VIR_ARCH_I686, false,
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
"/usr/share/seabios/bios-256k.bin:NULL",
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS);
DO_SUPPORTED_TEST("pc-q35-3.1", VIR_ARCH_X86_64, true,
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
"/usr/share/seabios/bios-256k.bin:NULL:"
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-05-11 16:29:17 +00:00
"/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2:/usr/share/edk2/ovmf/OVMF_VARS_4M.secboot.qcow2:"
"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd:"
"/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2:/usr/share/edk2/ovmf/OVMF_VARS_4M.qcow2:"
"/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd:"
"/usr/share/edk2/ovmf/OVMF_CODE_4M.qcow2:/usr/share/edk2/ovmf/OVMF_VARS_4M.qcow2:"
"/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd:"
"/usr/share/edk2/ovmf/OVMF.secboot.fd:NULL:"
"/usr/share/edk2/ovmf/OVMF.amdsev.fd:NULL:"
"/usr/share/edk2/ovmf/OVMF.inteltdx.fd:NULL",
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS,
VIR_DOMAIN_OS_DEF_FIRMWARE_EFI);
DO_SUPPORTED_TEST("pc-q35-3.1", VIR_ARCH_I686, false,
qemufirmwaretest: Test FW path getting through qemuFirmwareGetSupported() There is one hack hidden here, but since this is in a test, it's okay. In order to get a list of expected firmwares in virFirmwarePtr form I'm using virFirmwareParseList(). But usually, in real life scenario, this function is used only to parse a list of UEFI images which have NVRAM split out. In other words, this function expects ${FW}:${NVRAM} pairs. But in this test, we also want to allow just a single path: ${FW} because some reported firmwares are just a BIOS image really. To avoid writing some parser function, let's just pass "NULL" as ${NVRAM} and fix the result later. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-08-05 14:11:26 +00:00
"/usr/share/seabios/bios-256k.bin:NULL",
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS);
tests: Include microvm in firmwaretest libvirt doesn't really support the microvm machine type, but it can parse the firmware descriptor just fine. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-05-18 12:57:07 +00:00
DO_SUPPORTED_TEST("microvm", VIR_ARCH_X86_64, false,
"/usr/share/edk2/ovmf/MICROVM.fd:NULL",
VIR_DOMAIN_OS_DEF_FIRMWARE_EFI);
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
DO_SUPPORTED_TEST("virt-3.1", VIR_ARCH_AARCH64, false,
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-05-11 16:29:17 +00:00
"/usr/share/edk2/aarch64/QEMU_EFI-silent-pflash.qcow2:/usr/share/edk2/aarch64/vars-template-pflash.qcow2:"
"/usr/share/edk2/aarch64/QEMU_EFI-silent-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw:"
"/usr/share/edk2/aarch64/QEMU_EFI-pflash.qcow2:/usr/share/edk2/aarch64/vars-template-pflash.qcow2:"
"/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw",
qemu_firmware: Introduce qemuFirmwareGetSupported The point of this API is to fetch all FW descriptors, parse them and return list of supported interfaces and SMM feature for given combination of machine type and guest architecture. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-04-04 13:52:53 +00:00
VIR_DOMAIN_OS_DEF_FIRMWARE_EFI);
tests: Call virFileWrapperClearPrefixes() for tests using virFileWrapper This is mostly to avoid a memleak that is not a true memleak anyway - prefixes will be freed by kernel upon test exit. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Martin Kletzander <mkletzan@redhat.com> Reviewed-by: Erik Skultety <eskultet@redhat.com>
2019-03-13 08:56:47 +00:00
virFileWrapperClearPrefixes();
test: Introduce qemufirmwaretest Test firmware description parsing so far. The test files come from three locations: 1) ovmf-sb-keys.json and ovmf-sb.json come from OVMF package from RHEL-7 (with slight name change to reflect their features in filename too), 2) bios.json and aavmf.json come from example JSON documents from firmware.json from qemu's git (3a0adfc9bf), 3) ovmf.json is then copied from ovmf-sb.json and stripped of SECURE_BOOT and REQUIRES_SMM flags, OVMF path change, description update and machine type expanded for both pc and q35 machine types. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com> Acked-by: Laszlo Ersek <lersek@redhat.com>
2019-02-19 16:35:43 +00:00
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
VIR_TEST_MAIN(mymain)
Reference in New Issue Copy Permalink