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
813ccd553b
libvirt/tests/qemuxml2argvdata/firmware-auto-efi-loader-secure-abi-update.x86_64-latest.args

39 lines
1.9 KiB
Plaintext
Raw Normal View History

tests: Add more tests for firmware selection Most of these are just additional coverage, but a few demonstrate bugs in libvirt: * firmware-manual-efi-nvram-template-nonstandard sees the NVRAM template path, which was explicitly provided in the XML, being overridden by the firmware selection machinery; * firmware-auto-efi-rw* and firmware-manual-efi-rw-legacy-paths lose the loader.readonly=no setting and thus behave differently than requested; * firmware-manual-efi-loader-path-nonstandard fails because an NVRAM path doesn't get generated. We're going to address all these issues with upcoming changes. Note that the firmware-auto-efi-nvram-template-nonstandard failure is expected: firmware autoselection has been enabled, but the NVRAM template points to a custom path that's not mentioned in any of the firmware descriptors and so it can't succeed. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-05-26 16:19:24 +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"}' \
conf: Don't default to raw format for loader/NVRAM Due to the way the information is stored by the XML parser, we've had this quirk where specifying any information about the loader or NVRAM would implicitly set its format to raw. That is, <nvram>/path/to/guest_VARS.fd</nvram> would effectively be interpreted as <nvram format='raw'>/path/to/guest_VARS.fd</nvram> forcing the use of raw format firmware even when qcow2 format would normally be preferred based on the ordering of firmware descriptors. This behavior can be worked around in a number of ways, but it's fairly unintuitive. In order to remove this quirk, move the selection of the default firmware format from the parser down to the individual drivers. Most drivers only support raw firmware images, so they can unconditionally set the format early and be done with it; the QEMU driver, however, supports multiple formats and so in that case we want this default to be applied as late as possible, when we have already ruled out the possibility of using qcow2 formatted firmware images. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-05-16 17:50:50 +00:00
-blockdev '{"driver":"file","filename":"/usr/share/edk2/ovmf/OVMF_CODE_4M.secboot.qcow2","node-name":"libvirt-pflash0-storage","auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-pflash0-format","read-only":true,"driver":"qcow2","file":"libvirt-pflash0-storage"}' \
-blockdev '{"driver":"file","filename":"/var/lib/libvirt/qemu/nvram/guest_VARS.qcow2","node-name":"libvirt-pflash1-storage","auto-read-only":true,"discard":"unmap"}' \
-blockdev '{"node-name":"libvirt-pflash1-format","read-only":false,"driver":"qcow2","file":"libvirt-pflash1-storage"}' \
tests: Add more tests for firmware selection Most of these are just additional coverage, but a few demonstrate bugs in libvirt: * firmware-manual-efi-nvram-template-nonstandard sees the NVRAM template path, which was explicitly provided in the XML, being overridden by the firmware selection machinery; * firmware-auto-efi-rw* and firmware-manual-efi-rw-legacy-paths lose the loader.readonly=no setting and thus behave differently than requested; * firmware-manual-efi-loader-path-nonstandard fails because an NVRAM path doesn't get generated. We're going to address all these issues with upcoming changes. Note that the firmware-auto-efi-nvram-template-nonstandard failure is expected: firmware autoselection has been enabled, but the NVRAM template points to a custom path that's not mentioned in any of the firmware descriptors and so it can't succeed. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-05-26 16:19:24 +00:00
-machine pc-q35-4.0,usb=off,smm=on,dump-guest-core=off,memory-backend=pc.ram,pflash0=libvirt-pflash0-format,pflash1=libvirt-pflash1-format,acpi=on \
-accel kvm \
-cpu qemu64 \
-global driver=cfi.pflash01,property=secure,value=on \
-m size=1048576k \
-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
Reference in New Issue Copy Permalink