External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 13:45:38 +00:00
Code Issues Packages Projects Releases Wiki Activity
e2a7dd3f7e
libvirt/tests/qemuxmlconfdata/firmware-auto-efi-loader-path.x86_64-latest.xml

41 lines
1.4 KiB
XML
Raw Normal View History

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
<domain type='kvm'>
<name>guest</name>
<uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
<memory unit='KiB'>1048576</memory>
<currentMemory unit='KiB'>1048576</currentMemory>
<vcpu placement='static'>1</vcpu>
qemu: Don't drop firmware type/features information Now that we no longer reject configurations that include both this information and explicit firmware details, as long of course as everything is internally consistent, and that we've ensured that we produce maximally compatible XML on migration, we can stop stripping this information at the end of the firmware selection process. There are several advantages to keeping this information around: * if the user wants to change the firmware configuration for an existing VM, they can simply drop the <loader> and <nvram> elements, tweak the firmware autoselection parameters and let libvirt pick a firmware that matches on the new requirements; * management applications can inspect the XML and easily figure out firmware-related information without having to reverse-engineer them based on some opaque paths. Overall, this change makes things more transparent and easier to understand. The improvement is so significant that, in a follow-up commit, we're going to ensure that this information is available in even more cases. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-14 22:08:29 +00:00
<os firmware='efi'>
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
<type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
qemu: Automatically add firmware type/features information Even when the user is not taking advantage of firmware autoselection and instead manually providing all the necessary information, in most cases they're still going to use firmware builds that are provided by the OS vendor, are installed in standard paths and come with a corresponding firmware descriptor. Similarly, even when the user is not guiding the autoselection process by specifying the desired status of certain features and instead is relying on the system-level descriptor priority being set up correctly, libvirt will still ultimately decide to use a specific descriptor, which includes information about the firmware's features. In both these cases, take the additional information that were obtained from the firmware descriptor and reflect them back into the domain XML, where they can be conveniently inspected by the user and management applications alike. Signed-off-by: Andrea Bolognani <abologna@redhat.com> Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-03-15 16:53:02 +00:00
<firmware>
<feature enabled='no' name='enrolled-keys'/>
<feature enabled='no' name='secure-boot'/>
</firmware>
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
<loader readonly='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.fd</loader>
<nvram template='/usr/share/edk2/ovmf/OVMF_VARS.fd'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
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
<boot dev='hd'/>
</os>
<features>
<acpi/>
</features>
<cpu mode='custom' match='exact' check='none'>
<model fallback='forbid'>qemu64</model>
</cpu>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<controller type='usb' index='0' model='none'/>
<controller type='sata' index='0'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pcie-root'/>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<audio id='1' type='none'/>
<watchdog model='itco' action='reset'/>
<memballoon model='none'/>
</devices>
</domain>
Reference in New Issue Copy Permalink