shaba/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-23 21:34:54 +03:00
Code Releases Activity
7160215146
libvirt/tests/qemufirmwaretest.c

294 lines
9.8 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 19:35:43 +03: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 16:52:53 +03: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 19:35:43 +03: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 17:24:00 +03: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 19:35:43 +03: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 17:24:00 +03: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 19:35:43 +03: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 16:43:18 +03: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 15:47:50 +03: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 16:16:31 +03: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 16:43:18 +03: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 19:35:43 +03: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 16:43:18 +03: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 19:35:43 +03: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 16:43:18 +03: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 19:35:43 +03: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 16:43:18 +03: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 19:35:43 +03: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 17:24:00 +03: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 15:45:03 +03: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 17:24:00 +03: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 16:16:31 +03: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 11:21:32 +03: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 17:24:00 +03:00
const char *expected[] = {
PREFIX "/share/qemu/firmware/40-bios.json",
SYSCONFDIR "/qemu/firmware/40-ovmf-sb-keys.json",
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 16:43:18 +03:00
PREFIX "/share/qemu/firmware/45-ovmf-sev-stateless.json",
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03:00
PREFIX "/share/qemu/firmware/50-ovmf-sb-keys.json",
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 16:43:18 +03:00
PREFIX "/share/qemu/firmware/55-ovmf-sb-combined.json",
tests: Fix firmware descriptor masking test Right now we're checking that firmware descriptor masking works as intended by creating an empty file matching 60-ovmf-sb.json in name. However, that firmware descriptors contains the details for a perfectly valid and quite common situation: Secure Boot being supported by the firmware build, but being effectively disabled by the lack of certificates in the NVRAM template. Unmask that firmware descriptor, and instead create a dummy one that has higher priority than all other OVMF builds and points to paths that are obviously incorrect, which should make it easy to notice it getting accidentally unmasked in the future. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 22:51:51 +03:00
PREFIX "/share/qemu/firmware/60-ovmf-sb.json",
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03:00
PREFIX "/share/qemu/firmware/61-ovmf.json",
tests: Add descriptors for QCOW2 format firmware builds Now that we ignore all firmwares that are not in raw format while performing autoselection, we can have descriptors for firmware builds in QCOW2 format without breaking anything. Note that the descriptors are arranged so that they have the highest priority on aarch64, but the lowest one on x86_64. This matches the expectation that QCOW2 will quickly be adopted as the default on aarch64, where its use produces significant benefits in terms of memory usage, while x86_64 will likely stick with raw for the foreseeable future. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-27 19:48:43 +03:00
PREFIX "/share/qemu/firmware/65-ovmf-qcow2.json",
PREFIX "/share/qemu/firmware/66-aavmf-qcow2.json",
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03:00
PREFIX "/share/qemu/firmware/70-aavmf.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 19:34:13 +03:00
NULL
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03: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 19:34:13 +03: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 17:24:00 +03: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 14:49:46 +03: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 17:24:00 +03: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 20:16:19 +03: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 17:24:00 +03: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 19:34:13 +03: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 17:24:00 +03: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 19:34:13 +03: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 17:24:00 +03: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 19:34:13 +03: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 17:24:00 +03: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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03: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 10:16:13 +03: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 17:11:26 +03: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 10:16:13 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 10:16:13 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 10:16:13 +03: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 17:11:26 +03: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 16:52:53 +03: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 19:35:43 +03: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 17:24:00 +03: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 19:35:43 +03:00
#define DO_PARSE_TEST(filename) \
do { \
if (virTestRun("QEMU FW " filename, \
testParseFormatFW, filename) < 0) \
ret = -1; \
} while (0)
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03:00
DO_PARSE_TEST("usr/share/qemu/firmware/40-bios.json");
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 16:43:18 +03:00
DO_PARSE_TEST("usr/share/qemu/firmware/45-ovmf-sev-stateless.json");
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03:00
DO_PARSE_TEST("usr/share/qemu/firmware/50-ovmf-sb-keys.json");
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 16:43:18 +03:00
DO_PARSE_TEST("usr/share/qemu/firmware/55-ovmf-sb-combined.json");
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03:00
DO_PARSE_TEST("usr/share/qemu/firmware/60-ovmf-sb.json");
DO_PARSE_TEST("usr/share/qemu/firmware/61-ovmf.json");
tests: Add descriptors for QCOW2 format firmware builds Now that we ignore all firmwares that are not in raw format while performing autoselection, we can have descriptors for firmware builds in QCOW2 format without breaking anything. Note that the descriptors are arranged so that they have the highest priority on aarch64, but the lowest one on x86_64. This matches the expectation that QCOW2 will quickly be adopted as the default on aarch64, where its use produces significant benefits in terms of memory usage, while x86_64 will likely stick with raw for the foreseeable future. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-27 19:48:43 +03:00
DO_PARSE_TEST("usr/share/qemu/firmware/65-ovmf-qcow2.json");
DO_PARSE_TEST("usr/share/qemu/firmware/66-aavmf-qcow2.json");
qemufirmwaretest: Test qemuFirmwareFetchConfigs() Signed-off-by: Michal Privoznik <mprivozn@redhat.com> Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-02-21 17:24:00 +03:00
DO_PARSE_TEST("usr/share/qemu/firmware/70-aavmf.json");
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 19:35:43 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03: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 14:55:26 +03: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 16:52:53 +03: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 17:11:26 +03:00
"/usr/share/seabios/bios-256k.bin:NULL:"
tests: Add descriptors for QCOW2 format firmware builds Now that we ignore all firmwares that are not in raw format while performing autoselection, we can have descriptors for firmware builds in QCOW2 format without breaking anything. Note that the descriptors are arranged so that they have the highest priority on aarch64, but the lowest one on x86_64. This matches the expectation that QCOW2 will quickly be adopted as the default on aarch64, where its use produces significant benefits in terms of memory usage, while x86_64 will likely stick with raw for the foreseeable future. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-27 19:48:43 +03:00
"/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd:"
"/usr/share/OVMF/OVMF_CODE.qcow2:/usr/share/OVMF/OVMF_VARS.qcow2",
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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03: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 17:11:26 +03:00
"/usr/share/seabios/bios-256k.bin:NULL:"
"/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.secboot.fd:"
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 16:43:18 +03:00
"/usr/share/OVMF/OVMF.sev.fd:NULL:"
"/usr/share/OVMF/OVMF.secboot.fd:NULL:"
tests: Fix firmware descriptor masking test Right now we're checking that firmware descriptor masking works as intended by creating an empty file matching 60-ovmf-sb.json in name. However, that firmware descriptors contains the details for a perfectly valid and quite common situation: Secure Boot being supported by the firmware build, but being effectively disabled by the lack of certificates in the NVRAM template. Unmask that firmware descriptor, and instead create a dummy one that has higher priority than all other OVMF builds and points to paths that are obviously incorrect, which should make it easy to notice it getting accidentally unmasked in the future. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 22:51:51 +03:00
"/usr/share/OVMF/OVMF_CODE.secboot.fd:/usr/share/OVMF/OVMF_VARS.fd:"
tests: Add descriptors for QCOW2 format firmware builds Now that we ignore all firmwares that are not in raw format while performing autoselection, we can have descriptors for firmware builds in QCOW2 format without breaking anything. Note that the descriptors are arranged so that they have the highest priority on aarch64, but the lowest one on x86_64. This matches the expectation that QCOW2 will quickly be adopted as the default on aarch64, where its use produces significant benefits in terms of memory usage, while x86_64 will likely stick with raw for the foreseeable future. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-27 19:48:43 +03:00
"/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd:"
"/usr/share/OVMF/OVMF_CODE.qcow2:/usr/share/OVMF/OVMF_VARS.qcow2",
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 16:52:53 +03: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 17:11:26 +03: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 16:52:53 +03:00
VIR_DOMAIN_OS_DEF_FIRMWARE_BIOS);
DO_SUPPORTED_TEST("virt-3.1", VIR_ARCH_AARCH64, false,
tests: Add descriptors for QCOW2 format firmware builds Now that we ignore all firmwares that are not in raw format while performing autoselection, we can have descriptors for firmware builds in QCOW2 format without breaking anything. Note that the descriptors are arranged so that they have the highest priority on aarch64, but the lowest one on x86_64. This matches the expectation that QCOW2 will quickly be adopted as the default on aarch64, where its use produces significant benefits in terms of memory usage, while x86_64 will likely stick with raw for the foreseeable future. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-27 19:48:43 +03:00
"/usr/share/AAVMF/AAVMF_CODE.qcow2:/usr/share/AAVMF/AAVMF_VARS.qcow2:"
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 17:11:26 +03:00
"/usr/share/AAVMF/AAVMF_CODE.fd:/usr/share/AAVMF/AAVMF_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 16:52:53 +03: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 11:56:47 +03: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 19:35:43 +03:00
return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}
VIR_TEST_MAIN(mymain)
Copy Permalink