2022-06-09 13:56:32 +00:00
|
|
|
<domain type='kvm'>
|
2023-02-08 18:28:05 +00:00
|
|
|
<name>guest</name>
|
2022-06-09 13:56:32 +00:00
|
|
|
<uuid>63840878-0deb-4095-97e6-fc444d9bc9fa</uuid>
|
2023-02-08 18:28:05 +00:00
|
|
|
<memory unit='KiB'>1048576</memory>
|
|
|
|
|
<currentMemory unit='KiB'>1048576</currentMemory>
|
2022-06-09 13:56:32 +00:00
|
|
|
<vcpu placement='static'>1</vcpu>
|
2023-03-14 22:08:29 +00:00
|
|
|
<os firmware='efi'>
|
2022-06-09 13:56:32 +00:00
|
|
|
<type arch='x86_64' machine='pc-q35-4.0'>hvm</type>
|
2023-03-15 16:53:02 +00:00
|
|
|
<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'>/path/to/guest_VARS.fd</nvram>
|
2022-06-09 13:56:32 +00:00
|
|
|
<boot dev='hd'/>
|
|
|
|
|
</os>
|
|
|
|
|
<features>
|
|
|
|
|
<acpi/>
|
qemu: Move firmware selection from startup to postparse
Currently, firmware selection is performed as part of the
domain startup process. This mostly works fine, but there's a
significant downside to this approach: since the process is
affected by factors outside of libvirt's control, specifically
the contents of the various JSON firmware descriptors and
their names, it's pretty much impossible to guarantee that the
outcome is always going to be the same. It would only take an
edk2 update, or a change made by the local admin, to render a
domain unbootable or downgrade its boot security.
To avoid this, move firmware selection to the postparse phase.
This way it will only be performed once, when the domain is
first defined; subsequent boots will not need to go through
the process again, as all the paths that were picked during
firmware selection are recorded in the domain XML.
Care is taken to ensure that existing domains are handled
correctly, even if their firmware configuration can't be
successfully resolved. Failure to complete the firmware
selection process is only considered fatal when defining a
new domain; in all other cases the error will be reported
during startup, as is already the case today.
Signed-off-by: Andrea Bolognani <abologna@redhat.com>
Reviewed-by: Michal Privoznik <mprivozn@redhat.com>
2023-01-24 16:01:48 +00:00
|
|
|
<smm state='on'/>
|
2022-06-09 13:56:32 +00:00
|
|
|
</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'/>
|
2023-01-20 10:22:22 +00:00
|
|
|
<watchdog model='itco' action='reset'/>
|
2022-06-09 13:56:32 +00:00
|
|
|
<memballoon model='none'/>
|
|
|
|
|
</devices>
|
|
|
|
|
</domain>
|
