libvirt/tests/qemuxml2xmloutdata/firmware-auto-efi-loader-secure.x86_64-latest.xml

42 lines
1.4 KiB
XML
Raw Normal View History

<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>
<os firmware='efi'>
<type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
<firmware>
<feature enabled='yes' name='enrolled-keys'/>
<feature enabled='yes' 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' secure='yes' type='pflash'>/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd</loader>
<nvram template='/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd'>/var/lib/libvirt/qemu/nvram/guest_VARS.fd</nvram>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<smm state='on'/>
</features>
qemu: Store default CPU in domain XML When starting a domain without a CPU model specified in the domain XML, QEMU will choose a default one. Which is fine unless the domain gets migrated to another host because libvirt doesn't perform any CPU ABI checks and the virtual CPU provided by QEMU on the destination host can differ from the one on the source host. With QEMU 4.2.0 we can probe for the default CPU model used by QEMU for a particular machine type and store it in the domain XML. This way the chosen CPU model is more visible to users and libvirt will make sure the guest will see the exact same CPU after migration. Architecture specific notes - aarch64: We only set the default CPU for TCG domains as KVM requires explicit "-cpu host" to work. - ppc64: The default CPU for KVM is "host" thanks to some hacks in QEMU, we will translate the default model to the model corresponding to the host CPU ("POWER8" on a Power8 host, "POWER9" on Power9 host, etc.). This is not a problem as the corresponding CPU model is in fact an alias for "host". This is probably not ideal, but it's not wrong and the default virtual CPU configured by libvirt is the same QEMU would use. TCG uses various CPU models depending on machine type and its version. - s390x: The default CPU for KVM is "host" while TCG defaults to "qemu". - x86_64: The default CPU model (qemu64) is not runnable on any host with KVM, but QEMU just disables unavailable features and starts happily. https://bugzilla.redhat.com/show_bug.cgi?id=1598151 https://bugzilla.redhat.com/show_bug.cgi?id=1598162 Signed-off-by: Jiri Denemark <jdenemar@redhat.com> Reviewed-by: Ján Tomko <jtomko@redhat.com>
2019-09-26 16:42:02 +00:00
<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>