Commit Graph

27 Commits

Author SHA1 Message Date
Andrea Bolognani
a4fbb7bcc7 tests: Add firmware descriptor for edk2 on riscv64
It's available as part of the edk2-riscv64 Fedora package.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-07-19 15:18:40 +02:00
Andrea Bolognani
79941dd3c9 tests: Update firmware descriptors
Sync with the edk2-20240524-4.fc39 package from Fedora.

The only notable change is that the inteltdx variant now declares
support for Secure Boot and is a ROM image instead of a stateless
pflash one.

The latter causes it to be considered eligible for the
configuration described by the firmware-auto-efi-rw test cases,
which now passes instead of failing.

Of course that doesn't make any sense, because a ROM image by
definition cannot be read/write. So this indicates the presence
of a bug in our firmware selection algorithm, which we're going
to address with an upcoming commit.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
2024-07-19 15:18:16 +02:00
Xianglai Li
a4e3718981 Add loongarch cpu support
Add loongarch cpu support, Define new cpu type 'loongarch64'
and implement it's driver functions.

Signed-off-by: Xianglai Li <lixianglai@loongson.cn>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2024-03-21 14:42:20 +01:00
Andrea Bolognani
116a44d65e tests: Add invalid firmware descriptor
This is guaranteed to keep failing even after loongarch64
support is introduced.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-04 14:36:41 +01:00
Andrea Bolognani
03a2e01dd4 tests: Add firmware descriptor for edk2 on loongarch64
This fails to be parsed because libvirt doesn't yet know about
the architecture, but thanks to the recent improvements this
is a merely a local failure rather than bringing everything
else down with it.

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2024-03-04 14:36:40 +01:00
Andrea Bolognani
1b3e9c67e3 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-08-21 13:51:27 +02:00
Andrea Bolognani
a97c56888c tests: Update firmware descriptor files
These are imported from Fedora 38's edk2 package.

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

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

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

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

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

The following expected changes can be seen in output files:

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

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

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

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

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

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

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

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

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

Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-08-21 13:51:24 +02:00
Andrea Bolognani
3030010fa9 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-22 13:49:53 +01:00
Andrea Bolognani
ba5b338ee3 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-03-03 13:49:56 +01:00
Daniel P. Berrangé
32b9d8b0ae 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-23 18:11:08 +00:00
Michal Privoznik
c8238579fb 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-04-13 17:00:38 +02:00
Peter Krempa
3bfa9fce51 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-11 17:05:34 +01:00
Michal Privoznik
b7d4e6b67e 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-02 15:43:07 +01:00
Daniel P. Berrangé
2c33532423 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>
2020-01-03 15:42:12 +00:00
Michal Privoznik
4fa804c0c7 tests: Use g_strdup_printf() instead of virAsprintf()
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel Henrique Barboza <danielhb413@gmail.com>
2019-11-12 16:15:59 +01:00
Ján Tomko
29b1e859e3 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-21 12:51:59 +02:00
Ján Tomko
45678bd70a Use g_autoptr instead of VIR_AUTOPTR
Since commit 44e7f02915
    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-16 12:06:43 +02:00
Ján Tomko
1e2ae2e311 Use g_autofree instead of VIR_AUTOFREE
Since commit 44e7f02915
    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-16 12:06:43 +02:00
Ján Tomko
67e72053c1 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 16:14:19 +02:00
Ján Tomko
0d94f02455 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-15 11:25:25 +02:00
Michal Privoznik
5a5b8f74d4 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-09-12 12:33:19 +02:00
Michal Privoznik
78f8769a84 qemu_firmware: Extend qemuFirmwareGetSupported to return FW paths
The qemuFirmwareGetSupported() function is called from qemu
driver to generate domain capabilities XML based on FW descriptor
files. However, the function currently reports only some features
from domcapabilities XML and not actual FW image paths. The paths
reported in the domcapabilities XML are still from pre-FW
descriptor era and therefore the XML might be a bit confusing.
For instance, it may say that secure boot is supported but
secboot enabled FW is not in the listed FW image paths.

To resolve this problem, change qemuFirmwareGetSupported() so
that it also returns a list of FW images (we have the list
anyway). Luckily, we already have a structure to represent a FW
image - virFirmware.

Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1733940

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Cole Robinson <crobinso@redhat.com>
2019-09-12 12:31:39 +02:00
Michal Privoznik
9c0d73bf49 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-10 13:58:30 +02:00
Michal Privoznik
c34b3eefdf qemufirmwaretest: Produce better message on error
If qemuFirmwareFetchConfigs() returned more or fewer paths than
expected all that we see is the following error message:

  Expected 5 paths, got 7

While it is technically correct (the best kind of correct), we
can do better:

  Unexpected path (i=0). Expected /some/path got /some/other/path

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
2019-03-26 16:43:48 +01:00
Michal Privoznik
ff86e79faf 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 14:16:46 +01:00
Michal Privoznik
31eb3093c0 qemufirmwaretest: Test qemuFirmwareFetchConfigs()
Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
2019-03-12 15:29:44 +01:00
Michal Privoznik
04406d87d2 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-03-12 15:29:44 +01:00