conf: Remove some firmware validation checks
libvirt 8.6.0 introduced these checks and very clearly delineated
two possible firmware selection scenarios: manual firmware
selection, where the user is responsible for providing all
information, and firmware autoselection, where a list of desired
features is provided and everything else is handled by libvirt.
In the interest of maintaining the clear separation between these
two scenarios, setting most attributes when firmware autoselection
is active will result in the configuration being rejected.
This works fine, but is unnecessarily restrictive: in most cases,
the additional information that the user has provided matches
the information that libvirt would have discovered on its own by
looking at firmware descriptors, and asking the user to scrub it
from the XML only result in pointless friction.
Remove these checks entirely.
Unsurprisingly, this results in a few test cases that were
rejected until now to suddenly start working and producing
sensible results.
The firmware-auto-efi-loader-path-nonstandard test case is
notable: while we can now enable the xml2xml part of the test,
the xml2argv part is still failing, although in a slightly
different way. This is expected: since the firmware binary is a
non-standard one, libvirt is unable to figure out the missing
information from a firmware descriptor, and the configuration
is still ultimately an invalid one. However, if we were to find
such a configuration on disk at daemon startup, we would not
ignore it completely and instead would offer the user a chance
to fix it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-14 22:02:46 +00:00
|
|
|
LC_ALL=C \
|
|
|
|
|
PATH=/bin \
|
|
|
|
|
HOME=/var/lib/libvirt/qemu/domain--1-guest \
|
|
|
|
|
USER=test \
|
|
|
|
|
LOGNAME=test \
|
|
|
|
|
XDG_DATA_HOME=/var/lib/libvirt/qemu/domain--1-guest/.local/share \
|
|
|
|
|
XDG_CACHE_HOME=/var/lib/libvirt/qemu/domain--1-guest/.cache \
|
|
|
|
|
XDG_CONFIG_HOME=/var/lib/libvirt/qemu/domain--1-guest/.config \
|
|
|
|
|
/usr/bin/qemu-system-x86_64 \
|
|
|
|
|
-name guest=guest,debug-threads=on \
|
|
|
|
|
-S \
|
|
|
|
|
-object '{"qom-type":"secret","id":"masterKey0","format":"raw","file":"/var/lib/libvirt/qemu/domain--1-guest/master-key.aes"}' \
|
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
|
|
|
-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE.fd","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \
|
conf: Remove some firmware validation checks
libvirt 8.6.0 introduced these checks and very clearly delineated
two possible firmware selection scenarios: manual firmware
selection, where the user is responsible for providing all
information, and firmware autoselection, where a list of desired
features is provided and everything else is handled by libvirt.
In the interest of maintaining the clear separation between these
two scenarios, setting most attributes when firmware autoselection
is active will result in the configuration being rejected.
This works fine, but is unnecessarily restrictive: in most cases,
the additional information that the user has provided matches
the information that libvirt would have discovered on its own by
looking at firmware descriptors, and asking the user to scrub it
from the XML only result in pointless friction.
Remove these checks entirely.
Unsurprisingly, this results in a few test cases that were
rejected until now to suddenly start working and producing
sensible results.
The firmware-auto-efi-loader-path-nonstandard test case is
notable: while we can now enable the xml2xml part of the test,
the xml2argv part is still failing, although in a slightly
different way. This is expected: since the firmware binary is a
non-standard one, libvirt is unable to figure out the missing
information from a firmware descriptor, and the configuration
is still ultimately an invalid one. However, if we were to find
such a configuration on disk at daemon startup, we would not
ignore it completely and instead would offer the user a chance
to fix it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-14 22:02:46 +00:00
|
|
|
-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"raw","file":"libvirt-pflash0-storage"}' \
|
2023-10-19 20:07:49 +00:00
|
|
|
-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/guest_VARS.fd","node-name":"libvirt-pflash1-storage","read-only":false}' \
|
|
|
|
|
-machine pc-q35-4.0,usb=off,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-storage,acpi=on \
|
conf: Remove some firmware validation checks
libvirt 8.6.0 introduced these checks and very clearly delineated
two possible firmware selection scenarios: manual firmware
selection, where the user is responsible for providing all
information, and firmware autoselection, where a list of desired
features is provided and everything else is handled by libvirt.
In the interest of maintaining the clear separation between these
two scenarios, setting most attributes when firmware autoselection
is active will result in the configuration being rejected.
This works fine, but is unnecessarily restrictive: in most cases,
the additional information that the user has provided matches
the information that libvirt would have discovered on its own by
looking at firmware descriptors, and asking the user to scrub it
from the XML only result in pointless friction.
Remove these checks entirely.
Unsurprisingly, this results in a few test cases that were
rejected until now to suddenly start working and producing
sensible results.
The firmware-auto-efi-loader-path-nonstandard test case is
notable: while we can now enable the xml2xml part of the test,
the xml2argv part is still failing, although in a slightly
different way. This is expected: since the firmware binary is a
non-standard one, libvirt is unable to figure out the missing
information from a firmware descriptor, and the configuration
is still ultimately an invalid one. However, if we were to find
such a configuration on disk at daemon startup, we would not
ignore it completely and instead would offer the user a chance
to fix it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-14 22:02:46 +00:00
|
|
|
-accel kvm \
|
|
|
|
|
-cpu qemu64 \
|
2023-06-21 14:31:46 +00:00
|
|
|
-m size=1048576k \
|
conf: Remove some firmware validation checks
libvirt 8.6.0 introduced these checks and very clearly delineated
two possible firmware selection scenarios: manual firmware
selection, where the user is responsible for providing all
information, and firmware autoselection, where a list of desired
features is provided and everything else is handled by libvirt.
In the interest of maintaining the clear separation between these
two scenarios, setting most attributes when firmware autoselection
is active will result in the configuration being rejected.
This works fine, but is unnecessarily restrictive: in most cases,
the additional information that the user has provided matches
the information that libvirt would have discovered on its own by
looking at firmware descriptors, and asking the user to scrub it
from the XML only result in pointless friction.
Remove these checks entirely.
Unsurprisingly, this results in a few test cases that were
rejected until now to suddenly start working and producing
sensible results.
The firmware-auto-efi-loader-path-nonstandard test case is
notable: while we can now enable the xml2xml part of the test,
the xml2argv part is still failing, although in a slightly
different way. This is expected: since the firmware binary is a
non-standard one, libvirt is unable to figure out the missing
information from a firmware descriptor, and the configuration
is still ultimately an invalid one. However, if we were to find
such a configuration on disk at daemon startup, we would not
ignore it completely and instead would offer the user a chance
to fix it.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-14 22:02:46 +00:00
|
|
|
-object '{"qom-type":"memory-backend-ram","id":"pc.ram","size":1073741824}' \
|
|
|
|
|
-overcommit mem-lock=off \
|
|
|
|
|
-smp 1,sockets=1,cores=1,threads=1 \
|
|
|
|
|
-uuid 63840878-0deb-4095-97e6-fc444d9bc9fa \
|
|
|
|
|
-display none \
|
|
|
|
|
-no-user-config \
|
|
|
|
|
-nodefaults \
|
|
|
|
|
-chardev socket,id=charmonitor,fd=1729,server=on,wait=off \
|
|
|
|
|
-mon chardev=charmonitor,id=monitor,mode=control \
|
|
|
|
|
-rtc base=utc \
|
|
|
|
|
-no-shutdown \
|
|
|
|
|
-boot strict=on \
|
|
|
|
|
-audiodev '{"id":"audio1","driver":"none"}' \
|
|
|
|
|
-global ICH9-LPC.noreboot=off \
|
|
|
|
|
-watchdog-action reset \
|
|
|
|
|
-sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \
|
|
|
|
|
-msg timestamp=on
|
